| Author |
Message
|
| dhakshinabalu |
 Posted: Thu Oct 20, 2005 5:49 am Post subject: Maximum Size of the MQ message[Each Message Consists of File |
 |
|
Novice
Joined: 31 Aug 2004
Posts: 20
Location: Toronto
|
Hi
I would like to know what is the Max Size of the Message
As per Configuration it Maximum Message Length 4194304 Bytes , is it any way increase the size of the message in the Queues.
If we can increase the Size of the Message , how to increase the size
please guide me
regards
DAKSHIN 
_________________
dhakshinabalu |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 20, 2005 5:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think this is clearly documented.
Good luck!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dhakshinabalu |
| Posted: Thu Oct 20, 2005 5:52 am Post subject: |
|
|
Novice
Joined: 31 Aug 2004
Posts: 20
Location: Toronto
|
| jefflowrey wrote: |
I think this is clearly documented.
Good luck! |
where it is documented , I am not MQ Savy, but only knew 4190KB
what if we need Big Size message.
_________________
dhakshinabalu |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 20, 2005 6:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| dhakshinabalu wrote: |
| where it is documented |
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp
| dhakshinabalu wrote: |
, I am not MQ Savy, but only knew 4190KB
what if we need Big Size message. |
Then you will have to become MQ savvy.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dhakshinabalu |
| Posted: Thu Oct 20, 2005 6:30 am Post subject: |
|
|
Novice
Joined: 31 Aug 2004
Posts: 20
Location: Toronto
|
Thanks jeff
I am using MQ 5.3, as per MQ6.0 documentation says
On WebSphere MQ for AIX, WebSphere MQ for iSeries, WebSphere MQ for HP-UX, WebSphere MQ for Linux, WebSphere MQ for Solaris, and WebSphere MQ for Windows, the MaxMsgLength defaults to 100 MB (104 857 600 bytes).
so 100 MB, is it same applicable to MQ 5.3?
regards
_________________
dhakshinabalu |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 20, 2005 6:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| ashoon |
| Posted: Thu Oct 20, 2005 7:00 am Post subject: why not use segmentation??? |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
why send large messages instead of breaking it down into smaller sizes?
To quote another board member...
| Quote: |
1 70 MEG message or 700 1 MEG messages. While the end result is the same, consider moving this data between 2 QMs. The 70 Megger will take a bit of time to be moved across the channel, during which time no other messages can be shipped. Whereas the 70 1 Meggers would allow the possability of other messages to be intermingled and not delayed.
Also, consider what happens for the channels batch processing. If the channel batch size is set to the default of 50, and your channel sends of few of those 70 Meggers in a batch, it will take along time to backout if it needs to. If the app puts the messages fast enough to the XMITQ so that the Batch Interval doesn't get a chance to tell the channel to end the batch, now you got a batch of 50 70 Meg messages = 3.5 GIG = getting close to exceeding your log space if you happened to make them as big as possible.
If there are other applications using these QMs to ship messages, and they are significantly smaller, and time sensitive, then this is one of the few times that multiple channels between 2 QMs makes sense. Make a second "FAT" channel, that will be used to ship these huge messages. Meanwhile the regular channel can quickly move the smaller messages.
When a channel is moving a very large msg it needs to allocate a lot of heap memory, to read the msg from the queue, and possibly to convert it as well. If the heap memory is not available to the process then the channel will fail.
I suggest that if you need large msgs you enable msg segmentation so that the msgs are stored and transmitted as msgs of the max msg size, but can be put and got as complete msgs with the appropriate MQPMO and MQGMO options. |
|
|
| Back to top |
|
|
| dhakshinabalu |
| Posted: Thu Oct 20, 2005 7:31 am Post subject: Re: why not use segmentation??? |
|
|
Novice
Joined: 31 Aug 2004
Posts: 20
Location: Toronto
|
| ashoon wrote: |
why send large messages instead of breaking it down into smaller sizes?
To quote another board member...
| Quote: |
1 70 MEG message or 700 1 MEG messages. While the end result is the same, consider moving this data between 2 QMs. The 70 Megger will take a bit of time to be moved across the channel, during which time no other messages can be shipped. Whereas the 70 1 Meggers would allow the possability of other messages to be intermingled and not delayed.
Also, consider what happens for the channels batch processing. If the channel batch size is set to the default of 50, and your channel sends of few of those 70 Meggers in a batch, it will take along time to backout if it needs to. If the app puts the messages fast enough to the XMITQ so that the Batch Interval doesn't get a chance to tell the channel to end the batch, now you got a batch of 50 70 Meg messages = 3.5 GIG = getting close to exceeding your log space if you happened to make them as big as possible.
If there are other applications using these QMs to ship messages, and they are significantly smaller, and time sensitive, then this is one of the few times that multiple channels between 2 QMs makes sense. Make a second "FAT" channel, that will be used to ship these huge messages. Meanwhile the regular channel can quickly move the smaller messages.
When a channel is moving a very large msg it needs to allocate a lot of heap memory, to read the msg from the queue, and possibly to convert it as well. If the heap memory is not available to the process then the channel will fail.
I suggest that if you need large msgs you enable msg segmentation so that the msgs are stored and transmitted as msgs of the max msg size, but can be put and got as complete msgs with the appropriate MQPMO and MQGMO options. |
|
Thank you Ashoon
My requirement is different , each message consists of one application
which consists of set of values correponds to that application , I cannot break it out. But data size , right now I am not sure (it is an XML doc)
But at a time 3500 application concurrently send to the queue
regards
_________________
dhakshinabalu |
|
| Back to top |
|
|
| ashoon |
| Posted: Thu Oct 20, 2005 7:43 am Post subject: not sure i follow |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
but what i'm suggesting is logically it's one message but MQ breaks it down into multiple messages to send... vs. having your application actually break-down and re-assemble...
see the application programming guide on message segmentation for further info. |
|
| Back to top |
|
|
| dhakshinabalu |
| Posted: Thu Oct 20, 2005 8:01 am Post subject: Re: not sure i follow |
|
|
Novice
Joined: 31 Aug 2004
Posts: 20
Location: Toronto
|
| ashoon wrote: |
but what i'm suggesting is logically it's one message but MQ breaks it down into multiple messages to send... vs. having your application actually break-down and re-assemble...
see the application programming guide on message segmentation for further info. |
Thanks lot
I have one question where is DeadLetterQueue in my MQ ConsoleRoot
WebSphere MQ Explorer, in the Queue I have seen only
Local Queue, Alias Queue, Model Queue, Remote Queue
regards
_________________
dhakshinabalu |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 20, 2005 8:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Dead letter queue is a qlocal.
It is defined as a property of the queue manager, and can have any name you choose.
The default name most people choose is "SYSTEM.DEAD.LETTER.QUEUE".
There also does not have to be a Dead Letter queue defined at all.
If you do not see any queues named SYSTEM.(anything), then you need to click the little box that will "Show System Queues".
If you do this, and you do not see SYSTEM.DEAD.LETTER.QUEUE, then you should go to WebSphere MQ Services, and look at the properties of your queue manager and find the value for the dead letter queue, and then go look for that queue in MQ Explorer. (caveat, the dead letter queue might be a property of the qm in Explorer, not Services... I've forgotten where it is in v5).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| reddy_kal |
| Posted: Thu Oct 20, 2005 10:37 am Post subject: |
|
|
Acolyte
Joined: 04 Nov 2002
Posts: 73
|
dhakshinabalu,
Just change the Maximum Message Length Property of your local queue to 104857600.
And also make sure your QueueManager Property also changed and try to send big message, it should work.
-Reddy |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Oct 20, 2005 11:24 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
Just change the Maximum Message Length Property of your local queue to 104857600.
And also make sure your QueueManager Property also changed and try to send big message, it should work.
|
Providing it stays inside the local queue manager. 
If it is going to be sent to another queue manager then you need to check the channel attribute for max message length too...and the max message length on the transmission queue. |
|
| Back to top |
|
|
| woodoo2k |
| Posted: Wed Dec 14, 2005 7:27 am Post subject: |
|
|
Apprentice
Joined: 07 Feb 2005
Posts: 28
Location: USA
|
Dakshina,
If you are still looking for the dead letter queue, then click on the button to show system objects on an MQ Explorer windows. Then you should be able to see all SYSTEM objects that includes SYSTEM.DEAD.LETTER.QUEUE. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Dec 14, 2005 4:12 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| Then you should be able to see all SYSTEM objects that includes SYSTEM.DEAD.LETTER.QUEUE. |
Thats always assuming that SDLQ is set as the System dead letter queue.
The queue manager properties is THE place to look. Any queue name can be used (even a remote queue) so your method isn't really that reliable. Just because it is called SDLQ doesn't make it so. |
|
| Back to top |
|
|
|
|
