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 Sat, 09 Dec 2017 14:33:55 GMT
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

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