If I comment one listener out, or keep both JMSListener running - the timeout does not happen and the application shuts down immediately.
The app hangs even if no work has been processed. I reduced the JMSListener
to contain no own business logic at all:
// Die ID wird benoetigt, damit der Listener programmatisch gestoppt werden kannprotectedstaticfinalStringID = "MyListener1";
@JmsListener(id = ID, destination="MYQUEUE")
The problem arises both with Atomikos and Bitronix.
So to me, it looks like you need to have 2 JMSListeners and need to stop one of them to reproduce this problem.
Alright, the issue is fixed on master. Juergen Hoeller can you please backport that to 4.2.x?
It turns out that DefaultMessageListenerContainer was not honouring the stop callback in a particular scenario that was revealed by your use case. Could you please try again in a couple of hours once 4.3.0.BUILD-SNAPSHOT is available? Or you could wait for the backport and test with 4.2.6.BUILD-SNAPSHOT. We're releasing these this week so a confirmation would be much appreciated.
Sorry for the confusion and yes, I tried this version already yesterday and still had problems.
But it must have been my fault - today the error messages are completely vanished. I can stop/start MessageListenerContainer like a charme and stopping
the Spring-Boot Application does not lead to hangs anymore.
Thanks for this quick fix and your great work! I know why we are planning to switch from JEE/Appservers to Spring/Spring-Boot wherever possible ;-)