| Author |
Message
|
| ashoon |
 Posted: Mon Jul 18, 2005 2:21 pm Post subject: MQ Servers vs. Clients |
 |
|
Master
Joined: 26 Oct 2004
Posts: 235
|
Hello all - I'm trying to gather some info. as I've worked on this project where even though they weren't new to MQ they want to use MQ client connections for all their server applications
i.e. they have one central MQ server and run client connections to all of
them.
Since I know inherently that this is not how MQ is meant to work
(i.e. it's meant to be a core part of each server application) I've been
trying to get them off that concept into a distributed queuing concept. Is
there any info. out there as to why an MQ server is better than using a
client? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Jul 18, 2005 2:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
There is nothing wrong with this concept. We have hundreds of app servers and thousands of desktop clients, all with just MQ Client code, connecting to several MQ servers.
It is vastly easier to manage, and hundreds of thousands, no, probably millions of dollars cheaper that putting a full QM everywhere.
Client versus server has been discussed lots of times, try the search button. But 9 ou of 10 times, the free MQ client is all you need.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 18, 2005 3:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There are certain types of applications that require an MQ Server - anything that has a strong business need for globally coordinated transactions (and there are fewer of those than people tend to think or build).
Other than that, there are few reasons to make any distinction between a Client App and a Server app. A good set of library code will handle the finer points of both deployments and protect the casual developer from having to worry about it.
I would not, necessarily, recommend running an entire enterprise on one single queue manager. A certain amount of separation of functions can make a big difference in reliability and maintainability of an infrastructure.
But that said, there might not be need for more than four qms or so - unless the geographic/topographic layout of the business requires or encourages it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 19, 2005 12:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Sharing a queue manager is often the best approach, but make this queue manager as highly available as possible using hardware clustering, RAID disks or SAN etc.
The main reason to have a local queue manager is that an asychronous application can continue to generate messages, without a dependency on the availability of a remote queue manager.
Also if you have a badly designed MQ application that "polls" the queue (one of my pet hates) this will not matter too much with a local QM, but would cause network traffic if it was a MQ client.
The extended transactional client (not free) is yet another option. |
|
| Back to top |
|
|
| Pam |
| Posted: Tue Jul 19, 2005 1:39 am Post subject: |
|
|
Novice
Joined: 10 Dec 2004
Posts: 11
|
Hi Zpat,
"Also if you have a badly designed MQ application that "polls" the queue (one of my pet hates) this will not matter too much with a local QM, but would cause network traffic if it was a MQ client.
"
I have a similar situation where i have to get a message from a Q on MQ Server on another machine using MQ Client.I am planning to use "polling" mechanism with WAIT option (say 60 seconds).Would this cause any network overhead? Is there any better way to achieve the same?
_________________
Pam
IBM Cert. MQ Series System Administrator
IBM Cert. WBI MB System Administrator |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Jul 19, 2005 1:54 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| "polling" with a wait will have network overhead. You'll get network traffic every time that the MQGET ends and the agent running on the server has to notify your client. What will you do when you get this timeout? If the answer is re-issue the MQGET, then you might as well go with an unlimited wait and make sure that you have specified the fail if quiescing option. This will return an error to you when the qmgr shuts down. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 19, 2005 1:56 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Using MQGET with WAIT is the correct approach, and allowing 60 seconds before re-issuing this is fine.
Unlimited wait makes it hard to check for (other) application adapter closedown conditions, so I usually recommend around 60 seconds, check for any locally issued closedown command and then repeat.
It's when the wait is performed in the application code and with more frequent MQGETs that causes both overhead and latency.
However remember that all the MQ client does is operate the MQI remotely over a synchronous channel to the queue manager. MQI calls always execute on the QM itself. |
|
| Back to top |
|
|
|
|
