| Author |
Message
|
| bduncan |
 Posted: Mon Aug 25, 2003 8:42 am Post subject: |
 |
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I might be mistaken, but I just thought I'd throw this one out there to see if anyone remembers it more conclusively.
I thought that if the xmitq was full, subsequent MQPUTs to the remote queue wouldn't result in failure, but instead the message would go to the dead letter queue on the sender side.
It wasn't until both the xmitq and the dead letter queue filled up that the sending application would get an error on MQPUT.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Mon Aug 25, 2003 8:55 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Brandon, messages are NEVER put to the DLQ by an application, which is what your writeup suggests. MQ does not ALLOW putting to DLQ by ANY application directly to DLQ under ANY failure condition.
Hence in this case too, one cannot put to the xmitq if it were full. Putting messages to XMITQ is no different than putting it to a local queue other than the fact that MQ adds the XQH header to the messages that are on XMITQ.
Cheers
Kumar |
|
| Back to top |
|
|
| psanders |
| Posted: Tue Aug 26, 2003 5:57 am Post subject: Don't forget max uncommitted messages. |
|
|
Apprentice
Joined: 02 Apr 2002
Posts: 27
|
It relates here as well. It's one of the mechanisms that can be used to keep this from happening in the first place. In order to put that number of messages you will need to either perform commits occasionally or use no synchpoint.
Just a thought |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Aug 26, 2003 9:56 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Kumar,
By that logic, NO message is EVER put to ANY queue directly by the application. The application ALWAYS hands off the message to the queue manager. It's the queue manager that actually puts the message to a queue, be it local or a xmitq (for a remote destination).
While I couldn't find the exact scenario we are talking about in the MQSeries manuals, there are several examples where an application tries to put a message to a remote queue, but the message actually ends up on the local dead letter queue:
| Quote: |
"The dead-letter queue (or undelivered-message queue) is the queue to which messages are sent if they cannot be routed to their correct destination. Messages are put on this queue when they cannot be put on the destination queue for some reason (for example, because the queue does not exist, or because it is full). Dead-letter queues are also used at the sending end of a channel, for data-conversion errors. "
"The messages being moved have originated from any other queue manager in the network, and some messages may arrive that have an unknown queue manager name as destination. This can occur when a queue manager name has changed or has been removed from the system, for example.
The channel program recognizes this situation when it cannot find a transmission queue for these messages, and places the messages on your undelivered-message (dead-letter) queue. It is your responsibility to look for these messages and arrange for them to be forwarded to the correct destination, or to return them to the originator, where this can be ascertained."
|
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Aug 26, 2003 9:59 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
And in the examples I cite above, the application will get a successful return code after the MQPUT, even though the message ended up on the dead letter queue.
I believe that the same would occur in the case where the xmitq is full.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Aug 26, 2003 10:09 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Brandon, If we are going into specifics then let me add something else. Its the Queue manager AGENT that does puts/gets and not the queue manager itself.
Now, the transcript from the manuals that you posted here is not clear or specific as most part of the manuals are(Anybody from IBM pls ignore me..).. :)... It just says what is a DLQ message, but it does not detail as to under what all conditions message land up there.
As per my recollection, ONLY the MCA and the COMMAND SERVER are the MQ guys who can directly put a message to the DLQ under failure condition. Queue manager Agent that pertains to a user application Never PUTS msg directly to the DLQ "under any condition". Hence there wouldnt be an instance where an application's put directly lands up to the local DLQ.
You are right, in your cited example. If you put to a remote queue and there is a channel agent servicing its xmitq, it would pull off the msg and ties to put to the remote qm's local/destination queue. But in the event an error occurs, depending upon the type of the error, it may put to the DLQ of the remote end. There are, i think only 1 or 2 very very very rare instances where the MCA would put the msg to the Senders DLQ. But again, in this case it would be the MCA and NOT the application or its respective queue manager agent that would do this.
Cheers
Kumar |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 26, 2003 10:17 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Brandon, I agree with Kumar on this one. If the message can make it as far as the XMIT queue, then that is where the message will go and that is where it will stay until the MCA picks it up and sends it to the other side.
Once the message has made it to the XMIT queue, it will never go to the DLQ on the sending side. I can't think of any scenario where a sending MCA would ever put a message to a DLQ.
Now if the QM agent cannot put the message to the XMIT queue, or any other local queue (this includes locally defined remote queue definitions), then then the putting application is notified that the MQPUT is unsuccesful, and the message goes nowhere (the app still has control).
The rule of thumb is that if the putting application can be notified synchronously of a failed put to its intended locally defined queue, it will be. MQ will not accept responsability of a message if it knows it cannot handle it locally.
AND, if we are really splitting hairs,  , any application can put any message to any queue (if they have the authority). This includeds the DLQ. If you do have an app that puts messages to a DLQ directly,  , not that you would want to, but if you do, you should probably build the DLQ header into the message, so the DLQ handler don't choke.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bbeardsley |
| Posted: Tue Aug 26, 2003 3:13 pm Post subject: |
|
|
Acolyte
Joined: 17 Dec 2001
Posts: 52
Location: Dallas, TX, USA
|
To go back to the original question :
| Quote: |
...when the local queue on MQ2 is full (for whatever reason), the messages are put on the Dead Letter Queue on the QM2.
My question is, if the DLQ is also full, will the channel go down? what happens. |
Let's assume you have the two queues and one dedicated (nothing else is using it) channel set.
When a msg cannot be put to it's destination queue, because the destination queue is not available (for pick-your-reason put inihibited, full, etc), the receiver channel on QM2 will usually go into a state of PAUSED, and not go down ... right away. The sender QM1 channel is still running. The receiver channel is waiting on the retry count/interval to be exhausted. After it reaches those limits with no success on delivering the msgs, it tells to sender channel the msg is a no-go. When that happens the msg is backed out to the dlq on the sender side.
Or that's my understanding of it, anyway. So if your msgs are making it to the dlq on QM2, you should double check the return code. Maybe they are too big for the queue? or have another problem. I'm pretty sure they never make it across to the receiver when the destination queue is full. I'm also sure someone here will correct me if I'm wrong.
-Bridgette[/quote] |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 26, 2003 5:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
it tells to sender channel the msg is a no-go. When that happens the msg is backed out to the dlq on the sender side.
|
No, the messages go the DLQ on the RCVR side. The channel stays up until both the application queue and the DLQ (on the receiving side) are full. At that point the channel shuts down, and now the messages start piling up in the XMIT queue on the sending side. And when the XMIT queue fills up, the putting app will start getting bad return codes on its MQPUTs.
Messages will never go to the DLQ on the sending side.
You are correct in pointing out the Message Retry Counts and Intervals, which tell the RCVR MCA how many times to try reputting the message to the application queue before putting it to the DLQ.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| psanders |
| Posted: Wed Aug 27, 2003 6:33 am Post subject: We had an application on MVS that looped sending to a remote |
|
|
Apprentice
Joined: 02 Apr 2002
Posts: 27
|
queue. Here is what happened:
1. The messages started going to the target QM and Q
2. The target Q filled up
3. The target QM started placing messages on the DLQ
4. The Transmit queue filled up and the putting application got an error. (can't recall what error)
5. In our case the program continued trying to put more messages 
Hope it helps. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 27, 2003 6:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Sure, this makes sense. In step 5, you program ignores the bad return code on its MQPUT and continued to keep trying to do more MQPUTs, all of which were failing.
The program needs better error handling logic. It needs to stop when it encounters a bad RC on the put.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Aug 28, 2003 11:21 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Peter,
I agree with you and Kumar that the MQPUTs will fail when the xmitq fills up. As I said in my first response, I *thought* the messages would go to the sender side's DLQ, but you guys have corrected me.
However, you said:
| Quote: |
| Messages will never go to the DLQ on the sending side. |
But the excerpts I found in the MQ manuals seem to indicate that under a few conditions, messages might end up on the sender's DLQ.
Specifically, it seems to say if there is a conversion error, or if the queue manager cannot find the xmitq associated with the remote queue that the message was put to, then the message will end up on the sender's DLQ. Is this correct?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Aug 29, 2003 5:15 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Brandon. Answer to both questions is NO.
I am not 100% sure about the conversion error. In which case i would think that the MCA would put the message without conversion. Just my guess. In any case conversion takes place under normal circumstances only on a Get or by the MCA if CONVERT(YES) is set. In this case too, the application itself has no responsibility from the PUT's perspective. It has put whatever was told to it, on the xmitq.
Coming to the 2nd question. The answer is definitely NO. If the xmitq associated with the remote queue is not there, then the OPEN will fail.
As i mentioned earlier there are at least 2 very very very remote possibilites under which the message go to the Sender sides DLQ. But again this is done by the MCA, NEVER by the application or its agent.
Cheers
Kumar |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Aug 29, 2003 8:00 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well I was never trying to make a distinction about *who* would put it to the sender's DLQ (MCA, application, or agent) but just that I believe there are circumstances where the message will end up there...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mathew |
| Posted: Wed Sep 17, 2003 11:48 pm Post subject: |
|
|
Newbie
Joined: 17 Sep 2003
Posts: 2
|
good discussion!
this from real life:
Some days ago we have had msgs on DLQ. The MCA put this messages to DLQ because the application (JMS API) put UTF msgs to an remoteQ and target QMGR was a host with EBCDIC CCSID.
The msgs on DLQ had reasoncode "conversion error" but the strange thing was that these msgs were in the default CCSID of the QMGR. That means that this msgs had been converted from UTF to the default CCSID.
Plattform AIX with MQ 5.3 CSID 4 |
|
| Back to top |
|
|
|
|
