Author |
Message
|
awatson72 |
Posted: Tue Jan 30, 2007 6:23 am Post subject: AMQ7469 messages - how do I learn more |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
I have a prod queue manager that is writing the AMQ7469 message to the log at fairly regular intervals throughout the day. I know that a common cause of this is that an application putting or getting persistent messages is not issuing commits frequently enough and thus, the logs become fully allocated handling a large UOW. The problem is, the are quite a few applications using this particular queue manager and none of them appear to be having any relavant difficulties. But obviously, this is something I'd like the developers to resolve, (I would consider increasing the number of logs an undesirable workaround). What I'm wondering is what is the approach and what tools might I use to diagnose this? This is a 6.0.1 queue manager running on Linux, using Circular logging with 60 primary and 15 secondary logs. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 30, 2007 6:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
It could simply be that the volume of messages passing across your channels is filling up the logs.
You can, temporarily, decrease the batch size of your channels and see if that helps. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
awatson72 |
Posted: Tue Jan 30, 2007 6:46 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
These are java applications connecting to server connection channels with the native MQ API, so I don't think batch size would be relavant, though I'm not 100% sure.... _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 30, 2007 6:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I mean the channels to and from other queue managers. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
awatson72 |
Posted: Tue Jan 30, 2007 7:01 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
On this particular queue manager, the only channels that aren't SVRCONN channels are cluster sender/receivers. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jan 30, 2007 7:17 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
awatson72 wrote: |
On this particular queue manager, the only channels that aren't SVRCONN channels are cluster sender/receivers. |
Does your architecture predict large amounts of traffic across the cluster, or are you not using it in that way? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
awatson72 |
Posted: Tue Jan 30, 2007 9:00 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
No, I wouldn't expect large amounts of traffic across the cluster in this architecture. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 30, 2007 9:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Then why do you have the cluster? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
awatson72 |
Posted: Tue Jan 30, 2007 11:32 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
110,313 messages went in and out of the SYSTEM.CLUSTER.TRANSMIT.QUEUE in the last 24 hours, so I would not consider that a "large amount of traffic". I think we're talking semantics.
Regardless, my original question stands, how do approach the troubleshooting process to work toward knowing what transaction is causing the large UOW, so I can go bother the developers. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
kevinf2349 |
Posted: Tue Jan 30, 2007 11:43 am Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
There is a queue manager option that you can set to specifiy the maximum number of uncommited messages allowed.
Not sure that helps you prove who did it, but it may stop the problem happening so often. |
|
Back to top |
|
 |
|