Folks, I’ve been trying to test my GetJMSQueue configuration so that it detects a dead broker connection and fails over to an alternate broker. When I say dead connection I mean TCP connection that has not been closed but is no longer passing traffic. In the real world this typically happens when broker server crashes and so it does not reset the open connections. For my test case I am using iptables to block traffic.
This is the connection URI I am using failover:(tcp://host2:61616,tcp://host1:61616)?randomize=false&timeout=3000&nested.soTimeout=30000&nested.soWriteTimeout=30000&startupMaxReconnectAttempts=1&maxReconnectAttempts=0 They key parameters here are soTimeout=30000 and soWriteTimeout=30000 These set a 30 second timeout on socket reads and writes. I’m not sure if these are necessary since I believe the JMSConsumer classes specifies its own timeout according to the processor configuration. The important thing to note is that when one of these timeouts occurs the AMQ client does not close the connection. I believe the deficiency here is that JMSConsumer does not consider the possibility that the connection is dead. The problem with this is that an attempt to reconnect and failover to an alternate broker is not made. I think the fix would involve counting the number of sequential empty responses on the connection and then closing the connection once that number crosses some threshold. Then subsequent onTrigger() would cause a new connection attempt. Thoughts? Chris McDermott Remote Business Analytics STaTS/StoreFront Remote HPE Storage Hewlett Packard Enterprise Mobile: +1 978-697-5315 https://www.storefrontremote.com
