ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ API SupportCheck Q manager status before calling IMessageProduce.Send

Post new topicReply to topic
Check Q manager status before calling IMessageProduce.Send View previous topic :: View next topic
Author Message
GenCode
PostPosted: Thu Feb 18, 2016 11:55 am Post subject: Check Q manager status before calling IMessageProduce.Send Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 18, 2016 12:02 pm Post subject: Re: Check Q manager status before calling IMessageProduce.Se Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7763
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 didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
GenCode
PostPosted: Thu Feb 18, 2016 12:05 pm Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Thu Feb 18, 2016 2:33 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19100
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
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Thu Feb 18, 2016 9:09 pm Post subject: Re: Check Q manager status before calling IMessageProduce.Se Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1645
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
View user's profile Send private message
GenCode
PostPosted: Fri Feb 19, 2016 6:28 am Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Fri Feb 19, 2016 9:02 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7763
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 didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Feb 19, 2016 9:03 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7763
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 didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Feb 19, 2016 9:07 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17187

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...
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ API SupportCheck Q manager status before calling IMessageProduce.Send
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.