[
https://issues.apache.org/activemq/browse/AMQNET-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46413#action_46413
]
Allan Schrum commented on AMQNET-26:
------------------------------------
I wish to contribute towards the resolution of this issue. As such, I have been
examining the Java implementation with hopes to understand it sufficiently so
that I can replicate the functions in C#. Below are my comments as to the steps
or actions required to fix this problem. If others can comment or correct my
comments, then we can get started on this. If others are willing to help with
the coding or testing, that would be great.
All that I state below is what I have gleaned from the Java code. There is some
interpretation of the code that may be in error. If so, then those with
sufficient knowledge should correct my interpretation.
A quick jump through the stack: We start with a connection factory derived from
ActiveMQConnectionFactory() (C# ConnectionFactory()). This connection factory
returns an IConnection which, as part of the process, creates an ITransport
using a TransportFactory(). In Java, the resource information allows for
various implementations of ITransport which includes FailoverTransport().
Different from C#, the Java implementation breaks out the logic for creating a
transport so that it can be overridden by subclasses if desired. Not sure if we
need that or not.
In the TransportFactory, it all starts with the URI associated with the
connection. The "failover:(URI1, URI2, ..., URIn)" syntax is passed to the
TransportFactory.connect() to create the associated ITransport object. Looking
at TransportFactory.connect() it uses findTransportFactory() to determine which
class to load based upon the location passed. The URI.getScheme() method
returns "failover" which is used to load the failover transport factory
(org.apache.activemq.transport.failover.FailoverTransportFactory.java). This is
based upon the META-INF information which redirects "failover" to that class.
At this point we have a choice. We can allow for dynamic loading of classes
(which can be done - not too hard) allowing for a similar run-time loading of
appropriate classes to support various ITransport interface classes, or we can
punt and do something easy for a compile-time loading of classes. My simple
vote is to do a compile-time reference to the class which we can move to
run-time loading at a future date. I have done run-time loading of classes, so
if desired I can explain how I did it, but do we want that level of complexity
at this point?
Tabling that issue, the fundamental questions now reside around the differences
between TransportFactory() and FailoverTransportFactory(), followed by the
differences between Transport() and FailoverTransport().
The Java version of TransportFactory includes support for composite
connections. This is used to support reliable and HA connections. Basically,
composite connections represent a list of URIs associated with a connection.
Most of the extended functionality of the transports is handled through
subclassing. Want a ITransport that does X, then create a new subclass of
Transport() or something that implements ITransport() and now you have a new
feature X. However, there is a client-side and server-side for feature X (e.g.
SSL). For SSL support, the client must understand how to connect properly, and
the server needs to understand how to accept the connection properly. Thus
some of the classes that support ITransport() also support TransportServer()
which handles the server-side of things (I think this is correct). Not all
features require this to work properly. For instance, the failover: capability
is a client-only feature that does not require server-side coding.
If we are to round-out all the neat features of the Java-based interfaces to be
supported here with .NET, then we need to carefully support this dual concept
of client- and server-side coding for the features.
I think that is the level of complexity that is implied by all the features in
the Java-based code. Essentially it breaks down into two sets of supported
interfaces (Transport and TransportServer) which are required depending upon
the specific feature. The rest of the feature code seems to be dependent upon
the features being implemented.
OK - so what does this mean for our implementation? I would suggest the
following:
1. We create a Failover directory for our files with an implied "Failover"
namespace extension.
2. Create a FailoverTransportFactory.cs and FailoverTransport.cs classes
that will implement our new features (details to follow soon).
3. Explicitly reference this new namespace and based upon the schema
passed either call TcpTransportFactory() or FailoverTransportFactory(). Using
this ITransportFactory create the appropriate ITransport class.
4. As we add new features, we can then decide to continue with this
explicit compile-time structure of referencing the classes, or we can think
about a run-time loading of classes. But that is for the future.
The key feature of FailoverTransportFactory() and FailoverTransport() is the
ability to parse and handle multiple URIs. There is logic to randomly (or
sequentially) try to connect to each URI until success. If successful, then
life is good. If there is a failure, then a try to reconnect is possible as
well as tries to connect to the other URIs specified. Of course, each URI can
have it own connection qualifiers so each needs to be handled independently.
At this point I will stop for comments. The details of how FailoverTransport()
should be implemented are mostly in the Java code, but of course, details vary
for C#.
> 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.
