[jira] [Updated] (NIFI-10981) Ensure NAR Auto Loader is started after provider and handles existing NARs

["Bryan Bende (Jira)" <ji...@apache.org>]

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

Bryan Bende updated NIFI-10981:
-------------------------------
    Status: Patch Available  (was: Open)

> Ensure NAR Auto Loader is started after provider and handles existing NARs
> --------------------------------------------------------------------------
>
>                 Key: NIFI-10981
>                 URL: https://issues.apache.org/jira/browse/NIFI-10981
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.19.1, 1.19.0, 1.18.0, 1.17.0
>            Reporter: Bryan Bende
>            Assignee: Bryan Bende
>            Priority: Major
>             Fix For: 1.20.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the order during start up is the following...
>  * narLoader.start()
>  * narProvider.start()
>  * jettyServer.start()
> The provider has a blocking mechanism to ensure that all NARs are downloaded before we proceed with starting the server and loading the flow, but there are two problems...
> First, since the loader is started before the provider, the loader may load NARs individually as the provider is downloading them. In a case where the provider is going to download a service API NAR and service impl NAR, it may first download the impl NAR, and if the loader tries to load it before the API NAR was downloaded, the loader may determine there is another available API NAR that can be used and bind to that instead.
> Second, since the loader is running asynchronously, there is a potential race condition where NARs are being loaded at the same time we are proceeding with starting the server, and could reach the point of loading the cluster's flow before all NARs are actually loaded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)