2012/6/26 Gordon Sim <[email protected]>: > 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, > > > >
Thanks for your patience:-) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
