Oleg, I’ve determined that ConsumeJMS has exactly the same problem. Do a ‘reboot –f now’ on the node running the JMS broker and ConsumeJMS will not notice a problem until the TCP timeout which could be hours, days, or even never. We could easily fix this in GetJMSQueue, but ConsumeJMS is implemented using the Spring Framework’s JMS library and any fix would probably have to come from the Spring Community.
I’d like to file a couple of Jiras on this but will wait for your response. Thanks, Chris McDermott Remote Business Analytics STaTS/StoreFront Remote HPE Storage Hewlett Packard Enterprise Mobile: +1 978-697-5315 On 6/16/16, 1:43 PM, "Oleg Zhurakousky" <[email protected]> wrote: >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 >
