[
https://issues.apache.org/jira/browse/NIFI-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425415#comment-15425415
]
ASF GitHub Bot commented on NIFI-2545:
--------------------------------------
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/836
@olegz @joewitt I have pushed a new update to this PR. I did it as a
separate commit so that you can see the changes made. I also rebased against
master.
Fixed issue where we were calling @OnUnscheduled methods before invoking
SchedulingAgent.unschedule - that was a good catch. Also addressed the JavaDocs
and ensured that we use the appropriate Nar ClassLoader.
re: callback vs. passing in ScheduleState - I agree that both do have their
pro's & con's. However, when I was reviewing the code I thought that it was
quite difficult to follow, with the callback. The callback was only about 2-3
lines of code, and could easily just be moved into the StandardProcessorNode,
and this made the code much more straight-forward to read and understand.
Additionally, I do not consider it a leaky abstraction, given that this is the
'start' method of ProcessorNode, and this class's job is to handle the
"framework-y aspect of processors."
Should we need to change it to use a callback in the future, we certainly
can do so. If we do, though, I think we should create an interface that has a
specific method whose name makes sense and is well documented rather than using
a Callable<Boolean> to perform the operation & documenting how that Callable
should operate in the JavaDocs for the method called. I think this is what
really made it confusing to understand.
> Cannot tell a processor is "STOPPING", can edit, cannot restart it
> ------------------------------------------------------------------
>
> Key: NIFI-2545
> URL: https://issues.apache.org/jira/browse/NIFI-2545
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
> Affects Versions: 1.0.0
> Reporter: Joseph Witt
> Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Testing ListenSMTP processor. It has some bad behavior whereby it will not
> stop when told to. But on the UI i cannot tell that at all. So, i went to
> edit the processor config which I was able to do. Then went to start it and
> I get
> {quote}
> 7667f0c7-0156-1000-8181-5b556f8544da cannot be started because it is not
> stopped. Current state is STOPPING
> {quote}
> There should be a visual indicator of its status and we should not be able to
> edit a processor which is not stopped.
> More details on that specific case here
> https://issues.apache.org/jira/browse/NIFI-2519#
> But key is that a bad behaving processor can allow the user to do things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
