Author |
Message
|
merlin |
Posted: Thu Aug 19, 2004 6:33 am Post subject: Cluster Queue Messages Building up |
|
|
Novice
Joined: 07 Mar 2004 Posts: 19
|
Hi,
Hope someone has had this problem and knows an easy solution: messages are building up on the System.Cluster.Transmit.Queue over time and not getting delivered to the destination Q Mgr.
Not all messages, of course, but it appears that there is a steady build-up of messages accumulating on the Cluster queue (from times when the target MQ was unavailable I guess) and they don't get flushed to the target q mgr once it is back.
Is this perhaps (answering myself maybe) a sequencing thing? I.e. MQ A sends a message to a clustered Q Mgr, then later sends another message, however the first one didn't get through and now the second one supercedes the first one. Would this cause the first one to get stuck on the Cluster transmit queue?
Thousand thanks to anyone who can help!  |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 19, 2004 4:21 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Browse the S.C.T.Q. and tell us what the destination Queue Manager is for these stuck messages. Is that a valid QM? Is it up? Is it's CLUSRCVR channel up? Don't assume you know what QM those messages are trying to get to. Actually look at them. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
merlin |
Posted: Wed Aug 25, 2004 7:23 am Post subject: |
|
|
Novice
Joined: 07 Mar 2004 Posts: 19
|
Hmmmm...
I think I need to keep a closer eye on these queues in future - since now (ok, I've been busy elsewhere for a short while) I look at the MQ Q Manager and thos 1918 messages are no longer sat in the SCTQ but in the Sys DLQ. Looking at a couple of the messages, the destination QMgr and Q are both fine and what I expected to see there.
I wonder if this is something to do with a prolonged period of time where the channel between sending and receiving MQ managers was down and the MQ Sender gave up?
Strikes me as a tad wierd...  |
|
Back to top |
|
 |
EddieA |
Posted: Wed Aug 25, 2004 9:29 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
What's the DLQ code. That will tell you why the messages were put there.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Aug 25, 2004 2:37 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
I think I need to keep a closer eye on these queues in future
|
You really should have a monitoring tool watching your XMITQs and DLQs. I'm sure you have better things to do.
Quote: |
I wonder if this is something to do with a prolonged period of time where the channel between sending and receiving MQ managers was down and the MQ Sender gave up?
|
MQ would never put a message to a DLQ just cause it got tired of trying. Like Eddie said, the DLQ Header will shed some light on this. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
JasonE |
Posted: Thu Aug 26, 2004 1:36 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Well, messages get moved from the cluster transmit q to the dlq for 2 reasons that I can think of from the top of my head...
One is when the clusrcvr is being deleted and the messages cannot be rerouted (ie put as a fixed destination)
The other is when we try to reroute the messages so another qmgr can process them and fail to put the message for some reason.
As per the other updates, the dlq header is probably the key  |
|
Back to top |
|
 |
merlin |
Posted: Thu Aug 26, 2004 5:29 am Post subject: |
|
|
Novice
Joined: 07 Mar 2004 Posts: 19
|
Cheers for your thoughts guys - the DLQ Error shows as 281, and looking up this code across this website, it turns out the PeterPotkay experienced this issue before! So I found the answer under a thread of his going back to Sept last year.
Pretty sure that the existing app tries to send messages to clustered remote queues using Bind_on_open and that these failed messages ended up on the DLQ because the receiver channel that they were supposed to arrive on got deleted, even though it was replaced with another.
Needless to say I will be updating the app so that it doesn't Bind_on_open, and also looking into putting Monitoring in place to alert me if situation starts developing on SCTQ or SDLQ.
Thanks folks! |
|
Back to top |
|
 |
|