| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| JMS Always Browses? |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Mon Feb 20, 2006 5:49 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
I don't know if that will help with the 4k but I would think that if you up the heap some you might get more efficient memory management and gain "a little" time...
Let us know. 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| mvic |
| Posted: Tue Feb 21, 2006 10:10 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| PeterPotkay wrote: |
| Question remains though (I think the answer is no) on is there a way to up the 4K buffer if you know ahead of time the messages are bigger than 4K, to avoid the browse or selective destructive get that's gonna fail with MQRC_TRUNCATED_MSG_FAILED. |
I would expect the 4 Kb to be used for a given com.ibm.mq.MQQueue object until a message larger than this is received. At this point a larger size should be set internally within the MQQueue object, and this larger size should be used for the MQGET calls thereafter.
Question: is the same MQQueue object used each time round the loop? if not, this would explain why the increased size is not remembered. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 21, 2006 10:15 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
| I don't know if that will help with the 4k but I would think that if you up the heap some you might get more efficient memory management and gain "a little" time... |
Compared to the time for an MQI turnaround (could be several ms across a network) a speedup of memory management would probably not be visible. Don't know for sure, and it's system and load dependent, but I'd expect the benefit from improved memory management to be less than 0.01 ms. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 21, 2006 12:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Changing the Correl ID selector to prepend "ID:" turned the browse into a destructive MQGET with a Correl ID filled in.
After speaking with the app, I found out they do in fact open and close the queue for each message (don't ask), so that must explain why every new MQGET always had a 4K buffer according to mvic's explanation.
Should have included MQOPENs and MQCLOSEs for my Transaction Vision data collection right off the bat.
So we changed a Browse/Browse/Get to a Get/Get by using ID:, but due to application design, we can't get it down to a single get. Regardless, much more time is spent in the app, and opening and closing the queue than on the repreated get anyway.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
