| Author |
Message
|
| bruce2359 |
 Posted: Sun Aug 08, 2010 6:30 am Post subject: Suggestion for coding WMQ client applications, please. |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
As with most things, the WMQ Client offers some advantages and disadvantages. As has been discussed here at length, the client presents some opportunities for unusual behavior - the dreaded 2009 RC, and the uncertainty it leads to, for example.
If a qmgr is not possible, how can we code the client app to behave in a more robust manner?
Anyone? Anyone? Bueller? Bueller?
_________________
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 |
|
 |
| bruce2359 |
| Posted: Sun Aug 08, 2010 6:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Suggestion 1) use fixed-named queue objects for replies - don't use dynamic queues.
Suggestion 2) don't use UofW's.
Suggestion 3) create a 'status queue' where the app can post what it has done, where it is in the transaction, etc..
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sun Aug 08, 2010 12:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Any MQ Client that issues MQGETs must do so using the syncpoint option, otherwise it risks losing the message. If the connection breaks after the local QM side agent removes the message from the queue but before its shipped down the wire to the client, that message is gone if the MQGET was done outside of syncpoint.
All apps must check the Reason Code after every MQ API call. But it becomes more critical for MQ Clients because its more likely they would see a non zero Reason Code due to the added points of failure that even the most robust network introduces.
MQ Clients must have strong, and smart, reconnect logic. All apps should, but its more likely that an MQ Client app will have to deal with it. MQ 7 helps with its built in reconnect logic, although I haven't played with it and don't know if it works in all cases. (I thought I saw a post from someone, zpat maybe, that said it didn't work as expected?) Smart reconnect logic does not drop into a loop where the the app simply issues MQCONN(X) over and over as fast as possible and forever.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Aug 08, 2010 3:25 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Hi Peter, I'd like to add to that.
| PeterPotkay wrote: |
| Any MQ Client that issues MQGETs must do so using the syncpoint option, otherwise it risks losing the message. If the connection breaks after the local QM side agent removes the message from the queue but before its shipped down the wire to the client, that message is gone if the MQGET was done outside of syncpoint. |
Clients are usually FOH apps. Syncpoint is not necessary if its an "inquiry" transaction that does not result in coordinated DB updates. If there is a failure that can't be resolved, just try again.
| Quote: |
| All apps must check the Reason Code after every MQ API call. But it becomes more critical for MQ Clients because its more likely they would see a non zero Reason Code due to the added points of failure that even the most robust network introduces. |
I would have thought this is critical for all MQI calls in all apps.
| Quote: |
| MQ Clients must have strong, and smart, reconnect logic. All apps should, but its more likely that an MQ Client app will have to deal with it. MQ 7 helps with its built in reconnect logic, although I haven't played with it and don't know if it works in all cases. (I thought I saw a post from someone, zpat maybe, that said it didn't work as expected?) Smart reconnect logic does not drop into a loop where the the app simply issues MQCONN(X) over and over as fast as possible and forever. |
Yes. On a 2009 MQRC_CONNECTION_BROKEN the simplest approach is to clean up and break out of the application logic, close all the queues (ignore the comp code & reason code, or maybe just log them), and disconnect (ignore the comp code & reason code). This maintains the correct sequence of MQI calls and clears the handles and the internal state of MQ. Attempt to reconnect after a suitable time interval (say 10 - 30 seconds) or as chosen by the user in interactive aps.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 08, 2010 4:50 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The other scenario is the loss/abend of the client app or the o/s. Ideas on how can a client app can restart?
_________________
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 |
|
|
| zpat |
| Posted: Mon Aug 09, 2010 12:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
When client app starts, the QM may be down, the client should log this and retry on RC 2059 (but not more often than every 30 seconds).
Client app should ask for and respect FAIL_IF_QUIESCING.
Clients app should either tolerate or prevent the simultaneous execution of multiple instances of the client application.
Clients apps must release all connections acquired. They must not connect more times, or more often than necessary.
Any retry logic must not retry actions more often than every 30 seconds to prevent queue manager overload on errors. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 09, 2010 4:34 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
My 3.14159 cents:
Client apps should connect once and reuse the connection handle for many transactions. Connect is the most expensive and time consuming MQ operation and uses signficant resources on the server. (I have seen client apps that conn / disc for every transaction and this significantly limits the maximum transaction throughput)
Client apps should hold open request queues (and reply queues) across multiple transactions. This avoids the overhead of opening and closing queues for every transaction. (I have seen long running client apps that continually open and close the same queues)
The Client protocol requires a synchronous exchange of TCP packets across the network between the Client MCA and the Queue Manager MCA for every MQ call. Minimize the number of MQ calls. eg. Do not use MQGET with a very short wait interval to "poll" queues. (MQ v7 asynchronous put is an exception, as it only requires one TCP packet per put of a short message)
Avoid using large messages (>100K ?), as these compete with other network traffic for available bandwidth.
Include robust error detection and trapping in Client apps to reduce the incidence of crashes that leave behind orphan client channel instances.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 09, 2010 6:50 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gbaddeley wrote: |
| My 3.14159 cents: |
But those, of course, are $AU cents... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 09, 2010 8:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| gbaddeley wrote: |
| My 3.14159 cents: |
But those, of course, are $AU cents... |
you mean your PI cents 3.141592654 ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 10, 2010 2:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| mqjeff wrote: |
| gbaddeley wrote: |
| My 3.14159 cents: |
But those, of course, are $AU cents... |
you mean your PI cents 3.141592654 ? |
No, I'm saying that it's about 2.86481829 cents US according to Mr Google.
Now I want a pastie. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Aug 10, 2010 4:29 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| Now I want a pastie. |
Cheers,
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 11, 2010 2:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gbaddeley wrote: |
| mqjeff wrote: |
| Now I want a pastie. |
Cheers,
|
I couldn't find a proper aussie slang. I meant a Cornish Pastry, i.e. a PIE. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 11, 2010 3:33 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| I couldn't find a proper aussie slang. I meant a Cornish Pastry, i.e. a PIE. |
Hi Jeff,
Aussie bakeries have PIES (meat / gravy inside a round pastry crust, see http://en.wikipedia.org/wiki/Australian_and_New_Zealand_meat_pie ) and PASTIES (meat / vegetables inside a folded pastry crust, see http://en.wikipedia.org/wiki/Pasty ). Both are traditional "fast foods" for lunch. Cost is about AUD$3.50.
The rhyming slang for PIE and SAUCE (ketchup in US) is "dogs eye and dead horse".
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 11, 2010 5:28 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In traditional american fashion, I assert that anything wraped in pastry crust is a pie.
| gbaddeley wrote: |
| The rhyming slang for PIE and SAUCE (ketchup in US) is "dogs eye and dead horse". |
Ketchup in general tastes much worse than a dead horse. I realize this is terribly unamerican of me. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 12, 2010 4:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Ketchup in general tastes much worse than a dead horse. I realize this is terribly unamerican of me. |
Bless you sir. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
