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