Adam Chase 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.
Yes, that is correct. After failover has occurred an entirely new
session is created so any session state needs to be recreated. This
means that all subscriptions need to be re-established, any
exclusive-and-auto-deleted queues need to be recreated. Also messages
received on the defunct session can no longer be accepted or acquired
(they will all have been automatically released when the session failed).
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?
You may be able to avoid the exceptions, but the fact that the session
has failed means that you will still need to take all the point above
into consideration.
Also I am using manual acknowledgment. When I failover, I must
reacquire all the messages that I had acquired previously, before
acknowledging them, right?
Any messages that were not acknowledged before failure will be requeued
for redelivery. On re-establishing a subscription they will be resent.
Also, will the messageIds I get when I
reacquire necessarily be the same as the ones I got on the first
acquiring?
No, the message ids are session scoped (they are in fact command
sequence numbers for the transfer command by which the message was
delivered to the client).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
