Thanks Clebert. Reconnect-at-any-node sounds very similar - the only real
difference is the "initial connection" versus reconnect.
In my mind, the desired operation is the same for initial connect versus
reconnect. Are you aware of a desire to do differently?
Art
On Sat, Dec 9, 2017 at 7:33 AM, Clebert Suconic <clebert.suco...@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 <a...@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
>
