[
https://issues.apache.org/jira/browse/NIFI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062160#comment-15062160
]
Oleg Zhurakousky commented on NIFI-78:
--------------------------------------
Joe
I've done some digging and here is what we have:
As far as disconnecting and stopping Processor, that actually works already. I
was able to confirm that the Processor indeed stops and no longer scheduled.
The only reason why user can't perform any modification to its configuration is
because there are active threads (the little square at the top right corner).
Now, we can, with the UI kill option, ignore active threads and consider
Processor fully stopped, hence allowing configuration change, but. . . .
I am starting to wonder if instead of fixing the problem we will actually
create one bigger problem. Basically the only way this would work if user
changes configuration and still restarts NiFi. If user decides to simply
restart the re-configured processor then . . . who knows what's then, since we
still have those runaway active threads doing who knows what. On top of that we
don't know the state of the FlowFile currently in progress. For example, if the
thread blockage occurs after FlowFile was "completed", then rolling it back
somehow would mean that it will be reprocessed (duplicate), and if we don't
roll back and the thread blockage is before then we have data loss. Basically
chicken and egg.
So I want to make sure it is understood.
Having said that I am now willing to say this; These type of issues with
processors are typically a bug somewhere and in a typical development/testing
cycle would/could/should be addressed during such cycle. That doesn't mean that
nothing ever goes wrong in production, but it would limit the chances of that
happening. With this said I am starting to wonder if this JIRA needs any
addressing at the code level or should it simply be documented.
One last thing is that _Thread.stop()_ is still an option as long as we are
willing to document that this is an *abrupt end* (a true kill) and no
guarantees can't be made to the state of the FlowFile in progress.
> 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)
