[
https://issues.apache.org/jira/browse/NIFI-16174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noah Cover updated NIFI-16174:
------------------------------
Description:
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.
was:
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.
Real connectors hit this during break-glass / troubleshooting operations.
Example: the
Snowflake CDC connectors define a Snowflake connection-pool controller service
at the
connector root that is referenced by processors inside a stateless subgroup
(e.g. the
"Create Journal Table" group). Stopping the service's referencing components
leaves that
stateless group with a mixed processor state and a stuck group node, and the
connector
does not return to a clean RUNNING state without a full stop/restart.
> 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: 10m
> 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)
