Hi Eduardo, It looks like the Remote Processor Group Port is blocking on some call. I couldn't reproduce the issue with a similar setup, even after stopping and restarting nifi multiple times.
Could you create a Jira issue and attach your config files? A stack trace could also be helpful, if you can start minifi in a debugger and interrupt while it's stuck inside that onTrigger. Can you reproduce the issue with the previous minifi c++ release? If you rely on site-to-site for some production workflow, I suggest switching to MergeContent + InvokeHTTP and ListenHTTP on the nifi side. This use case has received a lot of attention lately, so I think it's both faster and more stable. Not sure if we should tank the release due to this issue, so I will leave my vote in place. Thanks, Marton On Wed, 24 Nov 2021 at 11:12, Eduardo Fontes <eduardo.fon...@gmail.com> wrote: > > Hi all, > > I've tested minifi 0.11 + Nifi 1.15 and I got warnings that I don't know if > it's a version issue. > > How to reproduce: > - Download and unpack Nifi 1.15 binary > - Download, unpack and compile Minifi 0.11 source > - Start Nifi with default settings, create a remote input port with name > "entrada", start it and connect it to a funnel > - Configure minifi TLS > - Configure minifi's flow (config.yaml) with a ExecuteCommand (find ./ each > 30 secs) with success relationship to a RPG pointing to NiFi 1.15 "entrada" > input port > - Start minifi > > At this point everything is ok. The result of the command "find ./" lands > on the NiFi input port and stays in the funnel's queue. > > The problem is, if NiFi stops for some reason (a real world case), I start > to get warnings in minifi's log the like: > [org::apache::nifi::minifi::SchedulingAgent] [warning] entrada::onTrigger > has been running for 971026 ms in 4d3e32ac-017d-1000-b4b1-e7f36e039202 > > And if I start NiFi the warnings continue and it never stops. In this > state, if I try to stop minifi using "minifi.sh stop" it doesn't stop and I > have to kill the minifi's process. > It seems the thread stuck. > > Is this only with me? Am I doing something wrong? > Please let me know. > > Thanks everybody. > Eduardo Fontes > > On Wed, Nov 24, 2021 at 6:56 AM Pierre Villard <pierre.villard...@gmail.com> > wrote: > > > +1 (binding) > > > > Followed the usual steps to build the agent on my MBP and test it with a > > simple flow. > > > > Thanks Adam for taking care of this release! > > > > Pierre > > > > Le mer. 24 nov. 2021 à 10:49, Ádám Markovics <nullzer...@gmail.com> a > > écrit : > > > > > +1 (non-binding) > > > Verified and built on Ubuntu 20.04. Ran tests and also ran a simple > > > (GetFile > > > -PutFile) flow. > > > Regards, > > > > > > Ádám > > > > > > On Mon, Nov 22, 2021 at 6:44 PM Marton Szasz <sza...@apache.org> wrote: > > > > > > > +1 (binding) > > > > > > > > Followed the release helper guide. Tested compilation with both GCC 11 > > > > and Clang 13 (with libstdc++). > > > > Used the convenience binary to collect systemd-journald messages from > > > > an ubuntu 16.04 VM and forward them via InvokeHTTP to a ListenHTTP > > > > listener on host. The host was running the clang-compiled release > > > > candidate agent. > > > > Manually removed unused extensions now that we have them in separate > > > > .so files, just to see that it's still working. Everything went > > > > smoothly. > > > > > > > > Thanks, > > > > Marton > > > > > > > > > > > > On Mon, 22 Nov 2021 at 16:08, Ferenc Gerlits <fgerl...@apache.org> > > > wrote: > > > > > > > > > > +1 (non-binding) > > > > > > > > > > - verified hashes and signatures > > > > > - compiled sources, ran unit tests > > > > > - ran convenience binary with a Generate Flow File -> Log Attribute > > > flow > > > > > using C2 with TLS > > > > > > > > > > Everything worked as expected. > > > > > > > > > > Thanks, > > > > > Ferenc > > > > > > > > >
