I am looking to change the code, if necessary, to get this working.
I'll look for you on IRC; it may be easier to clarify that way.
On Sun, Dec 10, 2017 at 6:43 PM, Clebert Suconic <clebert.suco...@gmail.com>
wrote:
> I understand. I thought you were proposing a code change.
>
> On Sun, Dec 10, 2017 at 8:13 PM Arthur Naseef <a...@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.suco...@gmail.com>
> > wrote:
> >
> > > On Sat, Dec 9, 2017 at 11:02 PM Arthur Naseef <a...@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.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
> > > > >
> > > >
> > > --
> > > Clebert Suconic
> > >
> >
> --
> Clebert Suconic
>
