[Info-vax] MQ series client support AST?

[Jan-Erik Söderholm]

rockdale wrote:
>> And have yo considered adding that 1 second timeout to the MQget call
>> as a param instead?
> 
> My concerns about this are:
> 
> Within this MQGET 1 second timeout, my application can not response to
> the TCP/IP socket ASTs.
> 
> What is the diff between this 1 sec timeout in MQGET and MQGET with
> default timeout then sleep 1 sec.

The difference is that with a 1 sec sleep, you can have a delay of
(up to) 1 sec before your applications acts on the message
on the MQ queue. By having the 1 sec delay as an 1 sec timeout
on the MQGET call instead, your process would act "at once"
when the message arrives on the queue. That is, if a message
arrives, the MQGET call returnes at once, of cource.

> My understanding is that with the 1
> sec time the gap between 2 mqget is shorter (it is 1 sec), but with my
> classic pool, the gap between 2 mqget is 1 sec + the default timeout.

No. If you are calling MQGET with wait and a timeout, the MGET will
always "respond" at once as soon as a message arrives in the queue.

You could have a 1 *hour* timeout in the MQGET call and still have
a quick response right when a message arrives on the queue. Your
problem is that your specific process has other things "to do", and
that could be solved by having a second process doing those things.

> And what is the default timeout value if I did not pass the timeout
> parameter to mqget?

I'm 100% sure that the docs would tell you that, but my guess is
that if you don't specify a timeout, you will not wait either...
I think the "wait" is a flag in the call that you have to set, so
there is no default timeout realy...

> 
> 
>> And this is from one process?
>> What is the value / need to use a single process?
>> Why not have a separate PRODUCER and a CONSUMER process and have them
>> talk (mutex?) if need be?
> 
> Yes. All this is from one process. That's why I am considering using 2
> threads to do read and write seperately. But with 2 separated thread I
> still need to consider the race condition (if there are any). Not sure
> if it is worth to change to 2 threads. ( a lot of changes).
> 
> Last question, does the race condition of MQGET and MQPUT exist? I
> understand that it is the same MQ server and same MQ Manager, but they
> are different queues.

Then there are no race condintion. Two separate process could read or
write two separate queues without any problems.




> 
> Again, Thanks
> -Rockdale