[
https://issues.apache.org/jira/browse/NIFI-16174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109320#comment-18109320
]
ASF subversion and git services commented on NIFI-16174:
--------------------------------------------------------
Commit 2597636c8e363725d2cc0769f360bcf77ad8378c in nifi's branch
refs/heads/main from Noah
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=2597636c8e3 ]
NIFI-16174 - Treat a stateless process group as a single lifecycle unit when
starting/stopping a controller service's referencing components (#11515)
* NIFI-16174 - Treat a stateless process group as a single lifecycle unit when
starting/stopping a controller service's referencing components
StandardControllerServiceProvider scheduled processors that reference a
controller service individually, even when they belong to a stateless process
group. Because a stateless group is a single scheduling unit, this left the
group with a mixed running/stopped processor state and a group node stuck
RUNNING, from which it could not recover.
Resolve each referenced processor's owning stateless group (STATELESS -> self,
INHERITED -> nearest explicit ancestor) and, for stateless members, stop the
group once via ProcessGroup.stopProcessing() / start it once via
ComponentScheduler.startStatelessGroup(), mapping the group's single future to
every affected member. Standard processors are unchanged. Public
ControllerServiceProvider signatures are unchanged.
Adds unit coverage in StandardControllerServiceProviderTest and an end-to-end
regression (ConnectorTroubleshootingIT) backed by a stateless controller-service
reference in the ComponentLifecycleConnector test fixture.
* Update ComponentLifecycleConnector.java
* NIFI-16174 - Guard against null execution engine when resolving the owning
stateless group
A referenced processor's process group can report a null execution engine
(e.g. in unit-test fixtures backed by mock process groups). Treat a null
engine as non-stateless so getStatelessGroup returns null and the processor
is handled on the standard per-component path, rather than throwing an NPE
in the switch.
* NIFI-16174 - Resolve the top-most stateless group when starting/stopping a
controller service's referencing components
The previous helper returned the inner-most Process Group marked STATELESS. Only
the top-most stateless group may be started or stopped directly, so on a nested
stateless chain both paths became silent no-ops: startProcessing() logs a
warning
and returns, and stopProcessing() returns an already-completed Future without
stopping anything.
Walk up while the group resolves to STATELESS and operate on the last one.
Document the rule on ProcessGroup.startProcessing()/stopProcessing(), and pin
the
no-op with a test, since it is what terminates the recursive stopComponents()
walk
during stateless shutdown.
The system test now carries a second stateless subtree whose only referencing
processor lives in a nested stateless group, which is what makes it
discriminate:
when a referencing processor exists in the outer group too, the outer group's
transition masks the nested no-op.
> Controller-service reference start/stop does not treat a stateless process
> group as a single lifecycle unit
> -----------------------------------------------------------------------------------------------------------
>
> Key: NIFI-16174
> URL: https://issues.apache.org/jira/browse/NIFI-16174
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Noah Cover
> Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When schedulable components that reference a controller service are started
> or stopped
> via the controller-service "references" path, processors that live inside a
> stateless
> process group are scheduled *individually* instead of through their owning
> stateless
> group. A stateless group is a single scheduling unit
> (ExecutionEngine.STATELESS), so
> individual scheduling leaves the group in an inconsistent state: some member
> processors
> stopped, others running, while the stateless group node itself stays RUNNING.
> The group
> cannot then recover cleanly.
> * org.apache.nifi.controller.service.StandardControllerServiceProvider
> ** unscheduleReferencingComponents(...) stops each referenced processor
> directly via
> ProcessGroup.stopProcessor(node), regardless of stateless membership.
> ** scheduleReferencingComponents(...) starts each referenced processor via
> ComponentScheduler.startComponent(node). For a stateless member,
> DefaultComponentScheduler.startNow(...) skips the processor, so the start
> is a silent
> no-op and the group is never actually started as a unit.
> * Reached through PUT /controller-services/\{id}/references
> (state=RUNNING|STOPPED) ->
>
> StandardControllerServiceDAO.updateControllerServiceReferencingComponents(...).
> * verifyUpdateReferencingComponents(...) only checks the *service's own*
> process group,
> so a service defined at a STANDARD (root) scope does not block the request
> even when the
> referencing processors live inside a stateless child group.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
