You should better use durable subscriptions and JBossMQ redelivery feature instead of a DLQ. In case of a backend failure for one of your MDB's just call ctx.setRollbackOnly() for mdb-specific rollback of message reception. JBossMQ will automatically redeliver these messages after a configurable ammount of time. Set the redelivery delay to a reasonable time delay ( 1m, 15m, 1h,... ) and set redelivery count to infinite. This effectively disables DQL.
Thanks for the response....
I am using durable subscriptions and have considered cranking up the retries. But, I also like the idea of the DLQ. Monitoring that single queue for problems rather than X number of topics/subscribers.
I have also been experimenting with using a message selector like:
(retrysubscriber IS NULL OR retrysubscriber='myDurableSubscriber')
and populating that retrysubscriber property from information contained in the JBOSS_ORIG_DESTINATION property of the DLQed message when I republish the message.
This seems to be working well, but it feels kind of hackish. I'm beginning to think that if I care this much about specifying destination in specific situations then I should probably consider using queues for those cases.
Regardless, at least I have some options...