activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Schrum (JIRA)" <>
Subject [jira] Commented: (AMQNET-26) Add failover:// to NMS client
Date Tue, 14 Oct 2008 00:46:52 GMT


Allan Schrum commented on AMQNET-26:

Please disregard much of my previous commentary. While somewhat true, it was a way to organize
my thoughts in the process of understanding what's going on with ActiveMQ NMS. Sorry for the
extra traffic, but not too much.

Failover mode for broker where we wish to use failover: syntax means that the broker is setup
in a failover layout. Our approach should support any failover configuration of brokers. Each
configuration guarantees that persistent messages written by the broker are persisted before
returning control back to the client (for Producers). For Consumers, this varies depending
upon which mode we are operating and when a failure might occur.

Connections have a transport which is used to communicate with the broker. This is typically
a TCP connection since we are using a wire protocol to connect to the broker. All the other
non-TCP modes only work from Java. The Connection has as part of its object data the associated

Sessions are created from Connections. A single Connection can have multiple Sessions. The
Session has as part of its object data the associated Connection. Session Acknowledgement
States: Auto, Client, Dups_OK, Transacted, Individual_Ack

Consumers and Producers are created from Sessions. A single Session can have multiple Consumers
and Producers. Each Consumer has a thread dedicated to manage receiving messages. The Consumer
object has the associated Session object as part of its data.

Messages are retrieved using Consumers (either by calling Receive() or asynchronously).

Session Mode: Auto

In this mode all Consumers of messages automatically acknowledge the message. A failure will
occur during a Receive() or asynchronously an Exception will be thrown indicating an I/O error
(or something similar). In this situation, a simple reconnect followed by tries of other servers
is sufficient. The Consumer should continue where it left off. Since each Consumer uses its
Session object which uses its Connection object to reference the Transport object, changing
the Transport associated with the Connection should be sufficient (more accurately, hiding
that change within the FailoverTransport should be sufficient).

Session Mode: Manual

Similar to mode Auto, when each consumed message is acknowledged, it no longer requires tracking
by the Transport. However, each Message that remains unacknowledged must be tracked. The reason
is if there is an error during processing of these messages, then the non-acknowledged messages
are still on the queue / topic. To handle this situation, all Messages that are consumed must
be registered by the Transport. When the Message is acknowledged then the associated Message(s)
must be removed from registration by the Transport. Care must be done here. If Client_Acknowledge
is used then all Messages registered with the Transport should be cleared. If Individual_Acknowledge
is used then only that Message is removed from the Transport.

Session Mode: Transactional

In this situation all Consumed Messages and all Published Messages must be tracked individually
until the transaction is committed or rolled back. If an error occurs and the connection is
reestablished, then the order of consumed and published messages must be recreated on the
newly reestablished connection to replicate the previous transaction. Normally, re-consuming
the same messages should not be a problem in processing the transaction.

>From the application point of view, something may or may not have happened. The processing
performed by the application was performed based upon the content of the Messages received
by the application. The same input should generate the same output, so all we should do is
re-consume the same messages to return to the same point as we were when the error occurred.


Outside of the transaction, Producers of messages will independently publish and, if they
succeed, complete all that is necessary.

Inside the transaction, the discussion above covers what is required to do to maintain status.

As part of the FailoverTransport implementation, we must replicate much of the same logic
in the Java ConnectionStateTracker() to preserve enough information to handle failover operation.
The Transport associated with the Connection must make use of the TransportFilter interface
so that when the FailoverTransport class is used it effectively select the currently active
Transport, or reconnects / connects to another Transport and continues on. 

However, in reconnecting or connecting to a new transport, the previous state of the Transport
connection must be restored. This is what is managed by the ConnectionStateTracker().

> Add failover:// to NMS client
> -----------------------------
>                 Key: AMQNET-26
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: New Feature
>          Components: ActiveMQ Client
>            Reporter: Denis Abramov
>            Assignee: Jim Gomes
>            Priority: Critical
>             Fix For: 1.1
> Please add failover:// to C# NMS Client. I would add it but I don't know how to resume
a stream once it is broken.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message