activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Gellings (JIRA)" <>
Subject [jira] Created: (AMQNET-159) Make failover protocol optionally asynchronously connect to sockets
Date Fri, 24 Apr 2009 19:32:38 GMT
Make failover protocol optionally asynchronously connect to sockets

                 Key: AMQNET-159
             Project: ActiveMQ .Net
          Issue Type: New Feature
          Components: ActiveMQ Client
    Affects Versions: 1.1
         Environment: XP, Windows Server 2008, Sql Server 2008
            Reporter: Mark Gellings
            Assignee: Jim Gomes
             Fix For: 1.1

The current failover transport synchronously attempts to socket connect to a broker.  Preferably
we would first socket connect trying the master address in the failover address to avoid a
socket connection timeout.  When the first tcp address in the failover address is the slave,
its connectors are not started, and .NET takes around 20 - 25s to timeout trying to socket
connect to the slave.  Thus the client is waiting 20-25s to submit a message when the session
is first established.

Since the first tcp address in the failover address is never guaranteed to be the master,
I've coded an enhancement that optionally allows to asynchronously socket connect utilizing
all the tcp addresses in the failover address.  I have a patch you can apply.

The following failover address is an example of how to use the async connect.

private static Uri _uri = new Uri("failover:(tcp://,tcp://");

This will cause the failover transport to attempt connecting to WAMQDEV1 and SXMQDEV1 at the
same time to avoid the impact of any socket connect timeouts.  First broker connected to becomes
the transport utilized.  If WAMQDEV1 broker is not running or is running the slave broker
then if SXMQDEV1 is running the master broker the client will connect to SXMQDEV1.

AsyncTimeout is the max time in milliseconds to wait for a transport to be initialized.  So
if both brokers are down, in the example above, after 20000 milliseconds the normal retry
logic will kick in.

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

View raw message