| Author |
Message
|
| squidward |
 Posted: Fri Mar 27, 2009 7:37 am Post subject: Recommend WMQ Server or Client in this case? |
 |
|
Novice
Joined: 27 Mar 2009
Posts: 10
|
First a general question: are there a set of guidelines available as to when a client installation should be used vs. server. I searched a bit through the forums and couldn’t find anything useful. My IBM contact said to never use client connections because they are less reliable, but I am thinking there should be a more nuanced set of rules.
Second, does anyone have a specific recommendation for my case:
I am adding a new integration point to an existing MQ infrastructure. The new point is SAP PI running on Linux VM, using the PI JMS/MQ connector. The connector can run in client or bindings mode. I believe the connector requires a constantly open MQ connection, but I am still verifying this.
PI will be exchanging messages with an existing MQ v6.1 queue manager on AIX. The AIX queue manager is in Kansas City, PI is in Denver, and there will be 60MB channel open between them.
Volumes are 30 messages/minute avg and 60 peak. Message size is 5k. Only simple Puts and Gets are required, no pub/sub, no clustering, nothing complex.
I am really hoping a client connection is sufficient, for the cost and administration reductions.
Thanks in advance for any input.
Last edited by squidward on Mon Mar 30, 2009 10:20 am; edited 1 time in total |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Mar 27, 2009 7:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Quote: |
| My IBM contact said to never use client connections because they are less reliable |
I'm sure he did...cha-ching! on the licensing 
If it's simple PUT/GET, and the application can recover from broken connections, and the application can do the necessary reconciliation, from the information you've given, I can't see an issue with using client.
No warranty is implied etc. etc. 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| ashoon |
| Posted: Fri Mar 27, 2009 7:45 am Post subject: my notes on client vs. local connections |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
The are 2 major differences when comparing MQserver and MQclient:
1. Licensing
2. Functionality
Licensing
MQclient is free and can be download from the web. It is a supportpac, supported under IBM standard T&Cs SW agreement provided you have MQserver licensing. If you encounter a defect with the MQclient and you have a current license for MQserver, you may reporting the problem via the same defect reporting channel you would use for MQserver.
So to answer your question customers dont run MQclient on its own they need to connect to an MQserver QM and thus MQclient is supported provided you own an MQserver license.
Functionality
1) To ensure data integrity between a queue and an XA database, applications running on a server can exploit the transaction coodination feature of MQ. To ensure data integrity between a queue manager and a database on a client, the client application needs to be designed appropriately, and recovery code has to be developed.
2) If a server application fails, the queue manager is told immediately by the operating system, and it can initiate recovery procedures. If a client fails, the server is not informed (and vice versa); there are heart beat processes that can be used to speed up the detection process. (assured once-once-only message delivery).
3) Applications running on a server depend solely on the availability of the server, including hardware, the OS etc. Applications running on a client depend on the availability of the remote server, the client system, and the communications (software, LAN, WAN etc) between them.
4) Server applications access queues on a local system, so responses to MQ calls will be at 'local' speeds since this is done in memory. MQ calls from client applications need to be sent to the remote server, processed and then the response sent. This is important when the sender has more processing power than the recieving application.
5) The channel between servers (the MCA channel) can be optimized for the transmission of batches of messages; messages can flow concurrently with the execution of applications processing those messages. The client-server channel (MCA channel) is designed to handle the MQ API; all calls are synchronous; data does not flow while the application is executing. Also you must code for and handle recovery to ensure message integrity.
6) Network recovery especially when there are a large number of clients. Ex. on ZOS, VTAM takes longer to recovery with the more client connections...
Connecting to a WebSphere MQ queue manager as a client has limitations. A network connection is placed between the application and the queue manager, which has performance implications, especially over longer distances. This also requires that a network connection is available in order for the application to operate. The interaction between the application and the queue manager over that network connection is synchronous, although WebSphere MQ manages that connection for the application.
- is clients available on the platform (some platforms like os400/zOS only support MQ servers) therefore if it's one of those platforms I put servers
- is this an XA transaction - if XA support is required then I put servers
- is there a large distance between endpoints - if yes MQ Servers
- is the network unreliable between endpoints - if yes - MQ servers
- is the amount of data being transferred large - if yes - MQ servers
- is fast throughput required - if yes MQ Servers
- is MQ clustering a requirements - if yes MQ Servers
_________________
IBM Certified - SOA Solution Designer & WebSphere Datapower SOA Appliances |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Fri Mar 27, 2009 8:04 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Good info Ashoon..thanks.
| Quote: |
| If it's simple PUT/GET, and the application can recover from broken connections, and the application can do the necessary reconciliation, from the information you've given, I can't see an issue with using client. |
Yes. The applications should properly close and disconnect from the QMgr when connecting via Client. Otherwise the max connections/ max channels will be reached which will lead to lack of resources.
| Quote: |
| Volumes are 30 messages/minute avg and 60 peak. Message size is 5k. Only simple Puts and Gets are required, no pub/sub, no clustering, nothing complex. |
You can upgrade your QMgr to MQ version 7 which is of no licensing cost.
With version 7 client the performance is almost like a MQ server(thats what the IBM doc is saying)...http://www-01.ibm.com/software/integration/wmq/v7/
Thanks. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Mar 27, 2009 9:19 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I take the view that a client connection should be used whenever possible. Not only for cost but avoidance of having to manage yet another queue manager.
Clients pulling messages from the same queue is a very easy and scalable form of load-balancing and failover (with no orphan messages).
Client applications needs to be written with re-connection logic but nothing that isn't general good practice. You can always move client applications to become server applications later.
The queue manager used by clients should ideally be dedicated to this purpose (unless a mainframe) and highly available.
You can control connection limits by IP address in MQ V7 to avoid the connections maxing out but again good coding will prevent this.
Quality control of client applications is essential to make sure they exhibit correct MQI behaviour so it helps to provide some coding guidelines to developers.
In a well controlled development environment client apps can be very successful. My last company had thousands of client apps (including on desktops) and around 30 queue managers. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 27, 2009 9:25 am Post subject: Re: my notes on client vs. local connections |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ashoon wrote: |
- is this an XA transaction - if XA support is required then I put servers
- is there a large distance between endpoints - if yes MQ Servers
- is the network unreliable between endpoints - if yes - MQ servers
- is the amount of data being transferred large - if yes - MQ servers
- is fast throughput required - if yes MQ Servers
- is MQ clustering a requirements - if yes MQ Servers |
Extended Transactional Client gives XA capability to an MQ Client without having to admin a QM (ETC is not free).
"Large distance" is a relative term. Its more about the network performance rather than the number of miles seperating the 2 endpoints. A flaky network connecting 2 points 10 miles apart is worse than a solid network connecting 2 points 100 miles apart.
large amount of data - again, a very relative term. 1 MB maybe large to you, and small to me. MQ Clients can move the same size messages as QM to QM connections.
fast throughput - yes, an MQPUT to a local QM in bindings mode will be faster than an MQPUT to a QM via MQ Client. But make sure you add in the time it takes for your local QM to send the message to the final QM, versus just client connecting to the final QM. And what is "fast". 1 millisecond is 50% faster than 2 milliseconds - wow! But if your app only needs 500 millisecond response times, who cares?
MQ Clients can connect to clustered Queue Managers just fine.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Mar 29, 2009 2:59 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
A big point for me in making these sorts of recommendations is as was pointed out very early on,
The ability of the client to handle broken connections (mqrc=2009 etc)
In many cases, I have found clients sorely lacking in this area. Error handling in the code has been almost non existent.
In some situtions, it was far cheaper for the client to shell out for a WMQ Server license than spend lots more $$$,££££ etc in fixing a badly designed client especially in cases where the Client vendor could even be bothered to fix it....
Take a look at the client code, test it, break it and then come to an informed decision.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Mar 29, 2009 7:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And don't forget even a bindings app connecting to a QM on a local machine can get a MQRC 2009.
The area where clients are more vulnerable is when doing an MQCMIT. If that call returns a MQRC 2009, did your connection break before your MQCMIT made it up to the QM? Or did the MQCMIT execute successfully but the connection broke before the MQRC 0000 was able to be sent to you? This possibility is greater for MQ Clients due to network latency. Its greatly, greatly reduced, but I don't know if 100% eliminated, for bindings apps.
You can deal with a 2009 on most other MQ APIs. MQOPEN gets a 2009? Big deal - reconnect and re-open. MQPUT with syncpoint gets a 2009? No problem - the message has not been committed, put it again. Same for MQGET under syncpoint. But getting a 2009 on a MQCMIT always leaves you in a tough spot wondering what really happened.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 30, 2009 9:43 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| smdavies99 wrote: |
A big point for me in making these sorts of recommendations is as was pointed out very early on,
The ability of the client to handle broken connections (mqrc=2009 etc)
In many cases, I have found clients sorely lacking in this area. Error handling in the code has been almost non existent.
In some situtions, it was far cheaper for the client to shell out for a WMQ Server license than spend lots more $$$,££££ etc in fixing a badly designed client especially in cases where the Client vendor could even be bothered to fix it....
Take a look at the client code, test it, break it and then come to an informed decision. |
MQRC 2009..connection broken will happen in both cases, Client and Binding mode.
What I have experienced is: reaching the max connections and reaching max channels. These are the major issues with the clients.
If the app doesn't disconnect from the QMgr and the app is recycled for some reason, the max channels is reached is getting. If we keep the KEEPALIVE=YES, after 2 hours, the orphaned channels will be closed.
If the app is using SYNCPOINT, it should Commit the transaction. Otherwise the max connection will be exceeded.
Thanks. |
|
| Back to top |
|
|
| squidward |
| Posted: Mon Mar 30, 2009 10:41 am Post subject: |
|
|
Novice
Joined: 27 Mar 2009
Posts: 10
|
Wow thanks for the detailed responses.
Another tidbit is that the new endpoint is a 64 bit environment, and looking at the IBM docs it seems bindings is not supported in 64 bit. So looks like we will be going with client. Only question is if its a local client connection or across the network. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Mon Mar 30, 2009 10:55 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| squidward wrote: |
| looking at the IBM docs it seems bindings is not supported in 64 bit. |
Please provide a link to this.... its a new one on me!
Last edited by WMBDEV1 on Mon Mar 30, 2009 11:01 am; edited 1 time in total |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 30, 2009 10:56 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| squidward wrote: |
Wow thanks for the detailed responses.
Another tidbit is that the new endpoint is a 64 bit environment, and looking at the IBM docs it seems bindings is not supported in 64 bit. So looks like we will be going with client. Only question is if its a local client connection or across the network. |
You mean Binding is not supported on 64 bit QMgr?. From version 6 onwards the QMgr is of 64 bit only and Binding is supported on 64 bit QMgr.
Thanks. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Mon Mar 30, 2009 11:04 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Quote: |
From version 6 onwards the QMgr is of 64 bit only and Binding is supported on 64 bit QMgr.
Thanks. |
This is new to me also! The 32 bit QM still exists in V6 unless you can prove to me otherwise..... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 30, 2009 11:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Sam Uppu wrote: |
| What I have experienced is: reaching the max connections and reaching max channels. These are the major issues with the clients. |
Major issue with poorly written MQ Client apps. Its not a problem inherint in all clients.
| Sam Uppu wrote: |
| If the app is using SYNCPOINT, it should Commit the transaction. Otherwise the max connection will be exceeded. |
Max Connections and commiting transactions are unrelated.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| squidward |
| Posted: Mon Mar 30, 2009 12:10 pm Post subject: |
|
|
Novice
Joined: 27 Mar 2009
Posts: 10
|
| Sam Uppu wrote: |
You mean Binding is not supported on 64 bit QMgr?. From version 6 onwards the QMgr is of 64 bit only and Binding is supported on 64 bit QMgr.
|
I was looking in the windows system requirements for MQ v6 here:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg27006266
Note #10:
WebSphere MQ only supports Java/JMS in Clients mode on Windows 64-bit platform (i.e. Bindings mode is not supported).
Since we are java based, bindings appears to be not available. Even though our prod will be Linux we will be needing to test in Windows.
Or am misunderstanding the requirement? |
|
| Back to top |
|
|
|
|
