| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to find negotiated MAXMSGL for client channel |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Thu Jan 27, 2022 6:06 pm Post subject: How to find negotiated MAXMSGL for client channel |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
On our MQ server, we defined a QMGR with MAXMSGL set to 104 MB, and also defined a SVRCONN channel with MAXMSGL set to 104 MB. And on our application server we created a JSON CCDT file to connect to the QMGR, but we did not specify the "maximumMessageLength" there. That setup has worked well for most of our applications, for a while now.
However, we recently ran into an issue with our latest application, where all of the MQGETs fail, due to an MQRC_DATA_LENGTH_ERROR. This application uses a much larger BufferLength than our previous applications did, and we suspect it exceeded the negotiated maximum message length for the client channel. We set the "maximumMessageLength" to 104 MB in the JSON CCDT, and that resolved the immediate issue.
But we still don't know how to figure out what the negotiated maximum message size is for a client channel. I had assumed that if the CCDT does not define the maximum message length, then it would default to the SVRCONN value, but apparently it does not. I'm also assuming that if the CCDT value matches the SVRCONN value, then it would default to that, but I don't know how to confirm that either.
Is there some runmqsc command for that? Or any documentation for how that value gets negotiated? I couldn't find much about that in the Knowledge Center, but that probably would have made it easier to troubleshoot.
Thanks, |
|
| Back to top |
|
 |
| EnigmaticCypher |
| Posted: Sat Jan 29, 2022 7:21 pm Post subject: |
|
|
Newbie
Joined: 01 Jan 2022
Posts: 5
|
First off, max message length is limited to the base 2 value for 100 MB, which is 104,857,600 bytes. I suspect that's where you're getting 104MB from, but just wanted to clear that up.
Second, the max message length parameter page in the IBM documentation clearly explains how that negotiation works:
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=order-maximum-message-length-maxmsgl
To quote the relevant paragraph:
| IBM Docs wrote: |
| Because various implementations of IBM MQ systems exist on different platforms, the size available for message processing might be limited in some applications. This number must reflect a size that your system can handle without stress. When a channel starts, the lower of the two numbers at each end of the channel is taken. |
Now, when you don't specify the max message length in a JSON CCDT, (or indeed a normal channel definition in a regular CCDT), IBM MQ will default the max message length to the base 2 value for 4 MB. Therefore, per the bolded section of the paragraph, your negotiated length would've been 4 MB, hence causing the data length error you observed.
To prevent this occurring, make sure you set max message length on both ends, or ideally, send smaller messages  You will get far better performance if you send many messages that are within 2 KB -> 200KB, vs sending a very large 20 MB message for example. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Sun Jan 30, 2022 2:57 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I agree completely that sending 100MB messages from a client should be avoided if possible. Not least of which because it is a huge re-send cost if you lose your connection. However, if you really, really, really need to send large amounts of data then I don't agree that your best option is to send it as 2KB chunks. Even 200KB may be a little small. A lot depends on the exact set up, round trip times, TCP settings, bandwidth etc but generally speaking MQ doesn't have to do anything awkward until you send more than 1MB so I would say if you really need to send 100MB then send it as 100 x 1MB message. As I say your exact speed will change depending on the environment so it is worth doing some testing and writing your application so none of this is hard coded. Generally speaking though you want to avoid both really large messages and lots and lots of small messages.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sun Jan 30, 2022 9:27 pm Post subject: Re: How to find negotiated MAXMSGL for client channel |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Thanks for the responses, but I still have some questions ...
| EnigmaticCypher wrote: |
| First off, max message length is limited to the base 2 value for 100 MB, which is 104,857,600 bytes. I suspect that's where you're getting 104MB from, but just wanted to clear that up. |
Ok, ... approximately 104 MB, then. Or, exactly 100 MiB. We don't control the server-side channel parameters. The client applications typically uses a much, much smaller BufferLength anyway, otherwise we would have encountered this MQRC_DATA_LENGTH_ERROR long before now.
| EnigmaticCypher wrote: |
Second, the max message length parameter page in the IBM documentation clearly explains how that negotiation works:
...
| IBM Docs wrote: |
| ... When a channel starts, the lower of the two numbers at each end of the channel is taken. |
|
But if I don't know what one of the two numbers is, then what? The page also states that "You can use a maximum message size of 0 which is taken to mean that the size is to be set to the local queue manager maximum value." But what does "local queue manager" mean for a client using a JSON CCDT? If I omit the "maximumMessageLength", then is that the same as setting it to 0? If so, then why wouldn't it use the server-side queue manager maximum value (100 MiB)?
| EnigmaticCypher wrote: |
| Now, when you don't specify the max message length in a JSON CCDT, (or indeed a normal channel definition in a regular CCDT), IBM MQ will default the max message length to the base 2 value for 4 MB. |
And where did that value come from? Does IBM document this somewhere? Binary CCDTs don't omit values; they use SYSTEM.DEF.CLNTCONN to fill in the blanks, (and IBM documents that). But I can't find similar documentation for JSON CCDTs.
If both ends of the channel define a maximum message length, and if nobody modified those values after launching a given client application, then I could probably guess what the negotiated value is. But can I run some command instead, to look up the actual runtime value, without guessing?
| EnigmaticCypher wrote: |
| To prevent this [data length error] occurring, make sure you set max message length on both ends, or ideally, send smaller messages ... |
We resolved the error, but it just took a little while longer, because we couldn't find what we were looking for in the documentation. |
|
| 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
|
|
|
|
