[jira] [Resolved] (NIFI-16308) StandardConnectorNode can schedule duplicate concurrent starts

["Pierre Villard (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIFI-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre Villard resolved NIFI-16308.
-----------------------------------
    Fix Version/s: 2.12.0
         Assignee: Mark Payne
       Resolution: Fixed

> 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
>            Assignee: Mark Payne
>            Priority: Major
>             Fix For: 2.12.0
>
>          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)