So I am basically re-acquiring the messages I had and remapping the set of messageIds (which can be different when you reconnect). It seems that TransportFailure exceptions in the listener thread at least can come in any Qpid API call, not just the ones you'd expect (getting exceptions in my received method all I'm doing is getting messageIds and header values). This makes programming these parts a little more challenging from a transactional perspective. I suppose if I get all my message data up front without exception, I can treat it as acquired, otherwise I'll get it again after the failover.
Adam On Mon, Feb 9, 2009 at 3:19 PM, Adam Chase <[email protected]> wrote: > First thank you for all the help you've been giving me, its been > extremely useful. > > My question now is about the FailoverManager. > > From what I can read, it essentially associates each command with a > session and then if that fails, reconnects you to the failover server > and lets you continue the work. > > But it looks like you must resubscribe to any queues that you had > subscribed to before the failover. > > If you are using synchronous sessions, is there much benefit to using > the FailoverManager? If I register a failureCallback on my > connection, could I handle the disconnect event without getting any > exceptions elsewhere in my program? > > Also I am using manual acknowledgment. When I failover, I must > reacquire all the messages that I had acquired previously, before > acknowledging them, right? Also, will the messageIds I get when I > reacquire necessarily be the same as the ones I got on the first > acquiring? > > Thanks, > > Adam > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
