| Author |
Message
|
| elikatz |
 Posted: Wed Nov 11, 2009 5:43 am Post subject: WMB and MQ 6.0.2.7 - transaction issue? |
 |
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
hi all,
I have a client trying to connect to our server using weblogic messaging bridge, the server is MQ version 6.0.2.7 installed on windows 2003 SP2.
The queue manager is holding mostley the default values.
The client complains he gets the following error:
javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue and com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2009.
on the server side is see the follwoing error:
Event Type: Information
Event Source: WebSphere MQ
Event Category: None
Event ID: 7469
Date: 11/11/2009
Time: 2:26:30 PM
User: N/A
Computer: XXXXXX
Description:
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've already doubled the number of log file as suggested here but seems that it does help.
any sugestions?
thanks...
Last edited by elikatz on Wed Nov 11, 2009 6:33 am; edited 1 time in total |
|
| Back to top |
|
 |
| WMBDEV1 |
| Posted: Wed Nov 11, 2009 5:55 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Quote: |
i've already doubled the number of log file as suggested here but seems that it does help.
|
How did you approach this? Did you just try poking some random numbers in to see what happened or did you do something more scientific? Just doubling them seems to suggest the former - who suggested this and why?
Some questions for you then...
How much log space do you have?
How much log space do you need and how did you work this out?
Is there enough space on the file system to accomodate this size of log? |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 11, 2009 5:57 am Post subject: Re: WMB and MQ 6.0.2.7 - transaction issue? |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| elikatz wrote: |
| ...i've already doubled the number of log file as suggested here but seems that it does help... |
Does help, or doesn't help? Did you restart the queue manager after changing the number of logs?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed Nov 11, 2009 6:08 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
thanks both for the speedy reply, now some answers:
WMBDEV1:
I didn't calculated the number and size of the log file, I found a suggestion to increase to number so I just doubled the number to get a quick response from the MQ server - nothing scientific from first place.
as I'm pretty new to MQ i didn't calculate it initially.
I’ve set the Log Page File to 10,240KB ; Log Primary Files to 60 ; Log secondary File to 40 ; all the rest is the defaults: Log Buffer pages is 0 and Log write integrity is triple write.
we have plenty of disk space on that server.
exerk:
It did help of about 12 hours and then the problem came back, as per IBM's site there is no need to restart the qmgr after changing the number of files.
your help is much appreciated!! |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 11, 2009 6:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| elikatz wrote: |
| ...as per IBM's site there is no need to restart the qmgr after changing the number of files... |
Really? 
You must be looking at a different IBM website than me, because the WebSphere MQ Version 6.0 Information Centre states:
| Quote: |
LogPrimaryFiles=3|2-254 (Windows®)|2-510 (UNIX® systems)
The log files allocated when the queue manager is created.
The minimum number of primary log files you can have is 2 and the maximum is 254 on Windows, or 510 on UNIX systems. The default is 3.
The total number of primary and secondary log files must not exceed 255 on Windows, or 511 on UNIX systems, and must not be less than 3.
The value is examined when the queue manager is created or started. You can change it after the queue manager has been created. However, a change in the value is not effective until the queue manager is restarted, and the effect might not be immediate.
LogSecondaryFiles=2|1-253 (Windows)|1-509 (UNIX systems)
The log files allocated when the primary files are exhausted.
The minimum number of secondary log files is 1 and the maximum is 253 on Windows, or 509 on UNIX systems. The default number is 2.
The total number of primary and secondary log files must not exceed 255 on Windows, or 511 on UNIX systems, and must not be less than 3.
The value is examined when the queue manager is started. You can change this value, but changes do not become effective until the queue manager is restarted, and even then the effect might not be immediate. |
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Wed Nov 11, 2009 6:18 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| elikatz wrote: |
I’ve set the Log Page File to 10,240KB |
Did you do this before or after creating the QM? If after it will have no effect as this must be set when the QM is created.
I'd try and apply some science to this now....
Work out how much space your logs can currently accomodate (search for help on this if needed as theres some good documents from IBM on this, heres one I found for starters: http://www.ibm.com/developerworks/websphere/library/techarticles/0712_dunn/0712_dunn.html but you can probably find better) and then work out how much space you will need for your environment. |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed Nov 11, 2009 6:27 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
It was whish full thinking about not restating the queue manager as I looked in this page:
http://www-01.ibm.com/support/docview.wss?uid=swg21204894
I guess I need to restart the queue manager.
WMBDEV1, I've set this number when creating the queue manager.
Regardless to this and to me going to do some reading from the link WMBDEV1 gave me, is there any general suggestion?
I'm going to restart the queue manager, hopefully it will give me a few days of quite so i can learn what I really need... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 11, 2009 6:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
That page also clearly states you need to restart the QM.
Upping the # of logs only delays the inevitable if the app submits messages under syncpoint and never commits. Sooner or later you exhaust your log space, whether you have a lot of log space or not so much.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed Nov 11, 2009 6:48 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
what should I suggest my client on that case?
It sounds like there is nothing to do on the server side in that case. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 11, 2009 6:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the app tells MQ to hold the message by using the syncpoint option then the app also has to commit or backout those holds as soon as feasible.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 11, 2009 6:57 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The application isn't doing something stupid like waiting until all messages have been processed before committing is it? (been there, seen it, suffered the consequences - but had great pleasure in re-educating the idiot responsible).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 11, 2009 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elikatz wrote: |
| what should I suggest my client on that case? |
Get the client to fix the application. There's either a bug, or a design issue.
It sounds like there is nothing to do on the server side in that case.[/quote]
No. It's an issue with application behaviour (as my worthy associates have pointed out).
FWIW this sort of problem doesn't often show up in testing as the data volumes tend to be lower and not enough to fill the qmgr logs. So when the client says "but it's been fully tested, it must be a server configuration issue" push back.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed Nov 11, 2009 7:42 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
I'll ask my client regarding the commit - would the right question be: are you waiting until all messages are processed before committing? are you using syncpoint option?
thanks for leading me with this one... maybe I’ll have the pleasure of educating someone as well... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 11, 2009 7:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elikatz wrote: |
| would the right question be: are you waiting until all messages are processed before committing? are you using syncpoint option? |
I'd ask what prompts the application to commit messages. Is it based on business information, or a number of messages? If so how did they come up at the number?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elikatz |
| Posted: Thu Nov 12, 2009 4:48 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
here are some of the client's settings on his weblogic messeging bridge:
Quality Of Service: Duplicate-okay
QOS Degradation Allowed : Yes
Asynchronous Mode Enabled : Yes
Transaction Timeout: 30
Batch Size: 10
Batch Interval (milliseconds): -1
maybe this will help to shed some light?
still trying to get his fdc's |
|
| Back to top |
|
|
|
|
