[ 
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)

Reply via email to