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: [email protected]
For additional commands, e-mail: [email protected]
