Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Websphere MDB/MQ- Total Maximum Retry / Error Queue logic?

119 views
Skip to first unread message

vincent...@fmr.com

unread,
Apr 11, 2008, 1:20:47 PM4/11/08
to
I have a Java Enterprise application that uses Websphere 5.1.1.11's MDB/MQ listener ports. We are receiving messages and processing them. In my app, I use the MesageDrivenContext.setRollbackOnly() method to attempt the message X number of times, then shut down the listener port / rollback any messages that are "FATAL". FATAL messages include ones that encounter issues such as our database being down, etc. <br />
<br />
However, there is an ongoing worry that a particular poison message will come in that will "appear" to encounter a database down error, but not truly encounter one. In this case it could be an endless loop of attempts for failing, shutting down the ports, then manually bringing up the listener ports, and continuing to fail this message, with no options for getting it out of the queue.<br />
<br />
What is the standard for handling potential items like this? Is there an "error queue" mechanism of some kind that can be used within Websphere? Or some kind of maximum retry logic (I know there is a maximum retry field, but that is currently used to attempt a message that number of times till it shuts down the port. What we need is a "total maximum retry" field of some kind). Please let me know if anyone has ideas on this, and my apologies in advance if I've missed this somewhere. Also let me know if more info is needed; I know I've been vague on things.

David Currie

unread,
Apr 14, 2008, 9:23:03 AM4/14/08
to
As things stand you have to choose. Either you set max retries lower
than the backout limit in which case the listener port stops or you set
the backout limit lower than max retries in which case messages are
forwarded to the exception destination. You can't have both.

Regards,
David

Kevin Rowles

unread,
May 4, 2009, 12:48:00 PM5/4/09
to
0 new messages