qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: ThreadSafe/Multiple Session/Connection handling
Date Tue, 26 Jun 2012 15:57:30 GMT
On 06/26/2012 04:24 PM, Zhihua Che wrote:
>     What do you mean by 'you can't retrieve the indoubt messages from a
> sender on a failed connection'?
> Do you mean that the message which causes the Sender.send() failure
> would not be fetched by Receiver.fetch() and 'lost' forever?

If you call send() with the synchronous flag set to true then the call 
will block until the message has been confirmed by the broker.

However if you call it with the synchronous flag set to false, then the 
call returns before it has been confirmed by the broker.

When using the reconnect message, any unconfirmed messages are resent 
when a connection is re-established.

However if you disable reconnect and handle the connection failure 
yourself then you would need to also handle any resending. Unfortunately 
at present you can't use the old senders to retrieve the messages to be 
resent. (You can determine how many of them remained unconfirmed, you 
just can't get the messages back themselves).

>     By the way, I wonder why the Receiver.fetch() could throw
> NoMessageAvailable because I thought the function would just block
> until message is available or the timeout is due.

It does. It will only throw NoMessageAvailable once the requested 
timeout has expired and there is still no message. Note also that the 
exception is only used for the second form of the fetch() method. The 
first form returns a boolean indicating whether a message was fetched or 
not (if true, the reference passed in now refers to that message). The 
second form returns a message if available and throws if not. You can 
use whichever style you prefer,

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

View raw message