| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Message accumulation in xmitq |
« View previous topic :: View next topic » |
| Author |
Message
|
| guest468 |
 Posted: Tue Nov 04, 2008 9:06 am Post subject: |
 |
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
I meant to say curseqno was not increasing. and curmsgs was at 0. I don't have access to receiver qmgr. And the concerned support team in that side usually takes a long while before responding.
And it was xmitq curdepth which was increasing, that i am pretty sure  . I am in MQ admin field for more than 6 years now to have some idea about it(though i am more of a wmb guy).
I would guess it was a n/w issue. I am waiting on n/w team's response on this problem.
Thank you all. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Nov 04, 2008 9:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I would guess it was a n/w issue. |
It's always the network, isn't it?
It seems likely here as well; but I'm surprised that WMQ didn't detect the channel failures, log them in the error logs in the errors directory, go into retry, then stopped.
You checked the error logs for the qmgr(s) in question, yes? Did you check the error logs at the WMQ-code level, too?
Didn't the folks at the receiving end complain about the 'missing' messages?
| Quote: |
| and curmsgs was at 0 |
CURMSGS is set to zero when a batch is successfully sent; so that's not a surprise.
_________________
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: Tue Nov 04, 2008 9:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I am in MQ admin field for more than 6 years now to have some idea about it(though i am more of a wmb guy). |
I'd guess that there are hundreds or thousands of years of mq admin experience here at mqseries.net.
But since nobody responded with 'Oh, yeah. I had that exact problem!,' I'd figure that it is/was a very, very unusual event.
Clearly, our collective curiousity is peaked. Please let us know what you discover.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Nov 04, 2008 10:00 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| guest468 wrote: |
I meant to say curseqno was not increasing. and curmsgs was at 0. I don't have access to receiver qmgr. And the concerned support team in that side usually takes a long while before responding.
And it was xmitq curdepth which was increasing, that i am pretty sure . I am in MQ admin field for more than 6 years now to have some idea about it(though i am more of a wmb guy).
I would guess it was a n/w issue. I am waiting on n/w team's response on this problem.
Thank you all. |
Well, this is new info. Based on this, I would bet you had an app on your QM putting messages destined for another QM under syncpoint and not committing them. The XMITQ depth would rise, but otherwise there is no evidence of a problem. When I see this happening I send a few dozen messages thru that XMITQ to a test queue on the other QM. If they make it, I know there is nothing wrong with the channel.
In these cases its almost always in the the test environment, where a user is perhaps stepping thru code and hasn't gotten to the MQCMIT call in his code.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
