[
https://issues.apache.org/jira/browse/NIFI-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16400833#comment-16400833
]
Bryan Bende commented on NIFI-543:
----------------------------------
[~sivaprasanna] I actually don't think there should be a method
_setExecutionNodeRestricted_ because nothing outside of the node should ever be
telling the node it is restricted... the node knows if it is restricted based
on the underlying Processor and whether or not the processor has the new
@PrimaryNodeOnly annotation.
I think it is correct to have the internal _AtomicBoolean
executionNodeRestricted_ and the getter so that we can return to the UI whether
or not it is restricted, but nothing should ever be passing in whether it is
restricted or not.
The _setExecutionNode_ method should prevent setting a scheduling strategy that
doesn't make sense:
{code:java}
@Override
public synchronized void setExecutionNode(final ExecutionNode executionNode) {
if (this.executionNodeRestricted.get() && executionNode !=
ExecutionNode.PRIMARY) {
// throw some exception
}
this.executionNode = executionNode;
}{code}
Given the above, I don't think the versioned flow needs to store the boolean...
When creating a new flow from the registry, a new StandardProcessorNode will be
created and given a new Processor which will set the internal boolean, then
later on the code you referenced in StandardProcessGroup will apply the
ExecutionNode by calling the setter above, and if somehow the flow got saved to
the registry with non-primary node execution then it will throw the exception,
but that would never happen for a flow saved to registry by NiFi UI.
> Provide extensions a way to indicate that they can run only on primary node,
> if clustered
> -----------------------------------------------------------------------------------------
>
> Key: NIFI-543
> URL: https://issues.apache.org/jira/browse/NIFI-543
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework, Documentation & Website, Extensions
> Reporter: Mark Payne
> Assignee: Sivaprasanna Sethuraman
> Priority: Major
>
> There are Processors that are known to be problematic if run from multiple
> nodes simultaneously. These processors should be able to use a
> @PrimaryNodeOnly annotation (or something similar) to indicate that they can
> be scheduled to run only on primary node if run in a cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
