Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Polling vs Listening:

546 views
Skip to first unread message

Probashi

unread,
Mar 21, 2004, 3:18:17 AM3/21/04
to
Hi,

I am building a server process for processing messages from one
request queue and putting the result back on another response queue.
Various clients will put messages in the request queue and will wait
response in the response queue.

In the server process, for getting the messages from the request
queue, here are 2 options

Polling:
loop
{
1: call the GET method on request queue (with no wait or no blocking)
2: get message and process message
3: wait for some time (say some milliseconds)
}

Listening:
Loop
{
1: call the GET method on request queue (with wait or blocking for
some seconds, MQC.MQGMO_WAIT option)
2: get and process message
3: catch no message exception
}

Which one is the better method?

Thanks

Glenn Baddeley

unread,
Mar 21, 2004, 8:19:51 PM3/21/04
to
Probashi,

Listening is superior because it will get the message as soon as
it arrives on the queue, whereas the polling "wait" will introduce an
unnecessary delay. Polling also wastes CPU time by making lots
of calls to MQGET when there are no messages on the queue.

Polling will still have to catch the no message exception (ReasonCode
2033).

Glenn.

Crisps

unread,
Apr 2, 2004, 2:35:58 AM4/2/04
to
Is there a method of waiting until there is a message on the queue for
an unsepecified amount of time and then being notified by say an event
when one appears?

I'm using c++ and the Imq classes

Cheers

--
posted via MFF : http://www.MainFrameForum.com - USENET Gateway

Ron Bower

unread,
Apr 2, 2004, 9:27:40 AM4/2/04
to
You can wait with an unlimited time (-1) and your get will return when a
message arrives.

However, make sure that you specify FAIL_IF_QUIESCING on your calls. This
will break out of the get if the qmgr is shutting down.

Ron

"Crisps" <mem...@mainframeforum.com> wrote in message
news:c4j54u$4ook$1...@news.boulder.ibm.com...

0 new messages