We've implemented it in the following way:
- place messages in a queue with a custom property (e.g. status) and give this property a value of lets say 'pass'
- give the mdb a filter so it only matches this filter (status=pass)
- if you want to pauze the mdb, put new messages in the queue with 'status=hold'. The MDB wil not receive these anymore
- if you also want the mdb to not process message that are already in the queue, but with a 'status=pass', make a custom jmslistener that receives all messages and requeue's them with 'status=hold'
- On a later moment, you can read all the messages with another custom jmslistener (with a filter for status=hold) and requeue all the messages but now with 'status=pass'. The mdb(s) wil start processing them again.
An alternative we thought of was using 2 queue's. One 'processing-queue' on which the mdb listens and one 'holding-queue'. In this case no filters have to be used.
If anybody has any other solutions (like really pauzing the MDB's) that is cross-platform (we have to support Bea as an appserver as well) I'd be interested.
can you not just undeploy the MDB for pause and redeploy it when you need to "unpause"? (assuming it's a durable subscriber of course.)
If you got full control over the app-server I agree, but if it runs at an asp and you have to fill in a from in quadruple, two weeks in advance and then get an maintanance window from 01.00 to 02.00 AM.... naaaahhhh....
I hope it will become a spec of the new JMS servers, just like the now often proprietary implemented redelivery-timeout etc.