| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMQ Client |
« View previous topic :: View next topic » |
| Author |
Message
|
| suchi_sundar |
 Posted: Tue Sep 19, 2006 9:08 am Post subject: WMQ Client |
 |
|
Newbie
Joined: 11 Sep 2006
Posts: 5
|
Hi all,
We are considering installing one MQ server and having MQ client installed on the other machines. I have some questions regarding this
1. Is there a limit on the number of clients which can connect to a server?
2. If the application side has a server installed instead of a client what are the benefits accrued?
3. The max queue depth and max message length are features of a queue manager and so theoretically speaking having a client or server on the application side and having it connect to a remote server should not cause any issues. But from a practical standpoint is the client any less robust than a server when it comes to supporting huge messages?
4. What are the actual (from a practical standpoint) figures for the max queue depth and max message length for an MQ client connecting to a remote server?
If any of you can provide me answers to these questions it would really be great.
Thanks and Regards,
Suchitra |
|
| Back to top |
|
 |
| Hassan |
| Posted: Tue Sep 19, 2006 9:23 am Post subject: |
|
|
Voyager
Joined: 01 Apr 2004
Posts: 81
Location: Toronto, Canada
|
Suchitra jee,
1. Is there a limit on the number of clients which can connect to a server?
Simple answer is no there are no limits .... but you would have to take into account the network adapter's capacity, server's CPU power, memory, etc.
Plus off course what the clients intend to do after connecting.
2. If the application side has a server installed instead of a client what are the benefits accrued?
You'll have to a little reading yourself to understand. This will completely depend on the application design and purpose.
3. The max queue depth and max message length are features of a queue manager and so theoretically speaking having a client or server on the application side and having it connect to a remote server should not cause any issues. But from a practical standpoint is the client any less robust than a server when it comes to supporting huge messages?
Again, this will completely depend on the application design and purpose.
4. What are the actual (from a practical standpoint) figures for the max queue depth and max message length for an MQ client connecting to a remote server?
I don't know what you mean here but I guess if you do some reading this may get clarified on it's own.
Cheers! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 19, 2006 9:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Maximum Message Length is a property on three kinds of objects - queue managers, queues, and channels.
The maximum message length that can be used by a client application is the minimum of all applicable maxmsgln properties on all objects being used - qmgr, queues, channels.
Client applications use two channel definitions to talk to the server.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 20, 2006 7:11 am Post subject: |
|
|
Guest
|
MaxQueueDepth and MaxMessageLength values are application-dependent; and should be set to some 'reasonable' values (rather than the defaults) to meet application requirements. At the queue, both values affect (constrain) disk space usage - especially by misbehaving applications.
For example, for a payroll application with 2000 employees, each submitting one timecard: I'd probably use maxqueuedepth of 5000 - allowing all employees to submit incorrect timecards, then resubmit, plus some additional space for new hires.
Maxmsglength should reflect the maximum size of the actual message the application puts to the queue.
At the QueueManager, maxmessagelength affects the channels, as both ends negotiate to the lowest maxmessagelength value. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 20, 2006 7:28 am Post subject: |
|
|
Guest
|
MaxQueueDepth and MaxMessageLength values are application-dependent; and should be set to some 'reasonable' values (rather than the defaults) to meet application requirements. At the queue, both values affect (constrain) disk space usage - especially by misbehaving applications.
For example, for a payroll application with 2000 employees, each submitting one timecard: I'd probably use maxqueuedepth of 5000 - allowing all employees to submit incorrect timecards, then resubmit, plus some additional space for new hires.
Maxmsglength should reflect the maximum size of the actual message the application puts to the queue.
At the QueueManager, maxmessagelength affects the channels, as both ends negotiate to the lowest maxmessagelength value. |
|
| 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
|
|
|
|
