So does that mean that I cannot use the AMQ client packaged with NiFi but rather provide my own?
Sorry if I an being obtuse. 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, 2:53 PM, "Oleg Zhurakousky" <[email protected]> wrote: >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 >>> >> >
