@Frank37
Short answer is "No". There is nothing built within the NiDi core controller to accomplish exactly what you are trying to do.
NiFi provides the ability to enable a long running task monitor which will alert to long running component threads, but that is all it does. This new feature was introduced in Apache NiFi 1.14 and disabled by default later in NIFI-8645 because it has an impact on performance because it needs to take thread dumps periodically and is only intended for troubleshooting.
NiFi component processors are just pluggable components. NiFi core handles allocation of thread(s) to a component at component scheduled execution, but after a thread has been given to the processor, it is that processors code that must handle the lifespan of the thread. NiFi core would have no way of knowing how long a thread should or should not take to execute per every processor you add to the canvas.
As you know from the linked article, the thread if truly hung will remain hung until NiFi is restarted, terminate will not kill a thread. So if NiFi was to imply an auto-terminate on all thread taking longer then X, that could be dangerous, Might end up terminating threads that actually do take longer, could end up with a continuously incrementing of hung threads by a misbehaving processor hat goes unnoticed, etc... Also once a thread has been terminated the NiFi core scheduler no longer cares about it, so starting processor again simply allows that processor to get a new thread from the cores Max Timer Driven thread pool.
Best is to figure out why the threads are being hung and address it through processor configuration or code changes as needed.
That being said, anything you can do through the UI can also be accomplished via the NiFi rest-api. This means you could possibly add a MonitorActivity processor after this custom processor that could use a lack of activity generated FlowFile to trigger a dataflow that makes rest-api calls to stop, terminate, and start the processor (but i would not recommend this approach for reason mentioned earlier). But it is not a simple dataflow (involves making request to change processor state stopped, then checking status of processor to see if it stopped or is stopping (where stopping indicates it is waiting on active threads), if it is "stopping" make a request to terminate thread, and finally restart processor). This also assumes a continuous flow fo FlowFiles through he processor. If it gets FlowFiles sporadicly, this would not work well.
If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped.
Thank you,
Matt
