activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Date Mon, 11 Dec 2017 01:43:08 GMT
I understand.  I thought you were proposing a code change.

On Sun, Dec 10, 2017 at 8:13 PM Arthur Naseef <art@amlinv.com> wrote:

> 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
> >
>
-- 
Clebert Suconic

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