qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: messenger fetch interrupt
Date Tue, 13 Jan 2015 17:37:24 GMT
On 01/13/2015 05:24 PM, Michael Ivanov wrote:
> Thtnks for reply,
>
> As regarding my expectations I guess that messenger waits for the
> next message using some system call, probably poll or select.
> I set empty signal handler for SIGUSR1 and when I want to interrupt
> the wait I use pthread_kill to send SIGUSR1. The signal handler
> is invoked, I checked this. Usually in such situations any blocked
> system call also gets interrupted with EINTR error. Is this not
> the case with qpid messenger?

The thread blocking on the call is not the same as the thread(s) 
blocking on poll.

> And why no exception is thrown when I specify an explicit timeout?

The default behaviour of Session::nextReceiver() is to block 
indefinitely until a message is available. I suspect it is that call 
that you are blocked on, not the subsequent Receiver::fetch().

As Andrew stated, the usual pattern is to specify the wait time in 
nextReceiver() and then have a timeout of 0 in the fetch(), since the 
first call will only return when there is a message to fetch.

> 13.01.2015 20:13, Andrew Stitcher пишет:
>> On Mon, 2015-01-12 at 22:12 +0300, Michael Ivanov wrote:
>>> Hallo,
>>>
>>> I am reading the messages from the queue as follows:
>>>
>>>     Receiver    r(_session.nextReceiver());
>>>     Message     message(r.fetch(Duration::FOREVER d));
>>>
>>
>> This sequence should be spending its time in the nextReceiver() call,
>> because it should only return when there is a message. So the
>> message::fetch() should always have a message to fetch. You can use
>> message::fetch(0) to ensure that it does not wait at all.
>>
>>> At some moment I want to interrupt the receiver using some signal.
>>>  From signal handler I invoke pthread_kill(SIGUSR1, pthread_self())
>>> but fetch is not interrupted. Is it just not possible to interrupt
>>> this function or am I doing something wrong?
>>
>> Can you explain how you think this should work? It's not clear to me
>> what you'd even expect to happen. Do you have a SIGUSR1 handler? Is it
>> being called?
>>
>> Andrew
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message