| Author |
Message
|
| abd.wsu |
 Posted: Mon Feb 09, 2015 11:14 am Post subject: Uncommited messages on SCTQ |
 |
|
Acolyte
Joined: 12 Sep 2012
Posts: 65
|
We are seeing an issue where there are some uncommitted messages on the SCTQ of a remote queue manager from a broker queue manager.
The number of messages is not an issue. Every once in a while we have 18 - 20 messages and they are all gone really fast, the last 2 or 4 messages seem to linger on the queue for a little bit before going away but our tivoli setup alerts us for these messages.
I checked the qs(SCTQ) and it displays UNCOM(YES). I picked the TID(since PID is just amq process) and did a dis conn all where(TID eq #) and see three dataflow engines and one amq process. Not sure if dspmqtrn would help.
Now, i am not even sure if i should clean up something on the broker side or on the remote queue manager side. This is more like a nuisance than a problem.
The remote queue manager was on an NFS share till a couple of weeks back and we were under the impression this would be a reason for network latency and hence slowness in the messages being picked up. But we are still seeing this after we took the queue manager off the NFS.
Is there a good reason why this would be happening? Is there any place i can look at? Right now we are under the impression that the broker is just dumping a big batch of messages every once in a while. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Feb 09, 2015 11:18 am Post subject: Re: Uncommited messages on SCTQ |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| abd.wsu wrote: |
| Right now we are under the impression that the broker is just dumping a big batch of messages every once in a while. |
That's a reasonable guess.
You might try increasing or decreasing the chlbatch to see if that changes things.
You might also look at the remote clusrcvr to see if there's some signs of what's going on at the other end. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 09, 2015 12:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You might also consider reviewing how quickly your monitor fires when there are some uncommitted messages on a queue. Its not unusual if there are some uncommitted messages on a queue for a little while.
The number of "some messages" and the duration of "a little while" will vary by application, but certainly its not "Alert when there are more than zero messages on the queue for more than 0 seconds". You are not giving the software time to do its job.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| abd.wsu |
| Posted: Mon Feb 09, 2015 12:15 pm Post subject: |
|
|
Acolyte
Joined: 12 Sep 2012
Posts: 65
|
Thanks a ton for the reply.
I checked the remote clusrcvr side. Nothing out of ordinary. Nothing the queue manager error logs either.
I'll try tweaking the BATCHSIZE on the cluster channel on the sending side. Quick question, Should the sending and recieveing queue manager cluster channels have the same BATCHSIZE?
@Peter, that was my first thought about this issue. What i am not sure is if this is normal for the MQ. Currently we are checking for curdepth more than 10 for 5 iterations of 1 minute. So, basically more than 10 messages for more than 5 mins. Not sure if that is normal. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Feb 09, 2015 12:35 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Over cluster channel you really need to change the receiving side, ie. the CLUSRCVR. Changes there will flow over to the sending side automatically. Having different BATCHSZ values at two ends of a channel is not a problem. The channel will negotiate between the two sizes.
As for uncommitted messages as Peter says this is not normally a problem and is in fact unavoidable during normal message processing.If your monitoring app really is going to check for these things, and I'm not sure why it would, then it should probably check the transaction start times. If the start times are all 'recent' then it should ignore the situation. Checking for really long living transactions is not a bad thing to look out for anyway, whether they are on the SCTQ or anywhere else.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
