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)