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 Index » General Discussion » Ignoring reason codes, is it wise?

Post new topic  Reply to topic
 Ignoring reason codes, is it wise? « View previous topic :: View next topic » 
Author Message
aghani
PostPosted: Wed Jul 23, 2003 3:32 am    Post subject: Ignoring reason codes, is it wise? Reply with quote

Newbie

Joined: 23 Jul 2003
Posts: 3

Hi this is my first post.

I am running a java adaptor which 'polls' a queue for messages, every now and again the MQ GET returns a reason code of 2033 (no messages on queue) and gives a completion code of 2 (failure) this causes my java adaptor to hang.

Would it be good design to simply ignore reason code 2033 whenever this mqexception occurs or is there a more elegant way of dealing with the problem.

I want the java adaptor to run continuesly and check for messages on the queue, it should only stop running if a 'trailer' message is received and processed.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Wed Jul 23, 2003 5:12 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

It all depends upon your requirement.

Since in this case, you are doing "polling", and polling doesnt necessarily mean that each mqget would get a message, you just ignore the 2033 in your app. Even though you need to handle the case appropriately or else your app might end on getting this error.

Whereas in the case of a standalong get app, such as amqsget, you dont do the same. Instead, you end your app when there are no messages available.

The bottom line is, if you are polling, ignore 2033, if not, handle it and end your app or do whatever your design/requirement is.

Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
aghani
PostPosted: Wed Jul 23, 2003 5:26 am    Post subject: Reply with quote

Newbie

Joined: 23 Jul 2003
Posts: 3

Thanks for that, i just needed an opinion on whether hard coding to ignore reason codes is acceptable practice.

I read on another post that 'polling' is bad design, because of the performance overheads involved.

If anyone has a better solution my problem is as follows...

Messages are sent 24 hours a day to a queue, I need to pick up these messages and process them.

The application that will sit and monitor/receive and processe the messages is written in Java.
The application should only stop monitoring if a particular type of 'trailer' message is received and processed.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Wed Jul 23, 2003 5:40 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Yes, you have to hardcode reason codes in your app to handle such situations. Rather, without doing that you CANNOT write an MQ app. Check the amqsput or amqsget samples supplied by IBM they too have them hardcoded. Remember you are using MQ constants and hence you cannot really call them hardcoding, as in hardcoding the queue manager name instead of accepting an argument.

As i mentioned before, it all depends on your requirement that leads you to a solution. Polling is not a bad option, but yes, it is expensive. If you want a cheaper option you could go and trigger your process at different intervals.

Search this forum for the same and you should find a lot of hits as similar cases have been discussed earlier.

Cheers
Kumar


Last edited by mqonnet on Wed Jul 23, 2003 6:00 am; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website
EddieA
PostPosted: Wed Jul 23, 2003 5:49 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

mqonnet said:

Quote:
Polling is not a bad option, but yes, it is expensive. But bear in mind, the listener process of MQ itself does that.


I'm not so sure that MQ polls. I think it works a little more elegantly than that.

Which is the reason that it's more efficient to do a GET with Wait than to poll. But make sure you cater for someone wanting to shut the Queue Manager down.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
mqonnet
PostPosted: Wed Jul 23, 2003 5:59 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Eddie, you are right, thanks for correcting. I have corrected my previous post.

Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
aghani
PostPosted: Wed Jul 23, 2003 6:11 am    Post subject: Reply with quote

Newbie

Joined: 23 Jul 2003
Posts: 3

Thanks guys,

One more query, when we originally tested the java adapter it was polling a queue and it did not return RC 2033.
When we moved the testing to a higher performance platform and left the polling run for a longer period of time then the RC 2033 started appearing.

Are there known instances where even if there are no messages on the queue the RC 2033 will NOT be returned,
The only thing i can think of is polling frequency, the new platform may be polling more often (every second) and therefore could have a higher probability of polling an empty queue.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General Discussion » Ignoring reason codes, is it wise?
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.