On 04/24/2012 06:07 PM, Phillip Schanely wrote:
> Greetings all!
>
> I'm running into a problem using the qpid.messaging python client. I'm
> trying to quickly poll for messages using
> endpoints.Receiver.fetch(timeout=0). Unfortunately, doing so still blocks
> for me on occasion.
>
> Further investigation reveals that the process is waiting in one of the
> many calls to _ecwait() from fetch(). It would appear that the timeout is
> not passed along to these calls. Is this intended behavior? If it's not
> intended behavior, would a patch be considered if I were to submit one?
It's a good question.
The timeout limits the time that the client will wait for a message,
however before giving up, the client will do a roundtrip to the queue to
make sure there is no message on its way (i.e. a 'flush'). In the case
of a zero timeout, only this flush is performed, but being a roundtrip,
it does result in the calling thread blocking for the response.
How long is the call typically blocked? I wonder if this is sufficient
to explain your case of if there is something else involved...
I think the fetch() call *should* always do a flush. In the case of zero
capacity (i.e. no 'prefetch' enabled, the fetch call itself will trigger
the broker to be able to send a message - since that is not
instantaneous it would have to wait for the response.
In the c++ API there is a get() call that is like fetch() but without
the flush. I.e. it simply waits the specified amount of time for a
message to become locally available. If the timeout is specified as zero
it is a simple check for available messages.
Of course you could also check for available messages with the
available() method on the receiver in question.
---------------------------------------------------------------------
To unsubscribe, e-mail:
[hidden email]
For additional commands, e-mail:
[hidden email]
Locked
