markap14 commented on pull request #5445: URL: https://github.com/apache/nifi/pull/5445#issuecomment-1046039932
Thanks for adding this @s9514171! I tested it out, and I can verify that CRON driven did in fact remain in a bad state originally and after this PR it does not, so that part works well. I also tested it with event-driven, though, and it did not work. I created a flow: GenerateFlowFile (CRON driven) -> UpdateAttribute (EventDriven) -> UpdateAttribute. Run Once on GenerateFlowFile produced the desired FlowFile. Run Once on the event-driven UpdateAttribute did NOT process the FlowFile. It just left it in the queue. It also left the processor in a state of "RUN_ONCE" which means that I could not start it, edit it, delete it, or run it again. To be honest, my recommendation would be to revert the changes to the EventDrivenSchedulingStrategy completely and leave it as an unsupported operation. Event Driven was an experiment that we tried, in order to reduce CPU utilization that we had with Timer-Driven processors and provide potentially even better latency. However, once we introduced the "Bored Yield Duration" to timer-driven processors, we no longer had an issue with high CPU utilization, and the expense of event-driven ended up being more expensive than Timer-Driven. We've since found a few issues with Event-Driven scheduling strategy that have not been addressed, simply because we marked the feature as Experimental and we expect to remove it entirely (or otherwise completely rewrite it) in the next major version (2.0). Because of this, nobody should ever use the Event-Driven scheduling strategy, right now, and that's why we didn't implement the Run Once capability there to begin with. But the original behavior, of i mmediately failing, is preferable over this behavior of simply not doing anything and leaving the processor in a bad state. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
