|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Ignoring reason codes, is it wise? |
« View previous topic :: View next topic » |
Author |
Message
|
aghani |
Posted: Wed Jul 23, 2003 3:32 am Post subject: Ignoring reason codes, is it wise? |
|
|
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 |
|
 |
mqonnet |
Posted: Wed Jul 23, 2003 5:12 am Post subject: |
|
|
 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 |
|
 |
aghani |
Posted: Wed Jul 23, 2003 5:26 am Post subject: |
|
|
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 |
|
 |
mqonnet |
Posted: Wed Jul 23, 2003 5:40 am Post subject: |
|
|
 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 |
|
 |
EddieA |
Posted: Wed Jul 23, 2003 5:49 am Post subject: |
|
|
 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 |
|
 |
mqonnet |
Posted: Wed Jul 23, 2003 5:59 am Post subject: |
|
|
 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 |
|
 |
aghani |
Posted: Wed Jul 23, 2003 6:11 am Post subject: |
|
|
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 |
|
 |
|
|
 |
|
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
|
|
|
|