| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Production Environment MQ/MQSI problems |
« View previous topic :: View next topic » |
| Author |
Message
|
| itechnologist |
 Posted: Wed Jan 07, 2004 6:29 am Post subject: Production Environment MQ/MQSI problems |
 |
|
Novice
Joined: 06 Oct 2003
Posts: 10
|
hi folks:
I have been more in the development side, but would like to get some light on the common problems encountered in the messaging production world. I believe that the monitoring software/counters came with the motivation to solve these production side issues. Just wanted to get some insight on the categories of problems faced in production, how that maps to the monintoring solution/counters etc, causes and fixes. If some admin/production support personnel can point out the top5 or top10 that would helpful.
thanks
itechnologist@comcast.net |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 07, 2004 6:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The general categories of issues that I've run into are - Applications failing to consume messages
- Channels stopping or failing
- Queue Managers being unavailable for some reason
- "Missing" messages (almost always because of application issues on the sending or receiving side)
- Messages appearing on the DLQ
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| itechnologist |
| Posted: Wed Jan 07, 2004 8:18 am Post subject: Production Environment MQ/MQSI problems |
|
|
Novice
Joined: 06 Oct 2003
Posts: 10
|
hi jeff:
thanks for your response. do you/anyone also know what caused these 5 problems?
also how to monitor or track messages that got lost?
Below a way of measuring these 5 situations:
1) when apps fail to consume messages, say on nt, messages will build up on que and que depth threshold can track this.
2,3) channels and quue managers stop/start on nt event log messages
4) If messages are non-persistent, they wont survive system failures.
Error handling
The handling of errors by an application program depends on how the message
flow in the broker has been set up by the administrator.
If an error is generated in a message flow node, a number of things can happen,
depending on how the nodes in the flow are connected, and whether the message
being processed is under transactional control. The error is dealt with according to
the following rules:
v If the failure terminal of the node where the error occurs is connected, the
message is propagated to that terminal.
Otherwise, if it is not connected, an exception is generated and thrown back
towards the MQInput node; then...
v If a TryCatch node is encountered on this route, the flow of control proceeds to
its catch terminal.
Otherwise, if there is no TryCatch node, the exception reaches the MQInput
node; then...
v If the catch terminal of the MQInput node is connected, the message is
propagated there.
Otherwise, if it is not connected, the transactionality of the message is
considered...
v If the message is not transactional, the message is discarded.
Otherwise, if it is transactional, the message is returned to the input queue, and
is read again, whereupon the backout count is checked...
v If the backout count has not exceeded its threshold, the message is propagated to
the output terminal of the MQInput node for reprocessing.
Otherwise, if it has exceeded the threshold, then...
v If the failure terminal of the MQInput node is connected, the message is
propagated to that terminal. (If an error occurs on this route, the message
remains on the input queue in a retry loop until the failure route error clears.)
Otherwise, if the failure terminal of the MQInput node is not connected, the
message is put on an available queue, in order of preference:
– The message is put on the backout queue, if one is defined.
– If the backout queue is not defined, the message is put on the dead letter
queue, if one is defined.
– If the message cannot be put on either of these queues, it remains on the
input queue in a retry loop until the target queue clears.
Note that the message is propagated to the failure terminal of the MQInput node if
an MQCC_WARNING was returned when reading the message from the input queue.
You should also remember that, if you have checked ″Treat warnings as errors″ on
the node properties Advanced tab, database warning messages will cause errors to
be propagated to the failure terminal or one of the other alternatives listed above,
even though the processing might have completed successfully.
But how do you monitor this situation when messages get lost.
5) Persistent messages which have expired for example may land up in DLQ which can be monitored as also above.etc. Also que full event, wrong
que name, app has no authority for put etc can cause message to flow to DLQ i guess. |
|
| 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
|
|
|
|
