| Author |
Message
|
| k9i |
 Posted: Wed Aug 18, 2004 10:15 am Post subject: Broker handling of MQOutput node errors |
 |
|
Newbie
Joined: 11 Jul 2004
Posts: 8
|
Using WBIMB 5 with Fix Pack 3 on Windows in a development environment I've found that messages are unexpected lost without errors in a specific case. The problem was found while testing a message flow that referenced an MQOutput node pointing at an incorrectly configured queue manager sender channel. I expected the message to be put back on the broker's dead letter queue and a failure return from the output node. Instead, the output node indicates success, broker trace indicates success and I get a single AMQ9544 warning (not Error!) at the Windows event log saying:
Messages not put to destination queue.
During the processing of channel 'TO.TESTQM' one or more messages could not be put to the destination queue and attempts were made to put them to a dead-letter queue. The location of the queue is 2, where 1 is the local dead-letter queue and 2 is the remote dead-letter queue.
Examine the contents of the dead-letter queue. Each message is contained in a structure that describes why the message was put to the queue, and to where it was originally addressed. Also look at previous error messages to see if the attempt to put messages to a dead-letter queue failed. The program identifier (PID) of the processing program was '752(2944)'.
I also checked the queue manager error log files and broker trace files with no sign of the failure there.
Could it be something that I am doing wrong or is this a bug?
Thanks! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Aug 18, 2004 10:35 am Post subject: Re: Broker handling of MQOutput node errors |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| k9i wrote: |
| The problem was found while testing a message flow that referenced an MQOutput node pointing at an incorrectly configured queue manager sender channel. |
Could you explain this a little better?
Are your messages persistent?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| k9i |
| Posted: Wed Aug 18, 2004 11:34 am Post subject: |
|
|
Newbie
Joined: 11 Jul 2004
Posts: 8
|
Yes the messages are persistent.
To explain the concern a little further ...
The message flow works fine when I use an output queue located on the broker's queue manager.
The problem was found when I was attempting to output the messages to a queue on a different queue manager and did not have the sender channel/xmit queue for the new output queue set up correctly in the broker's queue manager.
An added detail is that the second queue manager is currently running in an MQ cluster along with with the broker's queue manager and has a working cluster sender channel that I thought would be sufficient for the broker (and I am still not sure that its not - but I haven't done enough homework to post a question about that here yet  .
My biggest concern was why I didn't get a more fatal error or error in the flow and/or a copy of the message on the DLQ when a misconfigured output queue could not be reached.
Thanks
Rick |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 18, 2004 11:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The message might have rolled back through the exception handling in the flow, which could have either discarded the message or caused it to go somewhere other than the DLQ... like a backout queue.
The cluster would only be sufficient if the destination queue was actually shared in the cluster.
Do you have a default transmission queue defined?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| k9i |
| Posted: Fri Aug 20, 2004 9:37 am Post subject: |
|
|
Newbie
Joined: 11 Jul 2004
Posts: 8
|
I verified with breakpoints in the message flow and trace that the flow was taking path from the normal terminal after the failed MQ output node (not following failure connection or emitting any other errors). There is no backout requeue configured. There is a DLQ configured and it has worked for other scenarios.
I determined that the root cause was that the cluster sender channel to the other queue manager was incorrectly configured with an incorrect hostname.
I remain concerned that a misconfiguration like this could result in only a warning message to the event log and loss of message.
Thoughts? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 23, 2004 5:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| k9i wrote: |
I determined that the root cause was that the cluster sender channel to the other queue manager was incorrectly configured with an incorrect hostname.
I remain concerned that a misconfiguration like this could result in only a warning message to the event log and loss of message.
Thoughts? |
The messages should be sitting on SYSTEM.CLUSTER.TRANSMIT.QUEUE.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
