| Author |
Message
|
| dunesand |
 Posted: Tue Dec 16, 2003 3:41 am Post subject: Events vs polling the queue... |
 |
|
Acolyte
Joined: 17 Nov 2003
Posts: 65
Location: Cambridgeshire, UK
|
I'm using Windows 2000/xp with CSD05 and accessing the .Net API.
What's the best way to get messages from a queue, specifically, how to wait for the next message to be sent?
there's a waitinterval property, where the get method will wait before timing out, and so this can be repeated in a polling fashion...
but i'm sure the event approach is probably the way that MQ is designed, I've had a read through the event's manual and would just like to clarify how this process works.
I assume you'd use the DepthHighLimit ( set to 1? ) and the DepthHighEvent to create a callback type structure so that messages are processed when they exist on the queue, and the application idles while there are no message on the queue.
am I right in my thinking, or am i missing the boat completely? 
Thanks for your time. 
Dan. |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Tue Dec 16, 2003 4:09 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Look into triggering! I think that is what you are looking for.
Michael |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 16, 2003 5:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, the Get with Wait Interval option is the recommended way to wait for a message on a queue. The Wait Interval is the maximum time that your app will wait, if a message arrives sooner the call will end.
Triggering is good, but is only recommended for certain styles of messaging - where you are going to get messages arriving in larger groups, and not at regular intervals or in small batches. If you're getting three messages every minute, triggering will cause your app to have to start up, process three messages and then quit. Every minute.
If you do start trying to do things with events, then you will basically end up recreating triggering. Which is fine, but you should think if you want to spend the time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dunesand |
| Posted: Tue Dec 16, 2003 5:47 am Post subject: |
|
|
Acolyte
Joined: 17 Nov 2003
Posts: 65
Location: Cambridgeshire, UK
|
I know comparing is bad sometimes, but MS MQ just seems so much friendly to develop with than ibm MQ. (but ibm mq does have a better admin UI through mq explorer)
You can monitor a queue by just establishing a callback so that every time a message is ready to be received, it fires an event so your program can read and process it.
Triggering makes a lot of sense, as you say, for certain types of messages arriving infrequently in fair sized blocks.
Polling the queue for messages through the wait interval technique just seems unnecessarily messy. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 16, 2003 6:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| dunesand wrote: |
| Polling the queue for messages through the wait interval technique just seems unnecessarily messy. |
Oh, I dunno. It allows your application to control explicitly when and how it wants to wait for data, which seems like a good thing to me. With an event system like you say MSMQ has, your application has to stop whatever else it's doing at the time to process a message. Or spawn off a worker thread to handle each event. Which you can do from your polling routine anyway - so it all starts to look the same... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Apr 01, 2008 11:42 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Using MQGET with WAIT is not really polling, as the wait interval can be infinite.
Polling is where you check the queue at a relatively frequent intervals (typically without a wait on the get) and can be inefficient, especially over a client connection.
WMQ V7 introduces another option, of call-back. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Apr 02, 2008 6:27 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Polling MQ is usually a bad idea. It wastes resources and indicates the app design has not really been thought out very well.
MQGET with infinite WaitInterval is like a "blocked read". The program thread will be suspended and it will return from the call when there is a message available or an error occurs. If a prog needs to listen on multiple queues then it should start multiple threads with each sitting on a MQGET with wait.
Triggering has already been mentioned and this is a very good technique in some situations. A prog is started by MQ when one or more messages arrives on the queue. The prog loops on MQGET with a short waitinterval and then terminates. The triggering condition logic is actually very complex.
MQ V7.0 introduces a new paradign for MQGET which effectively provides asynchronous / event driven message consumption. The main thread of the prog typically registers that it wants a user specified call-back function to be invoked whenever a message is available on one or more queues, using the new MQCB call. This mimics an equivalent feature of JMS. |
|
| Back to top |
|
|
|
|
