| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RC 2080 - multiple MQGETs |
« View previous topic :: View next topic » |
| Author |
Message
|
| RogerLacroix |
 Posted: Fri Sep 16, 2011 10:47 am Post subject: RC 2080 - multiple MQGETs |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
All,
I have a customer who is running a JMS application using webMethods via their MQ Adapter with MQ Client v6.0.0.0. When we monitor the queue manager (via API Exit), the JMS application issues an MQGET but the queue manager returns RC of 2080 (MQRC_TRUNCATED_MSG_FAILED) then a second MQGET is issued with the appropriate size for the message and the message is retrieved.
Basically, every MQGET from the JMS application is resulting in 2 MQGETs. The JMS application team says that they are issuing the MQGET via webMethods MQ Adapter. webMethods says their MQ Adapter is issuing an MQGET without specifying a message size. They claim it is the MQ Client library that is issuing the multiple MQGETs and not their code.
The customer says that they upgraded their MQ Client to version 6.0.2.11 but it made no difference.
The initial buffer size is always 4096 bytes for the first MQGET that returns the RC of 2080. Has anyone ever heard of the MQ Client library issuing MQGET of 4096 bytes (browse or destructive) followed by a second MQGET with the correct message size on behalf of JMS application?
We are trying to figure out how to tune this JMS application/webMethods MQ Adapter such that only 1 MQGET is issued.
Any thoughts or comments is much appreciated (I'm not a JMS guru).
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Sep 16, 2011 4:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Should be relatively easy to verify. Write your own JMS stand alone app and see if it behaves the same way (trace).
If it does the problem clearly lies with the MQ code. If it does not the problem is with WebMethods, or with the way it is being invoked, right?
I seem to remember from somewhere that the way this works in JMS is that on the first JMS receive for that destination, you would be seeing the behavior you describe. Is each receive being done against a new receiver / new session?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 16, 2011 5:04 pm Post subject: Re: RC 2080 - multiple MQGETs |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| RogerLacroix wrote: |
| The customer says that they upgraded their MQ Client to version 6.0.2.11 but it made no difference. |
Because its not in the MQ Client code. We have seen this before too, and it was an app using JMS as well. JMS - feh!!!
FJ's suggestion is a good one to prove it, but if the MQ Client did do this double get I think we would have seen it documented in the manuals or in a tech note by now. This app was coded by someone who thought they would be slick by not allocating too big a buffer and if they got the 2080 MQRC, they would reissue the MQGET with the bigger buffer.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 16, 2011 8:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
FWIIW and from what I remember the behavior in JMS follows this rule:
First get on a destination: if memory is not enough, increase and repeat,
second get keep increased memory.
The question then comes if you decrease the memory after n gets with less than 80% usage of the memory or if you keep the memory peak until the receiver is closed... or until the next garbage collection...
You guys are welcome to dig for a technote, but I believe a quick test would be faster...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Sep 17, 2011 1:46 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| fjb_saper wrote: |
| Should be relatively easy to verify. Write your own JMS stand alone app and see if it behaves the same way (trace). |
Yup, I could create a stand-alone JMS app (that is run outside of WebMethods). I don't have access to their queue managers, so it may not be as simple as a simple test.
| fjb_saper wrote: |
| ]The question then comes if you decrease the memory after n gets with less than 80% usage of the memory or if you keep the memory peak until the receiver is closed... or until the next garbage collection... |
Actually, every "first" MQGET is always 4096 bytes, then the second MQGET is exactly the size of the message.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Sep 17, 2011 3:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| RogerLacroix wrote: |
| fjb_saper wrote: |
| ]The question then comes if you decrease the memory after n gets with less than 80% usage of the memory or if you keep the memory peak until the receiver is closed... or until the next garbage collection... |
Actually, every "first" MQGET is always 4096 bytes, then the second MQGET is exactly the size of the message.
Regards,
Roger Lacroix
Capitalware Inc. |
And are subsequent gets after that, assuming the queue is not closed and reopened each time, maintaining the new larger size? I knew this sounded familiar, see the following link
http://www.mqseries.net/phpBB2/viewtopic.php?t=27403&postdays=0&postorder=asc&start=15
And take note of what mvic says on the second page regarding the new larger buffer size being used going forward, as long as you don't keep closing and reopening the queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
