You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nifi.apache.org by "Oleg Zhurakousky (JIRA)" <ji...@apache.org> on 2015/12/16 22:04:46 UTC

[jira] [Comment Edited] (NIFI-78) Add interrupt option for stopped processors with active threads

    [ https://issues.apache.org/jira/browse/NIFI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060852#comment-15060852 ] 

Oleg Zhurakousky edited comment on NIFI-78 at 12/16/15 9:04 PM:
----------------------------------------------------------------

To address this we need two things:
1. UI option to express the intent to interrupt (e.g., a separate button, or a popup on existing shutdown functionality asking user if processor should be interrupted) - NIFI-1295
2. Attempt to interrupt a running processor.

The first one I assume is trivial while the second one is not
Basically with _Thread.stop()_ deprecated there seem to be no other "clean" option (still digging though) to guarantee that the thread will stop. In other words simple _Thread.interrupt()_ will be meaningless unless the Processor's code is written to react to interrupts. Also, even if we were to allow _Thread.stop()_ it would not help us with the second point Joe made "_results are ends up in rollback_", since by definition it would put the entire thread into unreliable state releasing all the locks etc. In other words the best we can do is issue _Thread.interrupt()_. The rest should be handled by "best practices and guidelines on how to write interruptible NiFi components". 


was (Author: ozhurakousky):
To address this we need two things:
1. UI option to express the intent to interrupt (e.g., a separate button, or a popup on existing shutdown functionality asking user if processor should be interrupted)
2. Attempt to interrupt a running processor.

The first one I assume is trivial while the second one is not
Basically with _Thread.stop()_ deprecated there seem to be no other "clean" option (still digging though) to guarantee that the thread will stop. In other words simple _Thread.interrupt()_ will be meaningless unless the Processor's code is written to react to interrupts. Also, even if we were to allow _Thread.stop()_ it would not help us with the second point Joe made "_results are ends up in rollback_", since by definition it would put the entire thread into unreliable state releasing all the locks etc. In other words the best we can do is issue _Thread.interrupt()_. The rest should be handled by "best practices and guidelines on how to write interruptible NiFi components". 

> Add interrupt option for stopped processors with active threads
> ---------------------------------------------------------------
>
>                 Key: NIFI-78
>                 URL: https://issues.apache.org/jira/browse/NIFI-78
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>            Reporter: Joseph Witt
>            Assignee: Oleg Zhurakousky
>            Priority: Minor
>             Fix For: 0.5.0
>
>
> Some processors have really long stopping periods.  Would be nice to be able to forcibly kill them if possible.  Otherwise certain flow changes cannot occur.  This is one part best practices and another part helping the user decide when to forcibly kill a processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)