| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Getting Applications and Exception queues |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Aug 05, 2002 6:11 am Post subject: Getting Applications and Exception queues |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When setting up an architecture for a project, do you always, sometimes or never provide the app with an exception queue to put messages to that it can't handle for some reason ?
Backout Count exceeds threshold
Message to big for buffer
Data in buffer not correct for getting application
On the one side, you could have persistent messages that update financial databases. That's pretty much a no-brainer. They should have that exception queue because we cannot afford to lose any message, regardless of what's wrong with. Someone needs to look at them.
But what about nonpersistent inquiry messages that expire in 20 minutes? I guess an app would want to know what garbage is being sent in when things go wrong (I would anyway). Is it overkill to always set up this type of queue and tell the app to code this type of error handling logic, because this is an MQ issue, and as an MQ "expert", we should be forcing this on them cause its good for them, whether they like it or not? Or do we let the app decide whether they want/need this?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| nimconsult |
| Posted: Mon Aug 05, 2002 10:44 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Hello Peter,
Some of my opinions on the subject. I hope you will find them helpfull.
For persistent message it should be mandatory to have a dead-letter queue available to the application. Why? If you have set the message to persistent, it means that you cannot afford to loose it. If your app forgets persistent messages as soon as it encounters a problem, you are somewhat in contradiction with the objective of the persistence. There are so many reasons to encounter a problem that the decision should be analyzed deeply.
In term of dead-letter queue I have seen two options:
- the first option is to use the system dead-letter queue (SYSTEM.DEAD.LETTER.QUEUE). A dead-letter queue handler can run on the queue to process standard problems automatically, other problems are routed to a dedicated application dead-letter queue (something like LQ.MY_APPLICATION.DLQ).
- the second option is to post immediately to a dedicated application dead-letter queue. Here again you can run a dead-letter queue handler, which is in this instance specific to an application.
In all cases you need a monitor linked to a console, and raise alerts when messages are stored on a dead-letter queue.
The advantage of the first option is that messages on the dedicated application dead-letter queue are "really-dead" messages.
For non-persistent messages, I do not impose the usage of a dead-letter queue if I have an easy way to detect and replay the problem. This is typically the case for "request/reply" messages. If there is a problem, the support team can reproduce the problem using the client application.
For non-request/reply, you need a way of detecting/replaying the problem, and I think that a dead-letter queue is the most straightforward solution.
There are also other facts to consider. For example, consider a strict FIFO application (messages *HAVE* to be processed in sequence). If the application encounters a problem, you have the choice between posting the message on a dead-letter queue and stop the application, or leave the message on the application queue (MQBACK) and stop the application. I would say in this case I would recommend NOT to use a dead-letter queue.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Aug 06, 2002 5:27 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Typically, the "application" moving these messages around is actually a huge product in and of itself, which means it probably has a logging architecture already in place. So sometimes it makes sense to just make use of this functionality, and log the fact that you've found a bad message. You can output the header and message contents, as well as why the message failed. Now you can simply discard the message, and later, if necessary you can recreate the message in its entirety from the application's log file.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
