You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by GitBox <gi...@apache.org> on 2021/03/29 20:56:55 UTC
[GitHub] [nifi] markap14 opened a new pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
markap14 opened a new pull request #4950:
URL: https://github.com/apache/nifi/pull/4950
…e to place downloaded files. Also fixed an issue that was encountered, when a Source Processor is scheduled for Primary Node Only but more than 1 task is set. In that case, even though only a single task will should be scheduled, an Exception was getting thrown because @OnScheduled methods of Processors were still called. To avoid this, moved the initialization of the dataflow outside of the creation of the dataflow so that initialization can be triggered only when appropriate.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
#### Description of PR
_Enables X functionality; fixes bug NIFI-YYYY._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with **NIFI-XXXX** where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [ ] Has your PR been rebased against the latest commit within the target branch (typically `main`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not `squash` or use `--force` when pushing to allow for clean monitoring of changes._
### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via `mvn -Pcontrib-check clean install` at the root `nifi` folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] Have you verified that the full build is successful on JDK 8?
- [ ] Have you verified that the full build is successful on JDK 11?
- [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main `LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main `NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to .name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] markap14 commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
markap14 commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r606238347
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/config/PropertiesFileEngineConfigurationParser.java
##########
@@ -78,6 +79,12 @@ public StatelessEngineConfiguration parseEngineConfiguration(final File properti
throw new StatelessConfigurationException("Working Directory " + workingDirectory.getAbsolutePath() + " specified in properties file does not exist and could not be created");
}
+ final String extensionsDirectoryFilename = properties.getProperty(EXTENSIONS_DIRECTORY);
+ final File extensionsDirectory = extensionsDirectoryFilename == null ? narDirectory : new File(extensionsDirectoryFilename);
+ if (!extensionsDirectory.exists() && !extensionsDirectory.mkdirs()) {
Review comment:
The validation does not fail if the directory doesn't exist - that validation was removed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] markap14 commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
markap14 commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r604086680
##########
File path: nifi-external/nifi-kafka-connect/nifi-kafka-connector/src/main/java/org/apache/nifi/kafka/connect/validators/ConnectDirectoryExistsValidator.java
##########
@@ -34,7 +34,7 @@ public void ensureValid(final String name, final Object value) {
}
final File file = new File((String) value);
- if (!file.exists()) {
+ if (!file.exists() && !file.mkdirs()) {
Review comment:
No, you're right, that shouldn't be there. I put it there as a bit of an experiment, and forgot to remove it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] urbandan commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
urbandan commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r605415342
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/config/PropertiesFileEngineConfigurationParser.java
##########
@@ -78,6 +79,12 @@ public StatelessEngineConfiguration parseEngineConfiguration(final File properti
throw new StatelessConfigurationException("Working Directory " + workingDirectory.getAbsolutePath() + " specified in properties file does not exist and could not be created");
}
+ final String extensionsDirectoryFilename = properties.getProperty(EXTENSIONS_DIRECTORY);
+ final File extensionsDirectory = extensionsDirectoryFilename == null ? narDirectory : new File(extensionsDirectoryFilename);
+ if (!extensionsDirectory.exists() && !extensionsDirectory.mkdirs()) {
Review comment:
I'm not sure if the mkdirs call is ok here: the validator will fail if the dir doesn't exist, but the actual connector/task init will pass if the dir can be created. Seems like the validator is stricter than it should be.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] pvillard31 commented on pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
pvillard31 commented on pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#issuecomment-814836289
Merged to main, thanks @markap14 @akatona84 @urbandan
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] asfgit closed pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
asfgit closed pull request #4950:
URL: https://github.com/apache/nifi/pull/4950
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] akatona84 commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
akatona84 commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r603839628
##########
File path: nifi-external/nifi-kafka-connect/nifi-kafka-connector/src/main/java/org/apache/nifi/kafka/connect/validators/ConnectDirectoryExistsValidator.java
##########
@@ -34,7 +34,7 @@ public void ensureValid(final String name, final Object value) {
}
final File file = new File((String) value);
- if (!file.exists()) {
+ if (!file.exists() && !file.mkdirs()) {
Review comment:
Is this necessary to create the dir in the validation phase?
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/flow/StatelessDataflow.java
##########
@@ -24,8 +24,33 @@
import java.util.Set;
public interface StatelessDataflow {
Review comment:
It is not part of this PR, but wouldn't make sense to make it extend AutoClosable? and having close() instead of shutdown(), etc.
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/flow/StatelessDataflow.java
##########
@@ -24,8 +24,33 @@
import java.util.Set;
public interface StatelessDataflow {
Review comment:
It is not part of this PR, but wouldn't make sense to make it extend AutoClosable? and having close() instead of shutdown(), etc.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] markap14 commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
markap14 commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r604089989
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/flow/StatelessDataflow.java
##########
@@ -24,8 +24,33 @@
import java.util.Set;
public interface StatelessDataflow {
Review comment:
I don't think we should extend `AutoCloseable` in this case. The StatelessDataflow is not really a "resource" and is generally not used in a such a way that you'd want to use a try-with-resources to create it for a short period of time and then cleanup. Rather, `shutdown()` is generally used when the application is shutdown. This involves terminating thread pools, cleaning up potentially many resources, etc., etc.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] markap14 commented on pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
markap14 commented on pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#issuecomment-814871049
Awesome! Thanks @akatona84 and @urbandan for such thorough testing & review! And thanks @pvillard31 for reviewing & merging!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] urbandan commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
urbandan commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r607548833
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/config/PropertiesFileEngineConfigurationParser.java
##########
@@ -78,6 +79,12 @@ public StatelessEngineConfiguration parseEngineConfiguration(final File properti
throw new StatelessConfigurationException("Working Directory " + workingDirectory.getAbsolutePath() + " specified in properties file does not exist and could not be created");
}
+ final String extensionsDirectoryFilename = properties.getProperty(EXTENSIONS_DIRECTORY);
+ final File extensionsDirectory = extensionsDirectoryFilename == null ? narDirectory : new File(extensionsDirectoryFilename);
+ if (!extensionsDirectory.exists() && !extensionsDirectory.mkdirs()) {
Review comment:
Got it, thanks
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-bootstrap/src/main/java/org/apache/nifi/stateless/bootstrap/StatelessBootstrap.java
##########
@@ -98,7 +99,12 @@ public static StatelessBootstrap bootstrap(final StatelessEngineConfiguration en
// Unpack NARs
final long unpackStart = System.currentTimeMillis();
final Predicate<BundleCoordinate> narFilter = coordinate -> true;
- NarUnpacker.unpackNars(systemBundle, frameworkWorkingDir, extensionsWorkingDir, null, narDirectories, false, false, false, narFilter);
+ NarUnpackLock.lock();
Review comment:
Is this lock also protecting the part when the nars are getting downloaded? Can it cause issues if the download is not protected by it?
With this solution, do we avoid downloading the nars multiple times? (i.e. if one task is blocked on getting the lock, will it realize that the sibling task already downloaded and unpacked the necessary nars?)
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/engine/NarUnpackLock.java
##########
@@ -0,0 +1,58 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.nifi.stateless.engine;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;
+
+/**
+ * If multiple Stateless dataflows are loaded concurrently within the same JVM, we need to ensure that the dataflows
+ * do not stomp on one another when unpacking NAR's. To do that, we need a mechanism by which a single lock can be shared
+ * across multiple classes, as the Extension Repository as well as the bootstrap logic may attempt to unpack NARs.
+ * Because these classes exist across multiple modules, and because statically defined locks at that level may not be enough
+ * (due to multiple classloders being used for the 'stateless nar'), we define a singleton Lock within the nifi-stateless-api module.
+ * This lock should always be obtained before attempting to unpack nars.
+ */
+public class NarUnpackLock {
Review comment:
As an improvement, this could be providing locks on a per-directory basis - so if we have multiple NiFi Connectors with separate nar directories, they can progress without blocking each other.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] markap14 commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
markap14 commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r608121946
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-bootstrap/src/main/java/org/apache/nifi/stateless/bootstrap/StatelessBootstrap.java
##########
@@ -98,7 +99,12 @@ public static StatelessBootstrap bootstrap(final StatelessEngineConfiguration en
// Unpack NARs
final long unpackStart = System.currentTimeMillis();
final Predicate<BundleCoordinate> narFilter = coordinate -> true;
- NarUnpacker.unpackNars(systemBundle, frameworkWorkingDir, extensionsWorkingDir, null, narDirectories, false, false, false, narFilter);
+ NarUnpackLock.lock();
Review comment:
No, each process that needs the nar will download it for itself. They download using a temporary filename. Only one task will manage to rename its download to the 'final' name. Others will delete their temporary files. It's not efficient, but it was a simple/straight-forward solution that can be improved upon later.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] markap14 commented on a change in pull request #4950: NIFI-8380: Allow for an extensions.directory property to specify wher…
Posted by GitBox <gi...@apache.org>.
markap14 commented on a change in pull request #4950:
URL: https://github.com/apache/nifi/pull/4950#discussion_r608123474
##########
File path: nifi-nar-bundles/nifi-framework-bundle/nifi-stateless-bundle/nifi-stateless-api/src/main/java/org/apache/nifi/stateless/engine/NarUnpackLock.java
##########
@@ -0,0 +1,58 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.nifi.stateless.engine;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;
+
+/**
+ * If multiple Stateless dataflows are loaded concurrently within the same JVM, we need to ensure that the dataflows
+ * do not stomp on one another when unpacking NAR's. To do that, we need a mechanism by which a single lock can be shared
+ * across multiple classes, as the Extension Repository as well as the bootstrap logic may attempt to unpack NARs.
+ * Because these classes exist across multiple modules, and because statically defined locks at that level may not be enough
+ * (due to multiple classloders being used for the 'stateless nar'), we define a singleton Lock within the nifi-stateless-api module.
+ * This lock should always be obtained before attempting to unpack nars.
+ */
+public class NarUnpackLock {
Review comment:
Yes, we can certainly improve this in the future. Given that this happens only at startup and likely will only take hundreds of milliseconds, I'm not particularly worried about the performance impact initially. But we can certainly improve this process if we need to, going forward.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org