|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ Server Library vs MQ Client Library ? |
« View previous topic :: View next topic » |
Author |
Message
|
olivieer |
Posted: Wed Nov 17, 2004 7:47 am Post subject: MQ Server Library vs MQ Client Library ? |
|
|
Newbie
Joined: 17 Nov 2004 Posts: 5
|
Hi, I'm new in using MQ Series.
I have a MQ Server running on UNIX.
And I have to develop a soft that send/receive message in C++.
What should be the best thing to do :
1) Put the program on the computer hosting the MQ Server and link with the server library
2) Put the program on an other computer and link with the client library.
Is there any problem or limit using the client library ?
Thanks for the help
Olivier |
|
Back to top |
|
 |
kirani |
Posted: Wed Nov 17, 2004 9:27 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
It depends ... you can choose either option. Each one of them have its own Pros/Cons. Take a look at WMQ Clients manual to see the restrictions of using Client libraries. From performance standpoint, it will be slower than server bindings. _________________ Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
Back to top |
|
 |
jsware |
Posted: Wed Nov 17, 2004 9:32 am Post subject: |
|
|
 Chevalier
Joined: 17 May 2001 Posts: 455
|
The only "real" difference is that with the client, you can't coordinate MQ transactions with another resource such as a database. This *doesn't* stop you using local transactions that involve operations with the queue manager on its own. With both client and bindings mode connections, to assure you don't lose messages, you must use syncpoint and persistent messages. If you don't mind losing a message during adverse conditions (network blip, host/app failure etc) then using non-persistent messages without syncpoint can improve things (though I have seen better performance when using syncpoint on some platforms).
Other than that the APIs are the same. The only thing that clients add is the network as an additional point of failure (mq failure/your app failure still remain with both modes of connection).
However, with clients, you have to consider that you have a network connection to the qmgr which may be *more* prone to failure than a locally bound connection. Therefore you are more likely to receive RC 2009 (connection broken) than with a local connection (though it is still theoretically possible with a local connection). Recovery logic from a broken connection can get quite complex (e.g. what do you do if you get connection broken when doing an MQCMIT call? You don't know whether the commit worked on the server and then the connection broke before the server could say to your client, committed OK, or it broke before the commit actually made it to the server and will be backed out automatically). For this reason alone I would not recommend a long running client connection over a wide area network.
The other things to consider are from a more operational point of view. You may find server connection channels floating around after a restart if your qmgr is recycled and your applications are not recycled in a coordinated fashion. This depends mainly on your applications behaving nicely with MQ (which I am sure you will do as a good programmer!) There are also maximum connection limits which, if your app runs away creating new connections can stop other channels from working (they all share the same max connections limit). This can be handled by adding a channel exit to limit the number of instances of a server connection channel from running.
Also, using MQClient to connect to a single MQServer can be cheaper than having multiple MQServers because MQClient doesn't cost, but MQServer does. _________________ Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
Back to top |
|
 |
olivieer |
Posted: Thu Nov 18, 2004 12:18 am Post subject: |
|
|
Newbie
Joined: 17 Nov 2004 Posts: 5
|
Thanks a lot for the reply |
|
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
|
|
|
|