MDB non-durable topic subscription results in queue flooding

[bvallade]

Hello,

I am using HornetQ 2.0 GA with JBoss 4.2.1.  I have successfully integrated HornetQ and have my MDBs ingesting messages sent through a remote HornetQ server (the provider is JBoss 5.1/HornetQ 2.0 GA).  I am seeing that every time I reload my application and thus redeploy my MDBs more queues are being created for topic addresses.  Specifically I am seeing one queue per topic/session instance.  We are running on a good size application server farm (30+ machines) and have 15 sessions per MDB.  Given these numbers the queue count for topic addresses will quickly become out of control.  I find this especially bad as most of the queues will not have any subscribers as they are disconnected with each application stop/start. Am I doing something wrong or is this expected behavior?  If it is expected behavior is there a way around this?  I have looked into created durable subscriptions but it looks like that would restrict me to 1 session/subscription per mdb as the subscription name/clientId is shared for the set up of all sessions per mdb.

Any insight would be greatly appreciated.

-Brandon

[clebert.suconic]

Yes.. I found this bug recently also when working on some integration with AS6.

You would need to basically remove the queue manually.

[clebert.suconic]

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.

[clebert.suconic]

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.

[bvallade]

Hey Clebert,

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.

thanks,

Brandon

[clebert.suconic]

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.