| Author |
Message
|
| ipmqadm |
 Posted: Fri Jul 22, 2011 1:25 pm Post subject: Xmit Queue Depths |
 |
|
Acolyte
Joined: 18 Apr 2007
Posts: 68
|
Funny thing...
Tivoli is alerting that we have records on the xmit queue, BUT the sender channel attached to the xmit queue is RUNNING.
After about 5-10 minutes the records on the xmit queue mysteriously move on to their destination. This is sporadic and an examination of the mq logs confirm that we have no channel issues causing the data to stack up on the xmit queue.
I've seen this before with an application LUW issue, but if tivoli can detect the message on the xmit queue, then the LUW must have been set for the trigger monitor to detect their presence and then move them from the init queue onto the xmit queue? RIGHT????
The application team is adamant that the applications have NO LUW issues.
This is happening on multiple platforms on both mq clustered and non-mq clustered qmgrs.
Has anyone else seen this happen? Can anyone provide a direction to pursue? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jul 22, 2011 1:50 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Some technical details would help.
What version/release of wmq?
Exactly how many messages are waiting in the queue?
What are the values of the sender channel batchsize and batch interval?
When you do a display ql(xmitqueuename), what other attributes (other than depth) do you observe? UNCOM(YES), for example?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 23, 2011 3:38 am Post subject: Re: Xmit Queue Depths |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ipmqadm wrote: |
Funny thing...
I've seen this before with an application LUW issue, but if tivoli can detect the message on the xmit queue, then the LUW must have been set for the trigger monitor to detect their presence and then move them from the init queue onto the xmit queue? RIGHT????
|
WRONG!!!
Uncommitted messages are part of the qdepth.
That the xmit queue shows a qdepth does not mean that the corresponding messages have been committed by the sender.
If the channel is triggered, the trigger only fires when the messages get committed.
From what you say it appears that you might have long running UOWs
| Quote: |
| then the LUW must have been set for the trigger monitor to detect their presence and then move them from the init queue onto the xmit queue |
This is a completely misguided and misunderstood assumption on triggering...
Messages are NEVER moved from the init queue to any other queue but the DLQ. The trigger monitor (or channel initiator) consumes the messages from the Init queue and fires off the corresponding app. The app will then consume the messages on the app queue (xmitq in case of a channel agent)
The message is put on the INIT queue at completion of the triggering conditions (this includes completion of the UOW) that put the messages to the app queue (queue remote, or qdefinition resolving to the xmitq in this case).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jul 23, 2011 12:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Look on the receiving ends of these channels. You probably have conditions (like full queues) that are causing the RCVR channels to drop into their Message Retry Interval and Count logic. While they do that, they will be in a PAUSED state, but the sending side will be in a RUNNING state (but not moving messages.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Jul 23, 2011 4:21 pm Post subject: Re: Xmit Queue Depths |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ipmqadm wrote: |
| Tivoli is alerting that we have records on the xmit queue, BUT the sender channel attached to the xmit queue is RUNNING. |
What is a record, is it the same as a message?
Why is there an alert? Is it alerting you that the queue depth is > 0 ? If not that, what problem is it alerting you to?
If you have some busy putters, then any moment you look, there will be a queue depth > 0. Remember there is a slight pause between batches to allow confirm processing. Also, if your putters are going faster than your channel can move the messages, you will see queue depth > 0.
I do not know what problem your alerts are referring to, maybe you can explain further. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jul 24, 2011 7:19 am Post subject: Re: Xmit Queue Depths |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mvic wrote: |
If you have some busy putters, then any moment you look, there will be a queue depth > 0. Remember there is a slight pause between batches to allow confirm processing. Also, if your putters are going faster than your channel can move the messages, you will see queue depth > 0.
|
And if they are doing MQPUTs under syncpoint, the XMITQ depth will be greater than 0 but the channel will not be able to move them until the app issues the MQCMIT.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ipmqadm |
| Posted: Mon Jul 25, 2011 7:15 am Post subject: |
|
|
Acolyte
Joined: 18 Apr 2007
Posts: 68
|
Thanks everyone for all the good info.
There are no 'uncom' messages on the xmit queue while the records are there.
This is occuring on both mq v6.0 and mq v7.0 qmgrs. And it is also occuring across different platforms...
Thanks for the indepth init queue/xmit queue explanation.
Based upon my experience in the past I'm leaning towards Potkay's thoughts of the long running UOW, between the setting of the LUW. We are setting up a test in a dev environment to try to trap the tivoli alert with a snapshot of the state of the qmgr(queues/channels/etc...) |
|
| Back to top |
|
|
| ipmqadm |
| Posted: Mon Jul 25, 2011 7:29 am Post subject: |
|
|
Acolyte
Joined: 18 Apr 2007
Posts: 68
|
| Thanks for the good input fjb_saper!!! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 25, 2011 8:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Messages, not records. The M in WMQ stands for Message; the Q stands for Queue.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 25, 2011 8:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| ipmqadm wrote: |
Thanks everyone for all the good info.
There are no 'uncom' messages on the xmit queue while the records are there.
Based upon my experience in the past I'm leaning towards Potkay's thoughts of the long running UOW... |
If the putting app has not yet committed messages to the xmit queue (a reason that messages may not be immediately transmitted), there will be UNCOM.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 25, 2011 8:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
You did not answer my previous questions.
1) Exactly how many messages are waiting in the queue?
2) What are the values of the sender channel batchsize and batch interval?
3) When you do a display ql(xmitqueuename), what other attributes (other than depth) do you observe? Post the entire output from the display command here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| ipmqadm |
| Posted: Tue Jul 26, 2011 10:30 am Post subject: |
|
|
Acolyte
Joined: 18 Apr 2007
Posts: 68
|
| bruce2359 wrote: |
| ipmqadm wrote: |
Thanks everyone for all the good info.
There are no 'uncom' messages on the xmit queue while the records are there.
Based upon my experience in the past I'm leaning towards Potkay's thoughts of the long running UOW... |
If the putting app has not yet committed messages to the xmit queue (a reason that messages may not be immediately transmitted), there will be UNCOM. |
Sorry, Bruce. I misstated. You are correct that there will be uncom messages on the queue until the commit. What I MEANT to convey was that there were no orphaned uncom messages on the queue left over from a previous transmission. Thanks for catching that for me. This is confusing enough I don't need to make it more confusing. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 26, 2011 12:54 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Sorry, Bruce. I misstated. You are correct that there will be uncom messages on the queue until the commit. What I MEANT to convey was that there were no orphaned uncom messages on the queue left over from a previous transmission. Thanks for catching that for me. This is confusing enough I don't need to make it more confusing. |
"orphaned uncom messages" is not an mq technical term. Either there are UNCOM, or are not UNCOM. Which is it?
Once again, you have not answer my previous questions.
1) Exactly how many messages are waiting in the queue?
2) What are the values of the sender channel batchsize and batch interval?
3) When you do a display ql(xmitqueuename), what other attributes (other than depth) do you observe? Post the entire output from the display command here.
4) Are other messages being transmitted successfully from this same xmit queue? What I mean is: once the channel begins to misbehave, does is misbehave for all messages? Or just some messages?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
