| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Polling for messages with .NET API queries... |
« View previous topic :: View next topic » |
| Author |
Message
|
| treny_boy |
 Posted: Tue Dec 18, 2007 3:44 pm Post subject: Polling for messages with .NET API queries... |
 |
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Hi,
I've got a couple of queries with the .NET API I'm hoping someone can provide some advice on:
1. I am building an application which polls an MQ queue looking for messages, and when found gets them. This application will run on the same machine, just wondering would I be best to keep the MQQueue open throughout the life of the application, or open and close it each polling interval?
2. This same polling mechanism, I am using the CurrentDepth property of the MQQueue within a while loop to get all available messages from that queue, however there have been a few instances when the CurrentDepth has been greater than 0 but when I have issued the Get an exception is thrown indicating that no messages are available. Is this property reliable or should I be using something else to determine if there are message(s) available?
Thanks in advance
Trent |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Dec 18, 2007 6:20 pm Post subject: Re: Polling for messages with .NET API queries... |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| treny_boy wrote: |
1. I am building an application which polls an MQ queue looking for messages, and when found gets them. This application will run on the same machine, just wondering would I be best to keep the MQQueue open throughout the life of the application, or open and close it each polling interval?
|
What are you going to do in between the pols? How long will it take? It doesn't make much sense to close the q only to immediately open it. Rather than polling you are better off opening the q once, issue a Get with Wait and then process messages as they arrive. Polling is generally a bad idea, unless you got a lot of other work to do in between "pols".
| treny_boy wrote: |
2. This same polling mechanism, I am using the CurrentDepth property of the MQQueue within a while loop to get all available messages from that queue, however there have been a few instances when the CurrentDepth has been greater than 0 but when I have issued the Get an exception is thrown indicating that no messages are available. Is this property reliable or should I be using something else to determine if there are message(s) available?
|
Your app should always read the q until its empty, and then return to waiting on the q for more messages. Using q depth to indicate how many times you should issue an MQGET against the queue is wrong. Its a common mistake among new MQ programmers. Do a search for this topic under my name as we recently discussed why this is such a bad ideas in great detail.
If the volume of messages is going to be very light and / or sporadic you may want to consider using triggering and leaving your app down otherwise. Or just sit and wait on the queue constantly. Polling, the "in between" option, is rarely correct or necessary.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| treny_boy |
| Posted: Wed Dec 19, 2007 9:47 pm Post subject: Re: Polling for messages with .NET API queries... |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
| PeterPotkay wrote: |
What are you going to do in between the pols? How long will it take? It doesn't make much sense to close the q only to immediately open it. Rather than polling you are better off opening the q once, issue a Get with Wait and then process messages as they arrive. Polling is generally a bad idea, unless you got a lot of other work to do in between "pols".
Your app should always read the q until its empty, and then return to waiting on the q for more messages. Using q depth to indicate how many times you should issue an MQGET against the queue is wrong. Its a common mistake among new MQ programmers. Do a search for this topic under my name as we recently discussed why this is such a bad ideas in great detail.
|
This sounds like a good approach!
I have this running on a seperate thread, could be multiple threads monitoring their own different queue (1 thread per queue). Its a service which runs constantly but generally only works for 1-2 hours per day, and the rest of the time will be idle.
Can I interupt a waiting Get as I would need to be able to stop it if requested. Currently i'm using an EventWaitHandle to put the thread to sleep which allows me to terminate if required (when the service is stopped).
Thanks |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 20, 2007 12:17 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What I recommend is issuing MQGET WAIT with a 30 second wait limit, when it terminates with RC 2033 (no msg available), check for the adapter closedown request and if set then close, otherwise repeat the above.
Also worth checking for the FAIL_IF_QUEISCING condition which is the queue manager telling the adapter to stop so the QM can stop. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 20, 2007 5:56 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You could also have your code immediately execute the following after every MQGET:
| Code: |
Check MQMD's Feedback Field
IF MQFB_QUIT
Close the q, disconnect from the QM and cleanly end the app
Else
process app message, then issue another MQGET with Wait
End IF
|
This way you can send in a "Quit" message to your app and gracefully end it anytime you want, no matter what the wait interval on the MQGET.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| treny_boy |
| Posted: Thu Dec 27, 2007 9:49 pm Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 8
|
Hi Peter,
Thanks, I will look into this but it sounds like this is exactly what I need.
Cheers
Trent |
|
| 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
|
|
|
|
