Re: Static processor design

Russ, If you're going to process a flowfile by a processor via ProcessSession (even if "process" does nothing but pass the FF along, unmodified), you still need to get it from the session and subsequently transfer it to a relationship. My suggestion was meant to indicate you can handle multiple

Re: Static processor design

Mark, Thanks for responding. I think my question is a little more naive than that on my part. I want to get those files through there as fast as possible. If I ask for /n/ files, how many would contribute to them getting them through the quickest? After all, I will do nothing at all to any

Re: Static processor design

Russell, You can use "session.get(N)" where N is an integer. This will get up to N flowfiles per OnTrigger() call. -Mark On Fri, Jan 8, 2021 at 5:07 PM Russell Bateman wrote: > Very well, I have decided to force customer flowfiles through this > processor (I did check out the /Listen/*

Re: Static processor design

Very well, I have decided to force customer flowfiles through this processor (I did check out the /Listen/* processors, but chose this easier solution). This now works. However, It brings up another question: is this the most efficient way to pass flowfiles straight through this processor

Re: Static processor design

*ListenDynamicPropertyChange > On Jan 8, 2021, at 12:42, Otto Fowler wrote: > > So you would be implementing ListDynamicPropertyChange kind of. > > >> On Jan 8, 2021, at 12:41, Otto Fowler > > wrote: >> >> What are the attributes of the processor? >> Do you

Re: Static processor design

So you would be implementing ListDynamicPropertyChange kind of. > On Jan 8, 2021, at 12:41, Otto Fowler wrote: > > What are the attributes of the processor? > Do you have : > > @InputRequirement(InputRequirement.Requirement.INPUT_FORBIDDEN) > or anything? > > You should take a look at the

Re: Static processor design

What are the attributes of the processor? Do you have : @InputRequirement(InputRequirement.Requirement.INPUT_FORBIDDEN) or anything? You should take a look at the Listen** processors. They do not have any inputs etc, and run processing queued input from a background thread. You can have on

Re: Static processor design

I only put the code I want to execute in onTrigger(), I suspected it would not fire there. I know that this isn't what processors do. Configuration is a messy problem to solve when your downstreamers want it made easy. This is supposed to be a solution that allows them to remain in the NiFi UI

Re: Static processor design

Timer Driven/onTrigger (I think) will only fire when an incoming FlowFile is received, thus triggering the processor to execute. But you mention not having any connections (presumably incoming or outgoing), so I guess that's not what you're after? You could try a Scheduling Strategy of "Cron"

Re: Static processor design

Russell, Are you trying to execute the code in onTrigger() only if a dynamic property has been modified? If so you could have a boolean member variable "shouldRun" that gets set to true in onPropertyModified() and checked/reset in onTrigger(). The scripting components do something similar, to

Re: Static processor design

The code I really want to run is sitting in onTrigger(), though I could move it elsewhere. Yes, I have tried *Scheduling Strategy*of Timer driven *Run Schedule*of 10 sec ...but the getLogger().info( "called from onTrigger()" )never reaches /logs/nifi-app.log/ (while the logging statement

Static processor design

(Inadequate title; didn't know what to call it.) I have written a processor that doesn't feature any relationships. It accepts dynamically properties that, in theory, when created (or removed, or values added or changed), and sets data into a class inside my NAR. I wonder, however, at what