Author |
Message
|
Vitor |
Posted: Wed Jul 11, 2007 1:54 am Post subject: Queue Manager log is full on deploy |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Has anyone seen this happening? Taken my own advice, done the search, done the Google & so forth, can't see a relevant doc but link welcomed.
Platform: WinXP
WMQ: 6.0.2.1
WMB: 6.0.2 IFix 005
Toolkit: 6.0.2
A single queue manager hosts both the config manager & broker but no other MQ applications. The queue manager has circular logging and all is well but after a few weeks of use a deploy failed with a 2102 reason code and a Windows event message that the queue manager log was full. Because the flow I was deploying at the time was a bit sizeable (and I was trying to fix a problem) I doubled the number of log files and this resolved the problem.
Now after a few more weeks, the deploy of a considerably simpler flow has failed with the same symptoms. As a WMBv6 newbie:
1) Shouldn't the deploy messages be committed and the log freed once the deploy is complete?
2) Am I missing a housekeeping step to clean up the broker?
3) Is there a process that should be doing this that isn't running, or not running properly?
4) Am I missing a fix?
I'm not short on space but am disinclined to keep adding more logs (or switch to linnear logs!).
Advice and comments welcomed, including "how did you miss this link!!"  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
sebastianhirt |
Posted: Wed Jul 11, 2007 2:59 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004 Posts: 620 Location: Germany
|
Can you spot the queue that carries the messages that fill up your logs (i.e. any of the SYSTEM.BROKER ones)?
That helps figuring out which part of the process causes the trouble.
Personally I have seen loads of problems with deployments. But non of them filled up MQ logs. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jul 11, 2007 3:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sebastianhirt wrote: |
Can you spot the queue that carries the messages that fill up your logs (i.e. any of the SYSTEM.BROKER ones)?
|
It's the SYSTEM.BROKER.EXECUTIONGROUP.QUEUE that's associated with the 2102 code. This ties in with an attempt to deploy that's the opperation at the time of failure.
It's also worth mentioning that aside from this, deploys have been going as smooth as silk. Until now they're smooth as sandpaper. Covered in glue.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jul 11, 2007 4:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Does the 2102 go away if you recycle the broker?
Is the broker particularly busy at the time when you are doing the deploy - perhaps sending and receiving lots of messages over channels? If so, all those messages are in the log as well.
It seems to be a reasonable practice to simply make the logs as big as possible, and then not have to worry about them any more. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jul 11, 2007 4:51 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
jefflowrey wrote: |
Does the 2102 go away if you recycle the broker? |
Yes it does. The broker needs an mqsistop -i to convince it to close.
jefflowrey wrote: |
Is the broker particularly busy at the time when you are doing the deploy - perhaps sending and receiving lots of messages over channels? If so, all those messages are in the log as well. |
Humming gently to itself and doing the crossword while waiting for a message. It's a test system and was not in use at the time of the deploy (trying to deploy new code for a test cycle).
jefflowrey wrote: |
It seems to be a reasonable practice to simply make the logs as big as possible, and then not have to worry about them any more. |
Granted. I'm more concerned that something (presumably broker) is not committing properly and sooner or later any log of any size will fill. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
sebastianhirt |
Posted: Wed Jul 11, 2007 4:56 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004 Posts: 620 Location: Germany
|
Maybe a far shot. But have you looked at the messages in the SYSTEM.BROKER.EXECUTIONGROUP.QUEUE queue?
Most of them are really short and XML. Therefore kinda human readable.
On my Solaris Test Broker there are some hundred messages in. But they are all just starts and stops of execution groups.
Now while I am not the IBM suport and therefore canot grant it will help, I might just go ahead and delete the messages in there.
Ordinary deployments are commited properly. Never had only the slightest trace of a problem with that. And there is nothing like a housekeeping task (you asked earlier) |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jul 11, 2007 5:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Did you restart the broker before the deploy?
Could it be the flows that you're testing that are leaving things uncommitted? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jul 11, 2007 5:01 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sebastianhirt wrote: |
Maybe a far shot. But have you looked at the messages in the SYSTEM.BROKER.EXECUTIONGROUP.QUEUE queue?
...
On my Solaris Test Broker there are some hundred messages in. But they are all just starts and stops of execution groups.
|
Interesting. Mine is empty, and remains so no matter how many deploys, starts or stops I do.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jul 11, 2007 5:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
jefflowrey wrote: |
Did you restart the broker before the deploy? |
No, but the hosting box had been bounced about 4 hours previously. Fair amount of deploy activity since then, mostly small (5 - 10 nodes) flows.
jefflowrey wrote: |
Could it be the flows that you're testing that are leaving things uncommitted? |
I don't think so. The box is a dedicated broker resource, the client programmes don't run there and all the MQOutput nodes have transaction Automatic. I can't think of a message flow on there that not MQInput->modify & route in some way->MQOutput in a single unit of work per input.
Worth looking into though.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
sebastianhirt |
Posted: Wed Jul 11, 2007 5:14 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004 Posts: 620 Location: Germany
|
Vitor wrote: |
sebastianhirt wrote: |
Maybe a far shot. But have you looked at the messages in the SYSTEM.BROKER.EXECUTIONGROUP.QUEUE queue?
...
On my Solaris Test Broker there are some hundred messages in. But they are all just starts and stops of execution groups.
|
Interesting. Mine is empty, and remains so no matter how many deploys, starts or stops I do.  |
Which might just mean that my Broker is weird which I don't want to put away.
I have had a problem with deployments in the past. But that was with the config mgr messing up, not the broker component. This was fixed in FP3 I seem to remember |
|
Back to top |
|
 |
|