You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2022/12/16 16:31:00 UTC

[jira] [Commented] (NIFI-10981) Ensure NAR Auto Loader is started after provider and handles existing NARs

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