ncover21 commented on code in PR #11515:
URL: https://github.com/apache/nifi/pull/11515#discussion_r3777703614
##########
nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java:
##########
@@ -264,6 +296,28 @@ private boolean isRunningOrStarting(final
ReportingTaskNode node) {
return scheduledState == ScheduledState.RUNNING || scheduledState ==
ScheduledState.STARTING;
}
+ /**
+ * Returns the explicit stateless process group that the given process
group belongs to, or {@code null} if the
+ * process group is not part of a stateless group. A group whose execution
engine is {@code INHERITED} resolves to
+ * its nearest ancestor that explicitly declares an execution engine.
+ */
+ private ProcessGroup getStatelessGroup(final ProcessGroup start) {
Review Comment:
Yeah you're right, good catch. And it fails silently rather than erroring
out: `startProcessing()` logs "Cannot start Process Group ... because its
parent is configured to run using the Stateless Engine" and returns, and
`stopProcessing()` returns an already completed future without stopping
anything, so the caller thinks the stop worked.
Fixed in the latest commit. The helper now walks up while the group resolves
to STATELESS and keeps the last one, so it returns the top-most group. Switched
to `resolveExecutionEngine()` too so the INHERITED collapsing is handled there
rather than recursing on it here, and documented the rule on
`ProcessGroup.startProcessing()` / `stopProcessing()`. Tests cover your exact
chain, plus one pinning the no-op itself since `stopComponents()` relies on it
to terminate the recursion during stateless shutdown. The system test now has a
nested subtree whose only referencing processor is in the inner group, it
wouldnt catch this otherwise since a referencing processor in the outer group
masks the nested no-op.
Also worth flagging, the same innermost-resolution helper is copied in
`AffectedComponentSet` (line 461) and `StandardAssetComponentManager` (291),
and `StandardProcessGroupDAO.scheduleComponents()` (310) calls
start/stopProcessing directly on the requested group so it has the same
exposure. Left those alone to keep this PR focused, happy to do a follow up if
you'd prefer.
Let me know what you think, thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
