Thanks, Oleg. Do you have an example of how to configure the JMSConnectionFactoryProvider to work with AMQ?
The documentation says that the MQ Client Libraries path is optional with org.apache.activemq.ActiveMQConnectionFactory but I am find that is not the case. Thanks, Chris McDermott Remote Business Analytics STaTS/StoreFront Remote HPE Storage Hewlett Packard Enterprise Mobile: +1 978-697-5315 https://www.storefrontremote.com 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 >
