You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Arthur Naseef <ar...@amlinv.com> on 2017/12/08 21:01:30 UTC
Artemis client pinned to 1 of 2 brokers when attempting to connect
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
Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Posted by Arthur Naseef <ar...@amlinv.com>.
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 <cl...@gmail.com>
wrote:
> I understand. I thought you were proposing a code change.
>
> On Sun, Dec 10, 2017 at 8:13 PM Arthur Naseef <ar...@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 <ar...@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 <ar...@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
>
Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Posted by Clebert Suconic <cl...@gmail.com>.
I understand. I thought you were proposing a code change.
On Sun, Dec 10, 2017 at 8:13 PM Arthur Naseef <ar...@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 <ar...@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 <ar...@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
Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Posted by Arthur Naseef <ar...@amlinv.com>.
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 <cl...@gmail.com>
wrote:
> On Sat, Dec 9, 2017 at 11:02 PM Arthur Naseef <ar...@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 <ar...@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
>
Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Posted by Clebert Suconic <cl...@gmail.com>.
On Sat, Dec 9, 2017 at 11:02 PM Arthur Naseef <ar...@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 <ar...@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
Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Posted by Arthur Naseef <ar...@amlinv.com>.
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 <cl...@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 <ar...@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
>
Re: Artemis client pinned to 1 of 2 brokers when attempting to connect
Posted by Clebert Suconic <cl...@gmail.com>.
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 <ar...@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