In alignment with #30242, DefaultMessageListenerContainer should proactively close the shared JMS Connection (if any) once the stop completion callback is triggered. While a regular stop() call will return before the invokers have actually stopped, the stop variant with a callback is effectively equivalent to the invoker handling in shutdown() where it is being followed by a closing of the shared Connection already.

On start(), the existing code path will automatically re-establish a JMS Connection already, just like when the Connection got closed due to an invoker exception. It seems generally sensible to close the Connection when not in use... since the chances of hitting a timeout or otherwise becoming stale are high while paused, so the Connection might need to be closed and re-established on re-start in any case.

Comment From: jhoeller

On a related note, we release the shared JMS Connection on Single/CachingConnectionFactory.stop() as well now.