Hi Peter, and thank you for your response. You are right: I was trying to use Run Once. Does this prohibition against Run Once also apply to PublishAMQP? If Run Once should not be used for a processor, would folks consider disabling that processor menu option on ConsumeAMQP (and PublishAMQP, should this be the same case there too)? Jim
On Mon, Jul 8, 2024 at 8:38 AM Peter Turcsanyi <turcsa...@apache.org> wrote: > Hi James, > > The logs show that the processor stopped just after it was started (within > the same second: 17:23:39 UTC). > > If it is due to closing the channel by the broker prematurely, then there > should be some error logs too. Could you please check if there are other > log messages? > > You may be trying to run ConsumeAMQP with Run Once. Please note, this > processor cannot work in that mode. The underlying AMQP client starts up a > consumer in a background thread which receives the messages asynchronously > and puts them into an internal queue for further processing by the > processor's main thread. This process continues while the processor is in > scheduled state. Run Once stops the processors immediately so when the > messages arrive, they will be discarded due to the processor's stopped > state. > Have you tried it with starting the processor and giving some time to the > client to get initialized and receive the messages? > > Best regards, > Peter Turcsanyi > > > On Mon, Jul 8, 2024 at 12:34 PM James McMahon <jsmcmah...@gmail.com> > wrote: > >> Wanted to follow up in case it serves others in the future. >> I stepped through these changes before I got this to work: >> >> 1. My associate extended the heartbeat on the RMQ host. >> 2. I made two changes to NiFi's bootstrap.conf, restarting NiFi after >> editing the file to pick up these changes: >> ..... java.arg.X=-Dcom.rabbitmq.client.heartbeat=120 >> ..... java.arg.X=-Dcom.rabbitmq.client.connection_timeout=30000 >> 3. I had experimented with settings on a few properties in ConsumeAMQP >> 2.0.0-M2. It works with these set as follows: >> ..... Auto-Acknowledge Messages false >> ..... Prefetch Count 1 >> >> On Fri, Jul 5, 2024 at 1:28 PM James McMahon <jsmcmah...@gmail.com> >> wrote: >> >>> I have a queue in RabbitMQ that I try to ConsumeAMQP from, configured >>> like this: >>> >>> Queue >>> detection-responses >>> Auto-Acknowledge Messages >>> false >>> Batch Size >>> 1 >>> Prefetch Count >>> 0 >>> Header Output Format >>> Comma-Separated String >>> Header Separator >>> , >>> Remove Curly Braces >>> False >>> BrokersNo value setHost Name >>> 18.235.119.166 >>> Port >>> 5672 >>> Virtual Host >>> / >>> User Name >>> Admin >>> Password Sensitive value >>> setAMQP Version >>> 0.9.1 >>> SSL Context Service >>> No value set >>> Use Client Certificate Authentication >>> false >>> >>> My messages are not successfully consumed into my nifi flow. This is >>> what I find in my log: >>> >>> 17:23:39 UTC >>> INFO >>> 1134134d-1ec5-158c-c3db-526be43cd3fa >>> >>> ConsumeAMQP[id=1134134d-1ec5-158c-c3db-526be43cd3fa] Successfully connected >>> AMQPConsumer to amqp://Admin@18.235.119.166:5672/ and 'detection-responses' >>> queue >>> >>> 17:23:39 UTC >>> DEBUG >>> 1134134d-1ec5-158c-c3db-526be43cd3fa >>> >>> ConsumeAMQP[id=1134134d-1ec5-158c-c3db-526be43cd3fa] Closing AMQP channel >>> for amqp://Admin@18.235.119.166:5672/ >>> >>> 17:23:39 UTC >>> INFO >>> 1134134d-1ec5-158c-c3db-526be43cd3fa >>> >>> ConsumeAMQP[id=1134134d-1ec5-158c-c3db-526be43cd3fa] Consumer is closed, >>> discarding message (delivery tag: 1). >>> >>> Auto-refresh >>> >>> >>> >>> Is this because the channel is closing prematurely? Is there a queue >>> property I must set to keep it open? >>> >>> Thank you for any help. >>> >>
