| Author |
Message
|
| hannan |
 Posted: Tue Mar 01, 2005 12:24 pm Post subject: Transction Rollback with MQ |
 |
|
Newbie
Joined: 01 Mar 2005
Posts: 2
|
MQ Gurus,
I'm seeing the following Informational message in my Application Log originating from WebSphereMQ.
[i]Transactions rolled back to release log space.
The log space for the queue manager is becoming full. One or more long-running transactions have been rolled back to release log space so that the queue manager can continue to process requests.
Try to ensure that the duration of your transactions is not excessive. Consider increasing the size of the log to allow transactions to last longer before the log starts to become full. [/i]
For my QM I have the following Logging settings:
Use Circular Logging
LogFilePages: (x 4KB) = 1024
LogPrimaryFiles : 50
LogSecondaryFiles : 25
LogBufferPages : [Not Specified]
Although the message above is informational, I would like to know what I can do to avoid this message. Is there a best practice with regards to the number of LogPrimaryFiles and LogSecondaryFiles that should be specified for circular logging?
Rgds,
H |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 01, 2005 12:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Consider reducing the batch size on your channels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Anirud |
| Posted: Tue Mar 01, 2005 12:52 pm Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
One work around would be to change the batch size on your sender channel. The default value is 50, change it to 5.
| Code: |
| alter chl(channelname) chltype(sdr) batchsz(5) |
|
|
| Back to top |
|
|
| hannan |
| Posted: Tue Mar 01, 2005 1:18 pm Post subject: |
|
|
Newbie
Joined: 01 Mar 2005
Posts: 2
|
Thankyou Gentlmen. I will attempt to change this and see the effects.
A few follow-ups just to understand.
I'm assuming that the batch size refers to the number of messages that are sent across the channel (sender, in this case) in one transmission.
Should I change the batch size on all my channels (sender and receiver)?
How does batch size affect the receiver channel?
Is this change Dynamic or would it require an MQ cycle? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 01, 2005 1:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hannan wrote: |
| I'm assuming that the batch size refers to the number of messages that are sent across the channel (sender, in this case) in one transmission. |
Not one transmission.
One transaction.
It doesn't affect the receiver channel, as it's not a property there. It does affect the receiving MCA - it causes more work to be done.
The long term fix is to understand the relationship between your log file size on both sides of the channel, the size of messages you are passing between each QM, and the batch size. Basically, you can only send down a channel in a single transaction as many messages(both in quantity and size) as will fit in the logs on the receiving side. So a big message could cause this, even if the rest of the messages were small.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| guest |
| Posted: Tue Mar 01, 2005 3:38 pm Post subject: |
|
|
Acolyte
Joined: 11 Aug 2003
Posts: 52
|
I may be missing something , but i want to ask
How did we know that "long running transaction" is a channel ????? ..
It may be aswell your one of the application programs rite ??? ...
I dont think reducing a BATCHSZ is not at all a good idea unless otherwise you know for sure its the channel .. There are implications on changing the BATCHSZ parameter. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Mar 01, 2005 4:03 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I agree with the last post.
The most likely cause is that the log is just too small to hold the concurrent transactions. First step is to review the number and scope of the transactions held open by apps running on the system. Use the formula in the System Admin manual to check the log space required. It may be necessary to delete and recreate the qmgr with bigger log files, i.e. LogFilePages set to the maximum for the platform.
BTW, the numbers of primary and secondary log files above must be wrong; the total number cannot exceed 63. |
|
| Back to top |
|
|
|
|
