Hello, In light of the issue found (not yet reproduced), and the lack of binding votes, I am cancelling RC1. We will investigate the issue, stay tuned for RC2.
Thanks, Adam On Thu, Nov 25, 2021 at 3:03 AM Eduardo Fontes <[email protected]> wrote: > Hi Marton, > > I've just downloaded and compiled 0.10 minifi c++ > The issue doesn't happen. > When I stop the input port in NiFi I get this: > > [org::apache::nifi::minifi::core::Processor] [warning] Caught "Process > Session Operation: Can not find the transfer relationship for the updated > flow 89289e16-4d90-11ec-bef4-c0b6f9f714b7" > (N3org6apache4nifi6minifi9ExceptionE) during Processor::onTrigger of > processor: 4d3e32ac-017d-1000-b4b1-e7f36e039202 (entrada) > > And when I start the input port again it comes back to work normally. > > The issue doesn't happen with MiNiFi 1.15 Java version too. > > I've created a Jira (https://issues.apache.org/jira/browse/MINIFICPP-1692) > for this. > > Thanks. Regards. > Eduardo Fontes > > On Wed, Nov 24, 2021 at 2:45 PM Marton Szasz <[email protected]> wrote: > > > 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 <[email protected]> > > 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 < > > [email protected]> > > > 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 <[email protected]> > 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 <[email protected]> > > 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 < > [email protected]> > > > > > 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 > > > > > > > > > > > > > > > > > >
