Yes, you can probably look at the test case for it since it uses embedded AMQP.
Let m know if you need more help with it. Cheers Oleg > On Jun 16, 2016, at 2:50 PM, McDermott, Chris Kevin (MSDU - > STaTS/StorefrontRemote) <[email protected]> wrote: > > 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 >> >
