Yes, that is documentation bug. Chris would you mind raising a JIRA or I can do it.
Cheers Oleg > On Jun 16, 2016, at 3:15 PM, Joe Witt <[email protected]> wrote: > > Oleg - so to Chris' other comment about docs suggesting the ActiveMQ > lib path is not needed - is that a doc bug? > > On Thu, Jun 16, 2016 at 3:13 PM, Oleg Zhurakousky > <[email protected]> wrote: >> Chris >> >> That is correct. >> The idea was to make sure that we can support multiple clients and multiple >> vendors since Get/Put only supported AMQP and only one version. The new JMS >> support allows you to use any JMS vendor and the only extra work we are >> asking you to do is to provide ConnectionFactory JAR(s). >> >> Does that clarify? >> >> Also, yeh tests I was referring to are >> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/test/java/org/apache/nifi/jms/processors >> >> Let me know if you need more help >> Cheers >> Oleg >> On Jun 16, 2016, at 3:08 PM, McDermott, Chris Kevin (MSDU - >> STaTS/StorefrontRemote) >> <[email protected]<mailto:[email protected]>> wrote: >> >> 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 >> >> >> >> >> >
