Thanks for the response. I also would like to add a few things which I got to know from my friend
His quotes :
When you say " the application goes down", I would assume that there's a runtime exception which has occurred in the application (the message consumer/MDB)
I would imagine that the behaviour here is largely dependent on the transaction attributes set for the particular methods. If the bean in question (MDB ) is container managed and has a transaction context, then the
EJB container does try to redeliver the message. (the number of retries is as specified in the listener port)
But in case, repeated attempts of delivering the message fail (in our case, this happens when the MDB repeatedly throws a runtime exception), then the message is placed in a dead letter queue (check if your JMS provider provides this facility. I am also told that in MQ Series we can also use Backout Requeue and Backout threshold). Then the messages have to be moved to the input queue from the dead letter queue(upon correction of the error causing the runtime exception in the MDB).
The other option which we could explore is writing the failed message into some sort of a log, from which we can programmatically recover the failed message.
The main point here is, make sure that the process of delivering and receiving the message is covered in a valid transaction context. For e.g., having the MDB's onMessage method running under "NotSupported" transaction attribute does not guarantee redelivery of failed messages!
I hope this helps!