The MDB shouldn't be processing messages synchronously. I don't understand this post.
me neither ;)
In this context synchronously means a message was put into a queue and without delay received by an MDB. Sorry for that missunderstanding.
My post describes the test result, under certain circumstances there seemed to be a ten minute delay.
We suppose, that the processing in the onMessage of the MDB leads to a transaction deadlock.
If it's deadlocked, then even after 10 years it wouldn't work. You can get a stack trace with CTRL-BREAK on Windows, or attach a debugger and see what's going on during those 10 minutes.
Thanks for that hint. What we found is if transaction timeout is set to 2 minutes, the delay takes 2 minutes, if set to 10 minutes the delay takes 10 minutes, but we did not see a transaction rollback exception.
Anyway the reason for that behaviour is not JMS, but some business logic involved within the onMessage of the MDB.