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
