On Sat, Dec 9, 2017 at 11:02 PM Arthur Naseef <[email protected]> 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 <[email protected] > > > 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 <[email protected]> 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
