Ian, With run duration the idea is that the processor will be allowed to keep executing for that period of time and the framework will keep giving it the same process session. For the developer this means they get to keep their logic very simple and discrete to a single operation but that the framework will take care of batching those operations together as one for up to 'X secs' of run duration.
For event driven the idea is that rather than telling the framework you want the processor to run every X units of time as is the case in timer driven with event driven the framework will execute the processor (give it thread/call ontrigger) whenever there is data being placed into its queue. It can be more efficient in some cases. Thanks Joe On Thu, Dec 10, 2015 at 8:59 PM, ianwork <[email protected]> wrote: > Bryan/Aldrin, Adding yielding into my processor prevent the number of tasks > was rapidly increasing. Thanks! > > Aldrin, I would like to dig a little more into the details. My application > is basically set do process logs like logstash. The application is reading > and parsing a high volume of logs. The listener is based up listenSyslog. > The listener forwards the logs to various processors which run regex's on > batches of logs. Increasing the number of regex processors reduces the > performance so i'd like to determine how I can configure the system > resources. > > I'm still struggling with run duration. Does setting run duration mean that > when a thread is allocated to the ontrigger method of that processor it will > run for a maximum of run duration? What if the method executes faster than > the run duration, will ontrigger be called again if there is work to be > done? > > > Is the event driven mode something to consider in my type of processor? > What use cases was that designed to satisfy and is there any documentation > on that? > > > > > -- > View this message in context: > http://apache-nifi-developer-list.39713.n7.nabble.com/Asynchronous-JMS-Consumer-for-IBM-MQ-tp3919p5715.html > Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.
