Author |
Message
|
John_peter |
Posted: Tue Jun 29, 2004 7:48 pm Post subject: XMIT Queue Full |
|
|
Novice
Joined: 10 May 2004 Posts: 22
|
I wanted to find out what would happen if the XMIT gets full.
I had a typical DQM , sender receiver set up.
I set the Maximum queue depth of the XMIT q to 2 , stopped the listener on the other end. Put three messages on the remote queue def.
Started the listener again, all three message came to the remote queue.
Ignores queue depth on xmit q? |
|
Back to top |
|
 |
kman |
Posted: Tue Jun 29, 2004 11:38 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003 Posts: 309 Location: Kuala Lumpur, Malaysia
|
mmmm are you pretty sure the right listener was stopped?
If listener was stopped, there would be an error recorded in amqerr01.log on communication failure.
You could stop the sender channel. Remove channel triggering. Then PUT your messages.  |
|
Back to top |
|
 |
John_peter |
Posted: Wed Jun 30, 2004 12:54 am Post subject: |
|
|
Novice
Joined: 10 May 2004 Posts: 22
|
But what is the expected behaviour??
WHat really happens when xmit queue gets full?
Is it any different for persistent and non-persistent messages? |
|
Back to top |
|
 |
kman |
Posted: Wed Jun 30, 2004 1:06 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2003 Posts: 309 Location: Kuala Lumpur, Malaysia
|
It should be sent to DLQ.
its the same with persistence or not. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jun 30, 2004 4:46 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
When the XMIT queue is full, the application putting the messages will syncronously get a bad RC on the MQPUT (2053) telling it as much. They will not go to the DLQ. Makes no diff if the messages are Persistent or not.
JohnPeter,
Quote: |
set the Maximum queue depth of the XMIT q to 2 , stopped the listener on the other end. Put three messages on the remote queue def.
Started the listener again, all three message came to the remote queue.
|
Something is wrong here. Try again, and make sure the MaxQueue Depth of the XMITQ is 2. And make sure the remote queue def you are putting to specifies this XMITQ and not some other one. Then put one message at a time, noteing the MQRC on each MQPUT. The first 2 should work, the 3rd should get a 2053 error. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Michael Dag |
Posted: Wed Jun 30, 2004 10:27 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
Quote: |
Unit-of-work processing and the segmentation of messages can both cause the actual number of physical messages on the queue to exceed |
just a guess, can you set the default BATCHSZ to 1 instead of 50 and try again? _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jun 30, 2004 2:35 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
To test the right behavior you really need to stop the sender channel and not the receiver channel.
If only the receiver channel is stopped you can have up to your channel batchsz number of messages in transit in the channel. This would potentially allow you to put new messages on the transmission queue as the messages are in transit on the channel albeit not commited but no longer part of the xmitq's qdepth.
Have fun.  |
|
Back to top |
|
 |
|