You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Bryan Bende (Jira)" <ji...@apache.org> on 2022/12/14 17:55:00 UTC
[jira] [Created] (NIFI-10981) Ensure NAR Auto Loader is started after provider and handles existing NARs
Bryan Bende created NIFI-10981:
----------------------------------
Summary: 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
Fix For: 1.20.0
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)