| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Check Q manager status before calling IMessageProduce.Send |
« View previous topic :: View next topic » |
| Author |
Message
|
| GenCode |
 Posted: Thu Feb 18, 2016 11:55 am Post subject: Check Q manager status before calling IMessageProduce.Send |
 |
|
Novice
Joined: 10 Sep 2015
Posts: 21
|
I need to check connection status before calling IMessageProduce.Send(...)
The reason why is we maintain a connection to our MQ, sometimes our app gets disconnected because of network issues causing a Reason: 2009, queue manager closed. I can reconnect but I want to do a status check "before" I call my database to get my messages to send.
I know I can use the autoreconnect in 7.5
cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT_Q_MGR);
Problem is I don't have 7.5 on our box, we only have 7.0.1.7
So long story short, is there a way to check queue manager before trying to send.
I am using XMS C# DLL
Thanks, Ed |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Feb 18, 2016 12:02 pm Post subject: Re: Check Q manager status before calling IMessageProduce.Se |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| GenCode wrote: |
I need to check connection status before calling IMessageProduce.Send(...)
...
So long story short, is there a way to check queue manager before trying to send.
|
I suppose you could do so.
But what if the qmgr was available when you checked, but then became unavailable a microsecond later when you tried to send? What have you gained?
_________________
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 |
|
|
| GenCode |
| Posted: Thu Feb 18, 2016 12:05 pm Post subject: |
|
|
Novice
Joined: 10 Sep 2015
Posts: 21
|
That would be okay, that rare instance I would reject it back to the DB with a failed to send status in the try catch and we will have a user resend later. This is what I want to prevent when possible, but of course there is always a chance.
Is there a way to check status this with XMS? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 18, 2016 2:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Besides from making a pcf call inquiring about the qmgr status, the fastest way to check would be to send and receive a message from a queue (could be a temporary queue).
If the send fails, the commit fails or the receive fails you know you have to go and troubleshoot...
Seems to be a lot of work when you'll have to code for the Exception to your normal case anyways...
Make sure you intercept the right exception, release all the resources, reacquire them and go on. Should you fail a second time... you'll have to go a different way, and don't forget to release the resources in a finally clause... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Feb 18, 2016 9:09 pm Post subject: Re: Check Q manager status before calling IMessageProduce.Se |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| GenCode wrote: |
I need to check connection status before calling IMessageProduce.Send(...)...
So long story short, is there a way to check queue manager before trying to send. |
I suppose you could do so.
But what if the qmgr was available when you checked, but then became unavailable a microsecond later when you tried to send? What have you gained? |
Best design and coding practice is to not check MQ connection status at any time. Every call to MQ should be able to catch and handle the exception if the connection drops, or any other unexpected error. In most cases the action should be to abandon / rollback the transaction, reconnect, reopen queues, and attempt it again.
This occurs on a regular basis, the root cause should be investigated and fixed by the MQ admins. Apps should be able to expect reliable service from MQ, and not code around ongoing infrastructure issues as a band-aid fix.
_________________
Glenn |
|
| Back to top |
|
|
| GenCode |
| Posted: Fri Feb 19, 2016 6:28 am Post subject: |
|
|
Novice
Joined: 10 Sep 2015
Posts: 21
|
" Every call to MQ should be able to catch and handle the exception if the connection drops, or any other unexpected error. In most cases the action should be to abandon / rollback the transaction, reconnect, reopen queues, and attempt it again. "
Thanks Glenn, that's exactly what we do. Guess we will stick to this method hope to get to 7.5 where we have the autoreconnect soon
I appreciate all the feedback. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 19, 2016 9:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This is similar to other posts where developers believed that they must MQINQuire on current queue depth before attempting to MQGET a message, not understanding that the app will either get a message if there is one, or a ReasonCode 2033 if no message is available.
Every MQI call returns a CompletionCode and ReasonCode that alterts the app as to success, warning, or failure of the call.
_________________
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: Fri Feb 19, 2016 9:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This is similar to other posts where developers believed that they must MQINQuire on current queue depth before attempting to MQGET a message, not understanding that the app will either get a message if there is one, or a ReasonCode 2033 if no message is available.
Every MQI call returns a CompletionCode and ReasonCode that alterts the app as to success, warning, or failure of the call.
Why expend the resources of two MQI calls when one MQI call will do.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Feb 19, 2016 9:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Why expend the resources of two MQI calls when one MQI call will do. |
And when there's no guarantee that the results of the first call are still meaningful when you make the second...
_________________
chmod -R ugo-wx / |
|
| 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
|
|
|
|
