[
https://issues.apache.org/jira/browse/NIFI-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112418#comment-18112418
]
ASF subversion and git services commented on NIFI-16308:
--------------------------------------------------------
Commit 73eb46b01a853cd9b8c7795f0c3370c798b422be in nifi's branch
refs/heads/main from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=73eb46b01a8 ]
NIFI-16308 Prevent concurrent Connector starts (#11638)
> StandardConnectorNode can schedule duplicate concurrent starts
> --------------------------------------------------------------
>
> Key: NIFI-16308
> URL: https://issues.apache.org/jira/browse/NIFI-16308
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Mark Payne
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> StandardConnectorNode.start() reads the current Connector state and then
> unconditionally sets it to STARTING. When two callers start the same
> Connector concurrently, both can observe STOPPED and both can schedule
> startComponent(). The second state update is logged as STARTING -> STARTING.
> This was observed while validating the Connector mock framework against the
> Kafka-to-S3 Connector. ConnectorTestRunner.applyUpdate() initiated an
> asynchronous stop and returned. An immediate explicit start set the desired
> state to RUNNING. When the stop completed, StandardConnectorNode also
> initiated its automatic restart, allowing both start calls to proceed
> concurrently.
> h2. Reproduction
> # Begin an asynchronous Connector stop.
> # Request start while the current state is STOPPING, setting the desired
> state to RUNNING.
> # Allow stopComponent() to reach STOPPED and invoke its automatic restart.
> # Arrange for the explicit start and automatic restart to complete validation
> together.
> # Observe both callers read STOPPED, followed by STOPPED -> STARTING and
> STARTING -> STARTING transitions.
> h2. Impact
> Both calls invoke Connector.start() and attempt to start the same managed
> processors and controller services. The first path can reach RUNNING while
> the duplicate path is refused because components are already STARTING.
> Completion futures created for the duplicate processor starts may never
> complete, which can strand the associated Connector start Future even though
> the Connector is running. Callers that wait on that Future can hang or time
> out, and Connector lifecycle callbacks can execute concurrently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
