joewitt commented on PR #11164: URL: https://github.com/apache/nifi/pull/11164#issuecomment-5639763405
Interrupt status kills the scheduling loop — share this This is a real behavioral change versus the current pool. Today, TimerDrivenSchedulingAgent submits a short-lived Runnable to FlowEngine. After onTrigger returns, that task is done. The next fire is a new executor task on a worker that has a clean interrupt flag. Processors that catch InterruptedException and do the textbook Thread.currentThread().interrupt() are therefore fine. On this PR, each concurrent task is one virtual thread that never dies: invoke() → waitForDelay() → acquirePermitWithPolling() → invoke() … If onTrigger leaves the interrupt flag set: waitForDelay() hits CountDownLatch.await and immediately throws InterruptedException. The catch restores the interrupt (Thread.currentThread().interrupt()). Next iteration, tryAcquire(...) throws immediately. acquirePermitWithPolling returns false, and runSchedulingLoop returns. The Processor stays RUNNING. The generation is still registered. Nothing reschedules that task. UI/thread count can look healthy. Throughput for that concurrent slot is just gone until stop/start. I reproduced the primitive on JDK 21: a platform-pool worker’s next task is not interrupted; a persistent virtual thread that restored interrupt does fail the next timed wait. This is not exotic. NiFi itself does this (e.g. DebugFlow, ExecuteProcess, ConsumeKafka backlog path, AMQP, Kinesis, HDFS, Listen processors). Any extension that “restores interrupt status and returns” is now a silent death sentence for that scheduling chain. Ask Mark to either: clear interrupt at a defined framework boundary after onTrigger unless shutdown/unschedule requested the interrupt, or use a fresh virtual thread per invocation (old model, virtualized), or treat interrupt as “this invocation was cancelled” and continue the loop if lifecycleState.isScheduled(). A regression test is easy: Processor that interrupt()s itself in onTrigger must fire again without a restart. Same for a Reporting Task. -- 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]
