| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CLNTCONN channel in JMS - How is MAXMSGL determined? |
View previous topic :: View next topic |
| Author |
Message
|
| PeterPotkay |
 Posted: Thu Apr 14, 2016 5:35 am Post subject: CLNTCONN channel in JMS - How is MAXMSGL determined? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Looking in MQ Explorer at some Queue Connection Factories, I do not see any place to specify the MAXMSGL. How is this value determined then?
I always thought MQ Client channel got the smaller of the CLNTCONN’s MAXMSGL and the corresponding SVCRCONN’s MAXMSGL, they would auto negotiate and settle on the smaller of the 2. But if there is no place to set this in the QCF on the JMS side, how do you get a value larger than the default of 4 MB if the SVRCONN channel’s is already set to > 4 MB?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Apr 14, 2016 7:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 14, 2016 7:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you follow the link to Properties of IBM MQ classes for JMS objects in the link mqjeff provided, it does not look like there is a property that controls the max message size.
That's it, PMR time! I will report back.....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 14, 2016 7:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Wrong page.
I meant go to the link I posted and go to the section called "Setting the properties of IBM MQ Classes for JMS objects".
Code :
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(JmsConstants.WMQ_PROVIDER);
JmsConnectionFactory factory = ff.createConnectionFactory();
factory.setIntProperty(MQIA_MAX_MSG_LENGTH,104876);
Or something like that.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 14, 2016 8:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Right, I did go that page. Since I don't know what all the available properties are, I needed a reference, which was conveniently provided by IBM right there, the link I posted.
If your code would work, I'm guessing its an undocumented feature.
At this point I'm more curious what the value is if the app doesn't set it.
PMR is open..... official news soon.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 14, 2016 10:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The page I went to showed setting standard MQ Java class properties, not JMS MQ Properties.
That's why I put in the bit about MQIA...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 15, 2016 4:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I got some good info from the PMR. Short answer is JMS has no limit, so there is no client side limitation to the MQ Max Message size when the client is JMS. Under the covers the MQ API calls are trying to be as efficient as possible with the size of the buffer being used, starting small and flexing as needed based on the message sizes encountered. They did provided a way to limit the MQ Max Message size on the JMS client side with a JVM property http://www-01.ibm.com/support/docview.wss?uid=swg1IV09144
I did ask for a TechNote (preferred) or a DWAnsweres post with this info so we can refer people to it.
Full response from L3 in the PMR:
| Quote: |
“I am not aware of any documentation within the Knowledge Center which details
the maximum size of a message which can be received or put with the MQ
classes for JMS - which is likely because there is no such client side limitation.
The documentation describes the various limits for components which have them
- but does not reference unlimited aspects which you can probably imagine would
be quite a big set!
When Chris was referring to the 4KB default buffer size, he was talking about the
underlying MQ-API which is being used by the MQ-JMS classes to communicate
with the queue manager.
If you are familiar with the MQ API, you may be aware that when requesting a
message from the queue manager a buffer size is provided for the message to
be placed into.
When using the MQ-JMS classes, this same MQ API is used, but the MQ-JMS
classes hide away the inner workings of the API from the JMS application. By
default, the MQ-JMS classes internally will start with a 4KB buffer, and if the
message is larger, they will perform a second get operation with a resized buffer.
This can have an impact on the performance of the system - as that second stage
get is specific to the message which was seen on the first stage. If another
application has removed that message in between the two stages, and the queue
depth is high (eg. 10,000+ messages), there can be a detrimental effect on the
performance of the queue manager as it attempts to locate the removed message
on the queue.
In this circumstance, a MQRC 2033 'MQRC_NO_MSG_AVAILABLE' is returned
to the MQ-JMS classes, which then must recalculate the remaining time left on
the message consume as specified by the requesting JMS application, and
potentially return to the queue manager again to request another message.
To mitigate this performance impact, the buffer size used by the MQ-JMS classes
stays at the larger size when a larger message is found for a number of message
consumes of smaller messages.
For example, if a 500KB message is found on the queue, the buffer is resized to
500KB, and remains at 500KB for the following requested messages which the
JMS application makes on that MessageConsumer object instance.
If a number of smaller messages are then consumed, for example 10 messages
at 5KB following on from the large message, the MQ-JMS classes will downsize
the buffer to 5KB, and so on.
However, returning to your original question - the JMS API has no concept of a buffer
size. If an application requests a message using for example:
javax.jms.MessageConsumer.receive()
it will receive a message from the queue of any size. All of the internals of resizing
the buffer are kept hidden from the JMS application - hopefully making the application
programming task much simpler! The maximum message size is still limited by the
queue manager of course, eg. 100MB maximum limit, then further restricted by the
queue property 'MAXMSGL', the queue manager property 'MAXMSGL' and the channel
property 'MAXMSGL'.
I would recommend that you don't do the following, in the interests of keeping things
simple and at the default values, but if you would like to control this internal buffer size
you can do using the JVM environment property:
com.ibm.mq.jmqi.defaultMaxMsgSize
which was introduced under APAR IV09144 to assist with tuning your system. More
information about this property can be read in the APAR description:
http://www.ibm.com/support/docview.wss?uid=swg1IV09144
”
|
_________________
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
|
|
|
|
