| Author |
Message
|
| Aragosta |
 Posted: Wed Aug 31, 2011 9:27 am Post subject: Migrating from MQ Server to MQ Client |
 |
|
Newbie
Joined: 30 Aug 2011
Posts: 3
|
Hello all.
We have a 3rd party application that runs on a stack of servers, with that stack growing every month.
Each server is presently configured with a full MQ license... a local queue manager on each server.
The costs of MQ for these servers is getting to be a problem. They are app servers doing heavyweight transactions... lots of cores... lots of $$$... with very light traffic going across MQ.
I am considering moving these queue managers to a central server, using only MQ Client on the application servers.
My question is...
Are application coding changes needed to support a move from MQ Server to MQ Client?
As it is a 3rd party application having changes made to the app is something of a problem.
Thanks in advance for any advice or guidance you can lend on this topic.
Aragosta |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 31, 2011 9:33 am Post subject: Re: Migrating from MQ Server to MQ Client |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Aragosta wrote: |
| Are application coding changes needed to support a move from MQ Server to MQ Client? |
Not code changes per se. The existing code will need to be relinked / retasked / pointed at / whatever the client api rather than the server side api.
The application code will need to be reviewed to see if it uses any server side only features (such as XA transactions) that the standard client doesn't support.
Where you may hit problems is if the application code makes the assumption that it's running server side and doesn't need to bother with such things as reconnection & retry logic in the event of network issues.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 31, 2011 10:09 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Bad MQ application behaviour can become more of an issue on a client connection.
Such as - over frequent mq connections to the QM, over frequent queue mqopens, or over frequent mqget attempts.
Retrying connection failures too frequently (e.g. when QM is down).
Not using FAIL_IF_QUIESCING options on MQI calls.
If your application uses two-phase commit (or MQBEGIN calls) you will need the extended transaction client (costs same as QM).
Plus as Vitor said, the logic to retry at all may be missing, and when the QM is separated - this scenario is much more common.
The other issue is any mis-match of SLA. Does the app need to store messages at a time the QM is down for maintenance?
Any centralised QM should be highly available, which brings a whole load of considerations (HA, MI, Auto-Reconn in client).
Try to get MQ client apps to use a CCDT. But this is not always supported by apps written in Java.
Use a DNS name for the MQ host -makes it a lot easier with DR etc. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Aug 31, 2011 11:09 am Post subject: Re: Migrating from MQ Server to MQ Client |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| ...if the application code makes the assumption that it's running server side and doesn't need to bother with such things as reconnection & retry logic in the event of network issues. |
| zpat wrote: |
| ...the logic to retry at all may be missing... |
Not forgetting that V7.0, if the client application's written in a 'proper' language, or if your WMQ installation is at a certain level (7.0.1.3) for 'improper' languages, reconnection support is there 
_________________
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 |
|
|
| zpat |
| Posted: Wed Aug 31, 2011 11:15 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, but client auto-reconnect only works when the QM is quiesced with the -r option.
It does not work if the QM crashes or is closed any other way. Or if it is down more than the time limit set by the client set up. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Aug 31, 2011 11:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| Yes, but client auto-reconnect only works when the QM is quiesced with the -r option... |
I do believe that is for bouncing a queue manager and signalling to reconnectable clients that "...I'll be back in a minute...". As I stated - support is there...
| Quote: |
* By default clients are not automatically reconnected. Enable the automatic client reconnection by setting the MQCONNX MQCNO Option MQCNO_RECONNECT or MQCNO_RECONNECT_Q_MGR.
* Many applications are written in such a way that they are able to take advantage of auto-reconnection with no additional coding. Enable automatic reconnection for existing programs, without making any coding changes, by setting the DefRecon attribute in the channels stanza of the mqclient.ini configuration file. |
_________________
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 |
|
|
| zpat |
| Posted: Wed Aug 31, 2011 12:05 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Auto-reconnect works by completely hiding the disconnection from the client app.
It only works when the reconnection information is saved during a controlled closedown with the -r option. This info can then be restored when the QM is started with the -r option (or -v something like that).
It does not make a brand new connection, this would totally baffle client applications that were in the middle of using QM and queue handles.
So it's not a complete substitute for reconnection logic in the application. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Aug 31, 2011 12:10 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| ...It only works when the reconnection information is saved during a controlled closedown with the -r option. This info can then be restored when the QM is started with the -r option (or -v something like that). |
From the manual:
| Quote: |
Automatic client reconnection is triggered by one of the following occurrences:
* queue manager failure
* ending a queue manager and specifying the -r, reconnect, option on the endmqm command |
Found HERE.
_________________
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 |
|
|
| zpat |
| Posted: Thu Sep 01, 2011 1:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
|
| Back to top |
|
|
| LouML |
| Posted: Mon Sep 26, 2011 6:48 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
We've started to go this route in Development, using Multi-instance Queue Manager.
As for auto-reconnect, I've found the most reliable apps have been using the AMQCLCHL.TAB file and MQ Client 7.0.1.3 or greater.
We still have some servers with older versions of MQ Client that need to be upgraded. These apps can connect but cannot take advantage of the auto-reconnect.
Apps using CPAN MQ Perl API's have worked well, using MQSERVER env variable with multiple hostnames.
Unfortunately, we have some other apps that do not support MQ Client 7.0 and Multi-Instance Queue Manager.
- 3rd party apps compiled with version 6.x libs
- Some JMS apps
- external channel connections that do not support multiple hostnames in a Sender Channel CONNAME
These issues still need to be worked out before we go to Production.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Sep 26, 2011 10:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| The Perl API should work fine with a CCDT. I personally don't like use of MQSERVER variables. |
|
| Back to top |
|
|
|
|
