You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Nandor Soma Abonyi (Jira)" <ji...@apache.org> on 2022/05/18 20:14:00 UTC
[jira] [Updated] (NIFI-10035) NiFi should fail at startup when it is unable to load nars to any reason
[ 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)*
* 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)