Chris Given that we are deprecating Get/PutJMS* in favor of Publish/SubscribeJMS, I’d suggest start using those once.
Cheers Oleg > On Jun 16, 2016, at 1:34 PM, McDermott, Chris Kevin (MSDU - > STaTS/StorefrontRemote) <[email protected]> wrote: > > 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
