Self-disable of MDB?

[ewestland]

Hello,

I have a situation where a resource my MDB relies upon can become inaccessible. I can detect the situation in my onMessage() method, but don't know how to tell the JMX server to disable it; allowing the messages to queue while an operator fixes the resource.

BTW - I don't want to leave the bean enabled because I am trying to avoid messages ending up in the dead letter queue.

Thoughts?

Thanks,
Erik

[lucsky]

I've just used setRollbackOnly() to "send back" the MDB to queue, when any resource it relies upon is unavailable (in fact, I've just caught any RuntimeException).
To avoid the DLQ queue problem, I've just defined the DLQ to be the MDB's destination queue in jboss.xml.
It has been working fine for some months in production.

[javadin]

The other approach would be to set the redelivery frequency in your code and redelivery limit high enough so that the MDB does not get bombarded and the message stays in the JMS destination long enough for you to recover. This is the approach I use to handle database access failures.

[ewestland]

Great suggestions - I will give them more rigorous thought...

Off the cuff, I believe I still have concerns though. In my situation, retaining message order is critical. That is why I had hoped to disable (or undeploy?) the bean. This would reduce load on the system by not having to shuffle these messages around while we are in an error state. The onus would be on an operator (or a JMX bean) to reactivate/reenable/redeploy the bean when the problem has been rectified.

I don't know if it is possible to setup lucsky's DLQ solution to retain my queue order.

I believe that javadin's solution may also have the ordering problem.

So, any additional thoughts?

Thanks for your input!!!

Cheers,
Erik

[javadin]

I am just curious to know how do you handle ordering using MDBs. Are you using a singleton MDB?

[lucsky]

Just to make it clear, the DLQ is set up to be the same MDB's destination queue. But to keep the same order, I'm not sure if a Singleton MDB is gonna "consume" the redelivered messages before the new incoming messages, when the dependent resources become available again. In this case, you should implement something else to keep the correct order.