| Author |
Message
|
| ivanachukapawn |
 Posted: Mon May 03, 2010 8:46 am Post subject: Long distance client trigger monitor |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
We have a ZOS QM in Chicago and a Windows MQ client in Houston. An application on the Windows client in Houston needs to dequeue messages originating from the Chicago ZOS server.
Joe wants to run the MAK7 client trigger monitor service on the Windows machine to trigger an application to dequeue the messages from a local queue on the Chicago machine.
Mike does not like that plan because of the distance involved in the MAK7 client trigger monitor connection to Chicago. Mike wants to setup distributed queueing between Chicago QM and an Katy QM and then have the Houston MQ client application dequeue the messages from the Katy QM.
Mike thinks that since the Katy QM (this is close to Houston) already exists the extra distributed queueing hop for these messages is a good idea because it eliminates the long distance client connection.
Is Mike correct? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon May 03, 2010 9:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is this a certification questions  ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon May 03, 2010 9:16 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| It certainly is not a certification question. It is a real life situation. The locations of the QMs have been changed and the names Joe and Mike are aliases. In this scenario I am Joe. Applying Occam's razor to this problem should lead an admin to select the long distance client trigger monitor solution. It is the simplest. But technical management (i.e. Mike) has the notion that client connections ought not to be trusted over long geographical distances. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 03, 2010 9:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This is what MA7K was designed for with its strong reconnect logic.
| Quote: |
| "the Katy QM (this is close to Houston)" |
Unless its on the same LAN, its the same "distance" as Chicago.
K.I.S.S.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 03, 2010 9:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's always better to make client connections to a closer qmgr than a further one.
It's always better to rely on MQ distributed queuing to move messages across network links and between datacenters than to rely on client connections to do so.
Using a client connection to read the message from a distant qmgr *may*, however, provide a faster response from the triggered application, in that it won't have to wait for the app message to move across the network and cause a local trigger message to be written.
And MA7K is written to be as fault-tolerant and self-reconnecting as any reasonable MQ application can be.
It comes down to the actual latency and reliability requirements of the business app processing the message. Can it survive a short period of time in which the trigger monitor may not be able to read a trigger message and start the app, because the connection over the network is unavailable? Can it survive having a delay between when the sending app puts the message and when the message is available to be processed? |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed May 19, 2010 4:35 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Peter's statement:
| Quote: |
It's always better to make client connections to a closer qmgr than a further one.
|
is possibly inconsistent with his later statement
| Quote: |
| It comes down to the actual latency and reliability requirements of the business app processing the message. Can it survive a short period of time in which the trigger monitor may not be able to read a trigger message and start the app, because the connection over the network is unavailable? Can it survive having a delay between when the sending app puts the message and when the message is available to be processed? |
If the answers are yes, the app can survive short periods of time of connection non-availability, and yes, the app can survive a delay etc, then perhaps the simpler solution of having a long distance client TM (vs an extra leg of distributed queueing just so a client connection can be short distance) is better. Would you agree? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 19, 2010 5:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, that was *my* statement, not Peter's.
And, you know, he's much better looking than I am, and probably smarter. So maybe he'll contribute his own opinions.
As he says, measuring the network distance is a tricky question. If you're talking to the qmgr over a LAN within the same datacenter or the same rack or etc, that's one distance. If you're talking to the qmgr but it's in another datacenter or otherwise not within a couple of switches or the same subnet, then that's a separate distance. And that second distance may be functionally equivalent to the network distance from Houston to Chicago.
I'm a bit biased on the subject of MA7K - it's part of my responsibilities as maintainer to ensure that it meets the widest set of requirements including being reliable over a longer distance connection. So I can't really make a recommendation for either option. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed May 19, 2010 6:03 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Lets say its the worst case (the network distance). Its the case you mentioned, not within a couple of switches or on the same subnet -
| Quote: |
| If you're talking to the qmgr but it's in another datacenter or otherwise not within a couple of switches or the same subnet, then that's a separate distance |
. It is my opinion that there is nothing about this long distance client TM connection that should cause an MQ I/F designer concern, given that the app can easily survive momentary disconnect/reconnect senarios and/or slight delays in dequeueing messages. K.I.S.S should win this dispute barring some objection to long distance client TM connections which has yet to surface. Could you agree to that? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 19, 2010 11:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If it was just MA7K we were talking about, I would still say go for the log distance client connection. All its doing is pulling little trigger messages and it wasn't written by some junior flunky fresh out of MQ 101.
BUT, what is MA7K gonna do? If its going to trigger a client app written by said junior flunky, and that client app is putting and getting messages related to heart transplants, well, then maybe you have a case for having this client app deal with as few external variables as possible and you want its network connection as reliable as possible, or maybe even eliminated (connect to a QM on the same server in bindings mode).
All depends on those pesky requirements.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 19, 2010 11:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
There has been much discussion here about the relative value of the WMQ client.
One of the most significant benefits of the client is that it is not a qmgr, and all that supporting a qmgr entails. Clients are an easy sell for low volume applications. If the requirement is that there be no qmgr at the client end, so be it.
I'm not all that concerned with distance or geography specifically. I'm more concerned with all the stuff between here and there that might affect network reliability. Chicago and Houston seem to be pretty well-connected. I'm not so sure about Chicago to, say, Elko NV.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 19, 2010 1:40 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ivanachukapawn wrote: |
| But technical management (i.e. Mike) has the notion that client connections ought not to be trusted over long geographical distances. |
If resilience is the concern, then it would be principally reflected in the need to have a queue manager local to the putter. You have that (I guess).
You said:
| Quote: |
| An application on the Windows client in Houston needs to dequeue messages originating from the Chicago ZOS server. |
So the Chicago server has the messages. You need them in Houston.
If you have a server in Houston, that doesn't help you with moment-to-moment unreliability in the link from Houston<->Chicago. But it might help you if your client processess slowly and you want it to work through a batch continuously.
By the way, is there any unreliability in the link from Houston<->Chicago? Just asking.
The time you might need a server in Houston is if you have unreliability at a few times in the day (which a SDR/RCVR channel could retry and work around) but need a steady stream of work to your client (running on a slow processor) in Houston.
Other than this, I don't see a strong argument against using a client for this in Houston.
How does that sound? |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu May 20, 2010 3:48 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Sounds very good. I thank you all for the help. |
|
| Back to top |
|
|
|
|
