[
https://issues.apache.org/activemq/browse/AMQNET-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46419#action_46419
]
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 Transport.
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.
===
Producers
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: https://issues.apache.org/activemq/browse/AMQNET-26
> 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.
