| Author |
Message
|
| ajaykumar |
 Posted: Sat Nov 01, 2008 10:24 pm Post subject: Browsing MEssages in Queuee |
 |
|
Novice
Joined: 20 Sep 2008
Posts: 10
|
Hi All,
What are the options that i need to specify in the open and getr message options so that i could browse the queue and know if there are messages in queue(need not match any selsction criteria any message i should only know if there are messages in the queue) |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Nov 02, 2008 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If I said "specify the browse option" would you believe me? 
All of this is laid out in the APR /API.
Browsing is also a bad way of detecting messages, as has been discussed many times on the forum. If your application need to react when there's a message on the queue use triggering.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ajaykumar |
| Posted: Sun Nov 02, 2008 2:27 am Post subject: |
|
|
Novice
Joined: 20 Sep 2008
Posts: 10
|
| Thanks Vitor for the quick reply. This is not something which i want to implement.It so happened that we have an application which gets messages from queue but the criteria for it to get messages is a depth greater than zero. Now sometimes the depth is graeter than zero and the pplication is not able to get messages.THOUGH CHECKING FOR DEPTH IS NOT A GOOD IDEA. So i just want to change the critera from depth to browse and get messages.As i believe that if a message ca be browsed it can also be got correct me if i am wrong. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Nov 02, 2008 5:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| ajaykumar wrote: |
| As i believe that if a message ca be browsed it can also be got correct me if i am wrong. |
There is no guarantee that if you browse the message it will be there when you decide to get it for real.
If you want a message, just go get one! Your app should be coded to gracefully handled the 2033 error code if the q does not have any available messages that meet your selection criteria (notice I didn't say 'if the q is empty'), and your code should loop until there are no more available messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Nov 02, 2008 8:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9415
Location: US: west coast, almost. Otherwise, enroute.
|
Queue depth only indicates that there are messages in the queue, not that they are available to an MQGET call (browse or destructive).
A message that is MQPUT to the queue IN_SYNCPOINT (in a unit of work) increments queue depth; but the message can not be MQGETed (browse or destructive) until it is comitted by the MQPUTting application.
As stated in a previous post, a 2033 r/c indicates that there is currently no message available, not that there are no messages in the queue. This is a common misunderstanding for new WMQ programmers.
_________________
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 |
|
|
| ajaykumar |
| Posted: Sun Nov 02, 2008 8:05 am Post subject: |
|
|
Novice
Joined: 20 Sep 2008
Posts: 10
|
Thanks for the quick response! The message will not be taken by any application because the same application is checking for messages and then getting it. I am thinking of browsing rather than checking for depth to acsertain the presence of messages that are in agettable state correct me if i am wrong. I beleieve if i can browse a message i can even get it please correctme if i am wrong. Also can anyone plese tell me what are poisoned and locked messages and how to confirm thir presence.
Last edited by ajaykumar on Sun Nov 02, 2008 8:17 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Nov 02, 2008 8:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| ajaykumar wrote: |
| I beleieve if i can browse a message i can even get it please correctme if i am wrong. |
| PeterPotkay wrote: |
| There is no guarantee that if you browse the message it will be there when you decide to get it for real. |
Do not check for messages! If you are ready to process a message, go get one. If you are ready to take a bite out of your sandwich, do you pick it up, look at it, put it down, then pick it up to take a bite?
Only check for q depths if you are a monitoring program.
Only browse messages if you are not sure which message you want (you should avoid this design if possible) or if you just want to see what's there. But guess what, people are curious, applications are not. Applications do not just want to see what's there. Are you writing a program that allows a person to casually read the messages in a queue?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Nov 02, 2008 9:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9415
Location: US: west coast, almost. Otherwise, enroute.
|
There are many samples of source code that do this correctly.
To confirm what you have read here; and to possibly explain it in more detail or clarity:
Your application does not need to know in advance if there are messages to process. It does not need to look at queue depth or browse messages first before getting them, or in any way inquire on queue attributes.
Use triggering to launch the consuming program. Trigger type first is perfect for this - a message arrives, the consuming program is launched.
When the consuming program is launched, it should simply do an MQGET with WAIT. If there is a message in the queue the program will immediately get it.
If there is no message in the queue, the program will wait however long the WAITINTERVAL value specifies. Waitinterval 10 seconds is ok for this (if you expect more messages to arrive within 10 seconds or so). Two possible things can occur: no message arrives within the waitinterval and 2033 is returned to the application; OR a message arrives and the application immediately gets the message.
In either case, the program should repeat the get with wait either forever (100 times, 1000 times), or enough times to ensure that the application has consumed all messages that are likely to arrive in the forseeable future. Only then should the program end itself.
Ending itself will require that it be re-launched when more messages arrive. Re-launching an application is labor-intensive as compared to waiting for a message with Get with Wait.
_________________
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 |
|
|
| ajaykumar |
| Posted: Sun Nov 02, 2008 9:27 am Post subject: |
|
|
Novice
Joined: 20 Sep 2008
Posts: 10
|
| I want u to understand that i am not in a position to change the design.I just want a workaround because the application has been so designed that it issues a call to check for depth and if its non zero it calls another method where we open fresh connection to the queue and get it. But we faced an issue recently that we were not able to get messages even if we have a depth greater than 0. So now we are thinking of a work around and rule out a few possibilities like uncommitted messages.So i am thinking to do browse and confirm that there are messages in queue and then try to get it. I feel messages that are uncomitted cant be browsed either. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Nov 02, 2008 10:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The design of the application is fundamentally wrong, and will be unreliable and represents an anti-pattern.
The workaround is to redesign it.
The issue you faced, where there were messages that you could not get messages even if you have a queue depth greater than zero, is one of the fundamental reasons the existing design is wrong.
The workaround is to redesign it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Nov 02, 2008 1:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ajaykumar wrote: |
| I want u to understand that i am not in a position to change the design. |
You've got serious problems.
| ajaykumar wrote: |
| I just want a workaround because the application has been so designed that it issues a call to check for depth and if its non zero it calls another method where we open fresh connection to the queue and get it. But we faced an issue recently that we were not able to get messages even if we have a depth greater than 0. |
This is because the design is wrong.
| ajaykumar wrote: |
| So now we are thinking of a work around and rule out a few possibilities like uncommitted messages.So i am thinking to do browse and confirm that there are messages in queue and then try to get it. I feel messages that are uncomitted cant be browsed either. |
Yes they can.
There's no guarantee (as other posters have correctly pointed out) that a message which you've browsed for can be got (especially via a fresh connection) or that a failed browse means there's message to be got.
It's also worth pointing out that a connection is a very resource costly artifact. No application should have more than one except in very unusual circumstances, and under no circumstances should you open a fresh one just to read a message. Even though it probably works, it's hideously inefficient and you'll discover exactly how inefficient if you try and use it for production volumes.
To touch on your other question (which are almost trival in the face of these other issues) a poison message is one which causes an application abend & roll back, so it's always the message being read and your program loops endlessly without handling. A locked message is one that is or has been accessed by another connection (i.e. by a badly designed application doing a browse) and therefore can't be read off.
This is of course another issue with your design. With just a small coding issue, the browse will indicate a message is ready to be processed while preventing the message actually being read off.
You may recognise this scenario - it's the one you're describing above where you say "we had an issue recently where we couldn't read a message off" 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
