| Author |
Message
|
| neilgc |
 Posted: Tue Jul 30, 2002 1:28 am Post subject: Maximum Message Size |
 |
|
Novice
Joined: 03 Jul 2002
Posts: 20
Location: London
|
We have setup an MQSeries environment in a hub & spoke configuration with our hub also running MQSI to allow message manipulation. We have only moved a few projects over to using this architecture so far with the last project to go live requiring the ability to transmit messages up to 10MB in size. To cater for this all Queue Managers, Queues, Channels used by this flow have been set to support 10MB messages. We have now been informed that a new project is to be started that uses the same Queue Managers, and Channels (but different Queues) that requires the ability to support a small number of messages up to 30MB in size.
Can anyone tell me what the downsides are to setting the Queue Managers and Channels to having a maximum message length of 100MB are? |
|
| Back to top |
|
 |
| bduncan |
| Posted: Tue Jul 30, 2002 6:10 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
There aren't many downsides except the obvious ones, slower throughput (in number of messages) longer MQGET times, etc., however, these differences are not disproportionate in relation to having larger numbers of smaller messages. So as long as your queue managers have enough hardware to support the larger messages in memory, on disk, etc., you should be fine...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 30, 2002 6:25 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well depending on platform the only issue I see and it's not really a downside but a issue that has to be taken care of.
With a channel to set to handle 100mb messages and you start it up it will
create 100mb buffer to hold messages and so will the agent process.
So you will go through ram quickly (200mb per channel) This assumes you are not running trusted(fastpath) channels then it only be 100mb per channel.
On HPUX you will hit an issue with a Kernel parm MAXDSIZ which I know by default is less than 100mb, which means it will need to be changed.
MAXDSIZ is the maximum data segment size for a process data.
Iam not sure about other versions of UNIX, but they probaly will have a similar parm.
This problem will show itself with Reason Code = 2071.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| neilgc |
| Posted: Tue Jul 30, 2002 7:03 am Post subject: |
|
|
Novice
Joined: 03 Jul 2002
Posts: 20
Location: London
|
Probably should have mentioned we're making use of clusters.
Does this 200MB memory requirement apply for just the single Cluster Channel definitions or does it apply to the Automatic Cluster definitions. i.e. we have a hub cluster that is able to connect to 2 other clusters. The hub therefor has a Cluster Sender/Receiver declared supporting 100MB messages, do we therefore use 200MB in total? or do we use 200MB for each automatic Cluster Sender/Receiver, therefore totalling 400MB?
One final thing, when you talk about 100MB for the agent are you referring to the Cluster Receiver as I've assumed above?
Thanks in advance, comments have been very useful (if somewhat worrying). |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 30, 2002 7:21 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
If you are not using trusted(fastpath) channels then the channel program doesnt communicate directly to the queue manager there is a process called an agent which acts as a go between the channel program and the qmgr(This is same for ALL MQ applications excluding trusted) .
This is to prevent a poorly written application from corrupting and destroying the queue manager
process name amqzlaa0 it will handle multiple applications(20 by default)
the qmgr will launch more as needed.
For each channel pgm that opens up the xmitq and pulls data of it will create 100mb buffer, plus the agent will also create 100mb buffer for each
channel.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jul 30, 2002 7:25 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Also any apps that you create to MQGET/MQPUT a 100mb message will require your app and the agent to create 100mb buffer each.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 30, 2002 7:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Be careful of the big message app affecting the little guys, especially if they are time sensitive, since you said you would use the same channels.
If the big app drops a few 30 meggers on the remote queue right before your little app drops its request that requires a reply in 2 seconds, be aware that the little message now waits its turn behind the big messages.
You might want to implement "heavyduty" channels to be used just for big messages between the hub and the spokes and then define another pair of "express" channels for each spoke to be used for all other lightweight messaging that is time sensitive.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 31, 2002 8:59 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Good point. 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
