1 of 1 people found this helpful
Yes.. I found this bug recently also when working on some integration with AS6.
You would need to basically remove the queue manually.
There was another issue also, that each session would create its own queue.
An MDB with maxSession=15 in a durable subscription should only create one.
Sorry for adding multiple responses.. I just keep remembering what to say after pushed send :-)
This is fixed on trunk. You could try trunk now from SVN if you like.
Thanks for the response. Let me make sure I am understanding the intended behavior correctly. Non-durable MDB subscriptions should not be creating their own permanent queue each timeand durable subscriptions would subscribe consistently however would only try to create one session rather than continuing on to maxSessions and failing on each subsequent set up.
On non-durable subscriptions:
The resource adapter (aka the MDB) should create a temporary subscription each time the MDB is deployed, and the temporary subscription should be removed each time the MDB is undeployed.
If you need the subscription to survive an undeployment/redeployment then you really need a durable subscription.
This is just like what would happen to a non-durable subscription using regular JMS API.