activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arthur Naseef <...@amlinv.com>
Subject Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Date Mon, 11 Dec 2017 01:13:39 GMT
Initial connect is where I'm seeing this now Clebert.  It can choose from
multiple nodes, but only sticks to one until the retries are exhausted.
However, I have unlimited retries, so the client is pinned.

On Sun, Dec 10, 2017 at 7:44 AM, Clebert Suconic <clebert.suconic@gmail.com>
wrote:

> On Sat, Dec 9, 2017 at 11:02 PM Arthur Naseef <art@amlinv.com> wrote:
>
> > Thanks Clebert.  Reconnect-at-any-node sounds very similar - the only
> real
> > difference is the "initial connection" versus reconnect.
> >
>
> Initial connect could always look at other nodes.
>
> >
> > In my mind, the desired operation is the same for initial connect versus
> > reconnect.  Are you aware of a desire to do differently?
>
>
> We have a JIRA but failover is easy to mess up. There was something else
> with higher priority (Open wire, amqp,... etc etc)
>
>
>
>
> >
> > Art
> >
> >
> > On Sat, Dec 9, 2017 at 7:33 AM, Clebert Suconic <
> clebert.suconic@gmail.com
> > >
> > wrote:
> >
> > > There is a JIRA open in artemis.  Reconnect at any node.
> > >
> > > We could add a property as reconnect any node.  And make the change you
> > > mentioned.
> > >
> > > That’s a different semantic between the two. I can dig for the jira
> later
> > > if you like. I am  Typing on the phone now.
> > >
> > > On Fri, Dec 8, 2017 at 4:01 PM Arthur Naseef <art@amlinv.com> wrote:
> > >
> > > > Note that I'm doing much of this for the first time, and not finding
> > > > examples on the website, so I expect there's a good chance I'm
> missing
> > > > something.
> > > >
> > > > Summary of the problem:
> > > >    * Clients get pinned to a single broker url when attempting to
> > > connect,
> > > > when using infinite connect attempts.
> > > >
> > > > Background:
> > > >     I'm attempting to setup the Artemis client in a way that will get
> > > > parity with the AMQ 5.x failover transport's default operation
> (without
> > > > optional configuration settings) using static broker urls:
> > > >
> > > >     * Client is configured with 2 (possibly more) broker URLs
> > > >     * Brokers are configured to run active/passive
> > > >     * All connection failures hidden from the client code; that is:
> > > >         * Application blocks indefinitely on JMS operations when
> > > connection
> > > > to broker is down
> > > >         * Application never gets an exception when the connection to
> > the
> > > > broker is down
> > > >         * Log messages recorded when connections lost and recreated
> > > >
> > > >
> > > > Artemis client setup:
> > > >     import
> > > > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;
> > > >
> > > >     ActiveMQConnectionFactory connectionFactory = new
> > > > ActiveMQConnectionFactory("broker-url: tcp://localhost:61616#tcp://
> > > > localhost:61617");
> > > >
> > > >     connectionFactory.setInitialConnectAttempts(-1); // Inifinite
> > > >     connectionFactory.setReconnectAttempts(-1); // Infinite
> > > >     connectionFactory.setMaxRetryInterval(1000); // 1 second
> > > >
> > > >
> > > > Test steps:
> > > >     * All brokers are SHUTDOWN
> > > >     * Start the client
> > > >     * Start either broker
> > > >
> > > >
> > > > Expected:
> > > >     * Client reliably connects to the broker that starts, within the
> > > > max-reconnect period
> > > >
> > > >
> > > > Actual:
> > > >     * Client only connects sometimes; other times, it remains
> > > disconnected
> > > > indefinitely
> > > >
> > > >
> > > > Diagnosing:
> > > >     * Using the debugger and reading the code, found the following
> key
> > > > points in the code:
> > > >
> > > > ServerLocatorImpl.java:771
> > > >         TransportConfiguration tc = selectConnector();
> > > > ClientSessionFactoryImpl.java:1086
> > > >         Connector liveConnector = createConnector(connectorFactory,
> > > > connectorConfig);
> > > > NettyConnector.java:575
> > > >         * host and port
> > > >
> > > >     * The host and port in the Netty Connector remain the same on
> every
> > > > call.  The retry logic is in ClientSessionFactoryImpl, which does not
> > > have
> > > > access to reselect the connector.  In other words, the client gets
> > Pinned
> > > > to the one broker url.
> > > >     * Changing the initialConnectAttempts() to a small value, it is
> > > > possible to see that the selectConnector will get called, and choose
> > the
> > > > other broker url, after reconnect.  However, this means connection
> > > failures
> > > > will cause exceptions thrown to the application.
> > > >
> > > >
> > > > If my findings appear to be incorrect, please let me know and help me
> > to
> > > > correct them.  Otherwise, please let me know and I should be able to
> > work
> > > > toward getting a fix.
> > > >
> > > > Art
> > > >
> > > --
> > > Clebert Suconic
> > >
> >
> --
> Clebert Suconic
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message