[ 
https://issues.apache.org/jira/browse/NIFI-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nandor Soma Abonyi updated NIFI-10035:
--------------------------------------
    Description: 
NiFi should fail at startup when it is unable to load nars.
 - We can end up in a situation where nars were deployed but weren’t loaded and 
users probably won't notice any warning unless they are looking for it.
 - In a clustered environment if only some of the nodes didn’t load the nar, 
then not all nodes will connect to the cluster (must have the same nars to 
connect), etc.

Practically this can be achieved by removing the catch block for `IOException` 
in `NarUnpacker:unpackNars()`. Though after a brief analysis there are some 
methods that throwing `IOException` and probably NiFi can recover because they 
are not related to core function.

Result of that analysis:

*Should prevent startup: (could lead to inconsistency in a cluster)*
 * NarUnpacker:98 - frameworkWorkingDir is not readable or does not exist
NarUnpacker:101 - extensionsWorkingDir is not readable or does not exist
 * NarUnpacker:112 - narDir is not readable or does not exist
 * NarUnpacker:133/134- manifest is not obtainable from a nar
 * NarUnpacker:148 - unable to unpack the framework nar
 * NarUnpacker:154 - unable to unpack Jetty nar
 * NarUnpacker:159 - unable to unpack extension nar

*Should not prevent startup: (reasons are different for each case)*
 * NarUnpacker:104 - docsWorkingDir is not readable or does not exist -> nifi 
could recover because in some scenarios docs are not needed at all. (minifi? 
This statement needs validation!)
 * NarUnpacker:190 - unable to delete working dir of nars which no longer exist 
-> nifi could recover because working dir of non existent nars’ doesn’t affect 
current flow
 * NarUnpacker:201 - unable to delete working dir of extension nars which no 
longer exist -> nifi could recover because working dir of non existent nars’ 
doesn’t affect current flow
 * NarUnpacker:213 - unable to map extensions -> internally it just unpack docs 
-> nifi could recover because in some scenarios docs are not needed at all. 
(minifi? This statement needs validation!)
 * NarUnpacker:216 - unable to unpack bundle docs -> nifi could recover because 
in some scenarios docs are not needed at all. (minifi? This statement needs 
validation!)

  was:
NiFi should fail at startup when it is unable to load nars.
 - We can end up in a situation where nars were deployed but weren’t loaded and 
users probably won't notice any warning unless they are looking for it.
 - In a clustered environment if only some of the nodes didn’t load the nar, 
then not all nodes will connect to the cluster (must have the same nars to 
connect), etc.

Practically this can be achieved by removing the catch block for `IOException` 
in `NarUnpacker:unpackNars()`. Though after a brief analysis there are some 
methods that throwing `IOException` and probably NiFi can recover because they 
are not related to core function.

Result of that analysis:

*Should prevent startup: (could lead to inconsistency in a cluster)*
 * NarUnpacker:98 - frameworkWorkingDir is not readable or does not exist
NarUnpacker:101 - extensionsWorkingDir is not readable or does not exist
 * NarUnpacker:112 - narDir is not readable or does not exist
 * NarUnpacker:133/134- manifest is not obtainable from a nar
 * NarUnpacker:148 - unable to unpack the framework nar
 * NarUnpacker:154 - unable to unpack Jetty nar
 * NarUnpacker:159 - unable to unpack extension nar

 

*Should not prevent startup: (reasons are different for each case)*
 * NarUnpacker:104 - docsWorkingDir is not readable or does not exist -> nifi 
could recover because in some scenarios docs are not needed at all. (minifi? 
This statement needs validation!)
 * NarUnpacker:190 - unable to delete working dir of nars which no longer exist 
-> nifi could recover because working dir of non existent nars’ doesn’t affect 
current flow
 * NarUnpacker:201 - unable to delete working dir of extension nars which no 
longer exist -> nifi could recover because working dir of non existent nars’ 
doesn’t affect current flow
 * NarUnpacker:213 - unable to map extensions -> internally it just unpack docs 
-> nifi could recover because in some scenarios docs are not needed at all. 
(minifi? This statement needs validation!)
 * NarUnpacker:216 - unable to unpack bundle docs -> nifi could recover because 
in some scenarios docs are not needed at all. (minifi? This statement needs 
validation!)


> NiFi should fail at startup when it is unable to load nars to any reason
> ------------------------------------------------------------------------
>
>                 Key: NIFI-10035
>                 URL: https://issues.apache.org/jira/browse/NIFI-10035
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>    Affects Versions: 1.16.1
>            Reporter: Nandor Soma Abonyi
>            Assignee: Nandor Soma Abonyi
>            Priority: Major
>
> NiFi should fail at startup when it is unable to load nars.
>  - We can end up in a situation where nars were deployed but weren’t loaded 
> and users probably won't notice any warning unless they are looking for it.
>  - In a clustered environment if only some of the nodes didn’t load the nar, 
> then not all nodes will connect to the cluster (must have the same nars to 
> connect), etc.
> Practically this can be achieved by removing the catch block for 
> `IOException` in `NarUnpacker:unpackNars()`. Though after a brief analysis 
> there are some methods that throwing `IOException` and probably NiFi can 
> recover because they are not related to core function.
> Result of that analysis:
> *Should prevent startup: (could lead to inconsistency in a cluster)*
>  * NarUnpacker:98 - frameworkWorkingDir is not readable or does not exist
> NarUnpacker:101 - extensionsWorkingDir is not readable or does not exist
>  * NarUnpacker:112 - narDir is not readable or does not exist
>  * NarUnpacker:133/134- manifest is not obtainable from a nar
>  * NarUnpacker:148 - unable to unpack the framework nar
>  * NarUnpacker:154 - unable to unpack Jetty nar
>  * NarUnpacker:159 - unable to unpack extension nar
> *Should not prevent startup: (reasons are different for each case)*
>  * NarUnpacker:104 - docsWorkingDir is not readable or does not exist -> nifi 
> could recover because in some scenarios docs are not needed at all. (minifi? 
> This statement needs validation!)
>  * NarUnpacker:190 - unable to delete working dir of nars which no longer 
> exist -> nifi could recover because working dir of non existent nars’ doesn’t 
> affect current flow
>  * NarUnpacker:201 - unable to delete working dir of extension nars which no 
> longer exist -> nifi could recover because working dir of non existent nars’ 
> doesn’t affect current flow
>  * NarUnpacker:213 - unable to map extensions -> internally it just unpack 
> docs -> nifi could recover because in some scenarios docs are not needed at 
> all. (minifi? This statement needs validation!)
>  * NarUnpacker:216 - unable to unpack bundle docs -> nifi could recover 
> because in some scenarios docs are not needed at all. (minifi? This statement 
> needs validation!)



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Reply via email to