[
https://issues.apache.org/jira/browse/NIFI-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648718#comment-17648718
]
ASF subversion and git services commented on NIFI-10981:
--------------------------------------------------------
Commit 5c3ca9d5374716ab1758ada6f0d36c8a4f5e2ed7 in nifi's branch
refs/heads/main from Bryan Bende
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5c3ca9d537 ]
NIFI-10981 Ensure NarAutoLoader starts after provider retrieves NARs,… (#6785)
- NIFI-10981 Ensure NarAutoLoader starts after provider retrieves NARs, and
ensure the auto-loader attempts to process any NARs available before starting
to watch for new files
- Add system test with NAR Provider that copies NARs from a local directory and
verifies the NARs were loaded and linked correctly
- Exclude new assembly from CI test-compile
> 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.17.0, 1.18.0, 1.19.0, 1.19.1
> Reporter: Bryan Bende
> Assignee: Bryan Bende
> Priority: Major
> Fix For: 1.20.0
>
> Time Spent: 40m
> 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)
