[GitHub] nifi issue #2022: NIFI-4200 - Initial commit for a ControlNiFi processor
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/2022 @pvillard31 I was reviewing this today, but wanted to make sure you still wanted to move forward. No reason not to that I can see, it's just been dormant a long time. ---
[jira] [Commented] (NIFI-4200) Consider a ControlNiFi processor
[ https://issues.apache.org/jira/browse/NIFI-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648736#comment-16648736 ] ASF GitHub Bot commented on NIFI-4200: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/2022 @pvillard31 I was reviewing this today, but wanted to make sure you still wanted to move forward. No reason not to that I can see, it's just been dormant a long time. > Consider a ControlNiFi processor > > > Key: NIFI-4200 > URL: https://issues.apache.org/jira/browse/NIFI-4200 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > We frequently see on the mailing list the need to start/stop a processor > based on incoming flow files. At the moment, that's something that can be > scripted or that can be done using multiple InvokeHttp processors but it > requires a bit of work. > Even though it is not really in the "NiFi way of thinking", it would be > interesting to have a processor with the following parameters: > - NiFi REST API URL > - Username > - Password > - Processor UUID (with expression language) > - Action to perform (START, STOP, START/STOP, STOP/START) > - Sleep duration (between the START and STOP calls when action is START/STOP, > or STOP/START) > That would be helpful in use cases like: > - start a workflow based on another workflow > - start a processor not accepting incoming relationship based on a flow file > - restart a processor to "refresh" its configuration when the processor > relies on configuration files that could be changed > - have a "start once" behavior -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5629) GetFile becomes slow listing vast directories
[
https://issues.apache.org/jira/browse/NIFI-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648726#comment-16648726
]
ASF GitHub Bot commented on NIFI-5629:
--
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224948420
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestGetFile.java
---
@@ -151,6 +151,90 @@ public void testFilePickedUp() throws IOException {
assertEquals(absTargetPathStr, absolutePath);
}
+@Test
+public void testFilePickedUpArrivalSinceListing() throws IOException {
+final File directory = new File("target/test/data/in");
+deleteDirectory(directory);
+assertTrue("Unable to create test data directory " +
directory.getAbsolutePath(), directory.exists() || directory.mkdirs());
+
+final TestRunner runner = TestRunners.newTestRunner(new GetFile());
+runner.setProperty(GetFile.DIRECTORY, directory.getAbsolutePath());
+runner.setProperty(GetFile.KEEP_SOURCE_FILE, "false");
+
+final File inFile = new File("src/test/resources/hello.txt");
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName());
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+}
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName() +
"1");
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+
+ runner.run(1);
+}
+final Path inPath = inFile.toPath();
+final File destFile = new File(directory, inFile.getName() + "2");
+final Path targetPath = destFile.toPath();
+final Path absTargetPath = targetPath.toAbsolutePath();
+final String absTargetPathStr = absTargetPath.getParent() + "/";
+Files.copy(inPath, targetPath);
+
+runner.run(1);
+runner.run(1);
+
+runner.assertAllFlowFilesTransferred(GetFile.REL_SUCCESS, 3);
+final List successFiles =
runner.getFlowFilesForRelationship(GetFile.REL_SUCCESS);
+successFiles.get(0).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(1).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(2).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+
+final String path = successFiles.get(2).getAttribute("path");
+assertEquals("/", path);
+final String absolutePath =
successFiles.get(2).getAttribute(CoreAttributes.ABSOLUTE_PATH.key());
+assertEquals(absTargetPathStr, absolutePath);
+}
+
+@Test
--- End diff --
On further testing of this test case, weird results. Does this test work
for you? I get a mix of Actual counts. I ran this test on the full code and get
Actual 9996. I took out the limit, and got an actual of . Not really sure
what's going on.
> GetFile becomes slow listing vast directories
> -
>
> Key: NIFI-5629
> URL: https://issues.apache.org/jira/browse/NIFI-5629
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.6.0
>Reporter: Adam
>Priority: Minor
>
> GetFile repeatedly lists entire directories before applying batching, meaning
> for vast directories it spends a long time listing directories.
>
> Pull request to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #3033: NIFI-5629 GetFile vast listing performance
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224948420
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestGetFile.java
---
@@ -151,6 +151,90 @@ public void testFilePickedUp() throws IOException {
assertEquals(absTargetPathStr, absolutePath);
}
+@Test
+public void testFilePickedUpArrivalSinceListing() throws IOException {
+final File directory = new File("target/test/data/in");
+deleteDirectory(directory);
+assertTrue("Unable to create test data directory " +
directory.getAbsolutePath(), directory.exists() || directory.mkdirs());
+
+final TestRunner runner = TestRunners.newTestRunner(new GetFile());
+runner.setProperty(GetFile.DIRECTORY, directory.getAbsolutePath());
+runner.setProperty(GetFile.KEEP_SOURCE_FILE, "false");
+
+final File inFile = new File("src/test/resources/hello.txt");
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName());
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+}
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName() +
"1");
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+
+ runner.run(1);
+}
+final Path inPath = inFile.toPath();
+final File destFile = new File(directory, inFile.getName() + "2");
+final Path targetPath = destFile.toPath();
+final Path absTargetPath = targetPath.toAbsolutePath();
+final String absTargetPathStr = absTargetPath.getParent() + "/";
+Files.copy(inPath, targetPath);
+
+runner.run(1);
+runner.run(1);
+
+runner.assertAllFlowFilesTransferred(GetFile.REL_SUCCESS, 3);
+final List successFiles =
runner.getFlowFilesForRelationship(GetFile.REL_SUCCESS);
+successFiles.get(0).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(1).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(2).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+
+final String path = successFiles.get(2).getAttribute("path");
+assertEquals("/", path);
+final String absolutePath =
successFiles.get(2).getAttribute(CoreAttributes.ABSOLUTE_PATH.key());
+assertEquals(absTargetPathStr, absolutePath);
+}
+
+@Test
--- End diff --
On further testing of this test case, weird results. Does this test work
for you? I get a mix of Actual counts. I ran this test on the full code and get
Actual 9996. I took out the limit, and got an actual of . Not really sure
what's going on.
---
[jira] [Commented] (NIFI-5629) GetFile becomes slow listing vast directories
[ https://issues.apache.org/jira/browse/NIFI-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648710#comment-16648710 ] ASF GitHub Bot commented on NIFI-5629: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/3033 @adyoun2 Also, to retrigger the build, I found online that you can close and re-open your PR (no need for a new PR, just re-open). That _should_ re-trigger the checks. > GetFile becomes slow listing vast directories > - > > Key: NIFI-5629 > URL: https://issues.apache.org/jira/browse/NIFI-5629 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Adam >Priority: Minor > > GetFile repeatedly lists entire directories before applying batching, meaning > for vast directories it spends a long time listing directories. > > Pull request to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3033: NIFI-5629 GetFile vast listing performance
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/3033 @adyoun2 Also, to retrigger the build, I found online that you can close and re-open your PR (no need for a new PR, just re-open). That _should_ re-trigger the checks. ---
[jira] [Commented] (NIFI-5629) GetFile becomes slow listing vast directories
[
https://issues.apache.org/jira/browse/NIFI-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648696#comment-16648696
]
ASF GitHub Bot commented on NIFI-5629:
--
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224947166
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestGetFile.java
---
@@ -151,6 +151,90 @@ public void testFilePickedUp() throws IOException {
assertEquals(absTargetPathStr, absolutePath);
}
+@Test
+public void testFilePickedUpArrivalSinceListing() throws IOException {
+final File directory = new File("target/test/data/in");
+deleteDirectory(directory);
+assertTrue("Unable to create test data directory " +
directory.getAbsolutePath(), directory.exists() || directory.mkdirs());
+
+final TestRunner runner = TestRunners.newTestRunner(new GetFile());
+runner.setProperty(GetFile.DIRECTORY, directory.getAbsolutePath());
+runner.setProperty(GetFile.KEEP_SOURCE_FILE, "false");
+
+final File inFile = new File("src/test/resources/hello.txt");
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName());
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+}
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName() +
"1");
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+
+ runner.run(1);
+}
+final Path inPath = inFile.toPath();
+final File destFile = new File(directory, inFile.getName() + "2");
+final Path targetPath = destFile.toPath();
+final Path absTargetPath = targetPath.toAbsolutePath();
+final String absTargetPathStr = absTargetPath.getParent() + "/";
+Files.copy(inPath, targetPath);
+
+runner.run(1);
+runner.run(1);
+
+runner.assertAllFlowFilesTransferred(GetFile.REL_SUCCESS, 3);
+final List successFiles =
runner.getFlowFilesForRelationship(GetFile.REL_SUCCESS);
+successFiles.get(0).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(1).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(2).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+
+final String path = successFiles.get(2).getAttribute("path");
+assertEquals("/", path);
+final String absolutePath =
successFiles.get(2).getAttribute(CoreAttributes.ABSOLUTE_PATH.key());
+assertEquals(absTargetPathStr, absolutePath);
+}
+
+@Test
--- End diff --
I still have more testing to do, but so far this test looks good at
demonstrating the issue. When i run this with the unmodified GetFile it runs
out steam around 9993 files.
> GetFile becomes slow listing vast directories
> -
>
> Key: NIFI-5629
> URL: https://issues.apache.org/jira/browse/NIFI-5629
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.6.0
>Reporter: Adam
>Priority: Minor
>
> GetFile repeatedly lists entire directories before applying batching, meaning
> for vast directories it spends a long time listing directories.
>
> Pull request to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NIFI-5629) GetFile becomes slow listing vast directories
[
https://issues.apache.org/jira/browse/NIFI-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648697#comment-16648697
]
ASF GitHub Bot commented on NIFI-5629:
--
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224946482
--- Diff:
nifi-mock/src/main/java/org/apache/nifi/util/MockProcessSession.java ---
@@ -458,6 +458,9 @@ public MockFlowFile importFrom(final Path path, final
boolean keepSourceFile, Fl
newFlowFile.setData(baos.toByteArray());
newFlowFile = putAttribute(newFlowFile,
CoreAttributes.FILENAME.key(), path.getFileName().toString());
+if (!keepSourceFile) {
--- End diff --
Was this included on accident? Does not seem relevant to your ticket.
> GetFile becomes slow listing vast directories
> -
>
> Key: NIFI-5629
> URL: https://issues.apache.org/jira/browse/NIFI-5629
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.6.0
>Reporter: Adam
>Priority: Minor
>
> GetFile repeatedly lists entire directories before applying batching, meaning
> for vast directories it spends a long time listing directories.
>
> Pull request to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #3033: NIFI-5629 GetFile vast listing performance
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224946482
--- Diff:
nifi-mock/src/main/java/org/apache/nifi/util/MockProcessSession.java ---
@@ -458,6 +458,9 @@ public MockFlowFile importFrom(final Path path, final
boolean keepSourceFile, Fl
newFlowFile.setData(baos.toByteArray());
newFlowFile = putAttribute(newFlowFile,
CoreAttributes.FILENAME.key(), path.getFileName().toString());
+if (!keepSourceFile) {
--- End diff --
Was this included on accident? Does not seem relevant to your ticket.
---
[jira] [Commented] (NIFI-5629) GetFile becomes slow listing vast directories
[
https://issues.apache.org/jira/browse/NIFI-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648699#comment-16648699
]
ASF GitHub Bot commented on NIFI-5629:
--
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224946495
--- Diff:
nifi-commons/nifi-properties/src/main/java/org/apache/nifi/util/NiFiProperties.java
---
@@ -1422,10 +1424,15 @@ public String
getDefaultBackPressureDataSizeThreshold() {
public static NiFiProperties createBasicNiFiProperties(final String
propertiesFilePath, final Map additionalProperties) {
final Map addProps = (additionalProperties ==
null) ? Collections.EMPTY_MAP : additionalProperties;
final Properties properties = new Properties();
-final String nfPropertiesFilePath = (propertiesFilePath == null)
+String nfPropertiesFilePath = (propertiesFilePath == null)
? System.getProperty(NiFiProperties.PROPERTIES_FILE_PATH)
: propertiesFilePath;
if (nfPropertiesFilePath != null) {
+try {
--- End diff --
Was this included on accident? Does not seem relevant to your ticket.
> GetFile becomes slow listing vast directories
> -
>
> Key: NIFI-5629
> URL: https://issues.apache.org/jira/browse/NIFI-5629
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.6.0
>Reporter: Adam
>Priority: Minor
>
> GetFile repeatedly lists entire directories before applying batching, meaning
> for vast directories it spends a long time listing directories.
>
> Pull request to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NIFI-5629) GetFile becomes slow listing vast directories
[
https://issues.apache.org/jira/browse/NIFI-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648698#comment-16648698
]
ASF GitHub Bot commented on NIFI-5629:
--
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224946474
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-documentation/src/test/java/org/apache/nifi/documentation/DocGeneratorTest.java
---
@@ -72,7 +74,12 @@ public void testProcessorLoadsNarResources() throws
IOException, ClassNotFoundEx
}
private NiFiProperties loadSpecifiedProperties(final String
propertiesFile, final String key, final String value) {
-String file =
DocGeneratorTest.class.getResource(propertiesFile).getFile();
+String file = propertiesFile;
--- End diff --
Was this included on accident? Does not seem relevant to your ticket.
> GetFile becomes slow listing vast directories
> -
>
> Key: NIFI-5629
> URL: https://issues.apache.org/jira/browse/NIFI-5629
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.6.0
>Reporter: Adam
>Priority: Minor
>
> GetFile repeatedly lists entire directories before applying batching, meaning
> for vast directories it spends a long time listing directories.
>
> Pull request to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #3033: NIFI-5629 GetFile vast listing performance
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224946495
--- Diff:
nifi-commons/nifi-properties/src/main/java/org/apache/nifi/util/NiFiProperties.java
---
@@ -1422,10 +1424,15 @@ public String
getDefaultBackPressureDataSizeThreshold() {
public static NiFiProperties createBasicNiFiProperties(final String
propertiesFilePath, final Map additionalProperties) {
final Map addProps = (additionalProperties ==
null) ? Collections.EMPTY_MAP : additionalProperties;
final Properties properties = new Properties();
-final String nfPropertiesFilePath = (propertiesFilePath == null)
+String nfPropertiesFilePath = (propertiesFilePath == null)
? System.getProperty(NiFiProperties.PROPERTIES_FILE_PATH)
: propertiesFilePath;
if (nfPropertiesFilePath != null) {
+try {
--- End diff --
Was this included on accident? Does not seem relevant to your ticket.
---
[GitHub] nifi pull request #3033: NIFI-5629 GetFile vast listing performance
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224946474
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-documentation/src/test/java/org/apache/nifi/documentation/DocGeneratorTest.java
---
@@ -72,7 +74,12 @@ public void testProcessorLoadsNarResources() throws
IOException, ClassNotFoundEx
}
private NiFiProperties loadSpecifiedProperties(final String
propertiesFile, final String key, final String value) {
-String file =
DocGeneratorTest.class.getResource(propertiesFile).getFile();
+String file = propertiesFile;
--- End diff --
Was this included on accident? Does not seem relevant to your ticket.
---
[GitHub] nifi pull request #3033: NIFI-5629 GetFile vast listing performance
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3033#discussion_r224947166
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestGetFile.java
---
@@ -151,6 +151,90 @@ public void testFilePickedUp() throws IOException {
assertEquals(absTargetPathStr, absolutePath);
}
+@Test
+public void testFilePickedUpArrivalSinceListing() throws IOException {
+final File directory = new File("target/test/data/in");
+deleteDirectory(directory);
+assertTrue("Unable to create test data directory " +
directory.getAbsolutePath(), directory.exists() || directory.mkdirs());
+
+final TestRunner runner = TestRunners.newTestRunner(new GetFile());
+runner.setProperty(GetFile.DIRECTORY, directory.getAbsolutePath());
+runner.setProperty(GetFile.KEEP_SOURCE_FILE, "false");
+
+final File inFile = new File("src/test/resources/hello.txt");
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName());
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+}
+{
+ final Path inPath = inFile.toPath();
+ final File destFile = new File(directory, inFile.getName() +
"1");
+ final Path targetPath = destFile.toPath();
+ Files.copy(inPath, targetPath);
+
+ runner.run(1);
+}
+final Path inPath = inFile.toPath();
+final File destFile = new File(directory, inFile.getName() + "2");
+final Path targetPath = destFile.toPath();
+final Path absTargetPath = targetPath.toAbsolutePath();
+final String absTargetPathStr = absTargetPath.getParent() + "/";
+Files.copy(inPath, targetPath);
+
+runner.run(1);
+runner.run(1);
+
+runner.assertAllFlowFilesTransferred(GetFile.REL_SUCCESS, 3);
+final List successFiles =
runner.getFlowFilesForRelationship(GetFile.REL_SUCCESS);
+successFiles.get(0).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(1).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+successFiles.get(2).assertContentEquals("Hello,
World!".getBytes("UTF-8"));
+
+final String path = successFiles.get(2).getAttribute("path");
+assertEquals("/", path);
+final String absolutePath =
successFiles.get(2).getAttribute(CoreAttributes.ABSOLUTE_PATH.key());
+assertEquals(absTargetPathStr, absolutePath);
+}
+
+@Test
--- End diff --
I still have more testing to do, but so far this test looks good at
demonstrating the issue. When i run this with the unmodified GetFile it runs
out steam around 9993 files.
---
[jira] [Commented] (NIFI-5669) Color on current thread count
[ https://issues.apache.org/jira/browse/NIFI-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648685#comment-16648685 ] Peter Wicks commented on NIFI-5669: --- [~pvillard] How do you see this working on clusters? In our cluster each server has ~140 threads assigned. Cumulative is thus around 540 (4 nodes). In a cluster, the color will be for the total of all threads approaching the maximum? What if a single node is maxed out on threads but the other nodes are low? > Color on current thread count > - > > Key: NIFI-5669 > URL: https://issues.apache.org/jira/browse/NIFI-5669 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Priority: Minor > > It'd be very useful to change the color (or have another kind of visual > indicator) of the current threads count in the upper menu bar when the number > is reaching the maximum number of available threads defined by the thread > pool size. > Note - It could a bit tricky with the two thread pools (timer driven / event > driven) but that would be a very useful indicator as this is, quite often, > something users do not know about. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5684) Add a Warning / Indicator in the UI if a property value begins or ends with white space
[ https://issues.apache.org/jira/browse/NIFI-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648682#comment-16648682 ] Peter Wicks commented on NIFI-5684: --- I had this one bite me a while back, had a whitespace in front of my username on a database connection. [~ottobackwards], I think it would still be easy to miss a space with the brackets, if you were not looking for it. > Add a Warning / Indicator in the UI if a property value begins or ends with > white space > --- > > Key: NIFI-5684 > URL: https://issues.apache.org/jira/browse/NIFI-5684 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Mark Payne >Priority: Major > > It is not uncommon to see a user enter a property value into the UI where the > property value begins or ends with whitespace (both trailing spaces and > trailing newlines are fairly common to see), especially when they copy & > paste the value in. NiFi does not trim whitespace because there are also very > valid use cases for having the white space there (for example, if the > property value is used as a prefix for some string, or as a delimiter). > However, when this happens, users often end up with errors that say something > like "User my-user-name does not exist" because the property value is set to > "my-user-name" and the error message leads the user astray, leading to > a lot of confusion. > Therefore, I propose adding an indicator to the UI, so that when a user > configures a property value that begins with or ends with white space, the UI > warns to this fact so that the user is able to detect and fix this easily, > avoiding the confusion described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5693) PutEmail should support multiple attachments
[ https://issues.apache.org/jira/browse/NIFI-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648680#comment-16648680 ] ASF GitHub Bot commented on NIFI-5693: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/3068 I like your #2 approach, as shown in this PR. I haven't tested it yet, but can you provide a better description on the property? Right now there is no way for a user to know that TAR is the expected merge format (instead of, for example, the NiFi FlowFile packing format) > PutEmail should support multiple attachments > > > Key: NIFI-5693 > URL: https://issues.apache.org/jira/browse/NIFI-5693 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.7.1 >Reporter: David Savage >Priority: Minor > > *As a* NiFi User > *I want* to create multi part emails with many attachments > *So that* I can interface NiFi flows with legacy email systems > For this use case I reviewed this comment here [1] unfortunately the legacy > system requires individual attachments and is out of my control to upgrade so > the simple MergeFile based approach will not work. > I can see three potential solutions to this: > # Update PutEmail to extend BinFiles and use a similar mechanism to > MergeFiles to collect many files from the flow. Complexity - Hard, > Flexibility - High > # Update PutEmail with an optional attribute to unpack files generated by > MergeFile and add each entry as a new attachment. Complexity - Medium, > Hackiness - Medium > # Ignore PutEmail and use a custom script based on Groovy/Jython etc. > Complexity - Simple, Supportability Low > I've created a patch for 2 that I'll submit as a merge request soon. > Interested in feedback and happy to try other approaches if this is something > that the community is interested in supporting going forwards. > [1] > https://mail-archives.apache.org/mod_mbox/nifi-users/201709.mbox/%3CCALJK9a6oSdy5PXaKE0GxY1M3xQqYW8%2B0UUgsQmtbkO1qMK-MQA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3068: NIFI-5693 add support for multiple attachments in PutEmail...
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/3068 I like your #2 approach, as shown in this PR. I haven't tested it yet, but can you provide a better description on the property? Right now there is no way for a user to know that TAR is the expected merge format (instead of, for example, the NiFi FlowFile packing format) ---
[jira] [Commented] (NIFI-5696) Update references to default value for nifi.cluster.node.load.load.balance.port
[ https://issues.apache.org/jira/browse/NIFI-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648439#comment-16648439 ] ASF GitHub Bot commented on NIFI-5696: -- GitHub user jtstorck opened a pull request: https://github.com/apache/nifi/pull/3071 NIFI-5696 Update references to default value for nifi.cluster.node.lo… …ad.load.balance.port Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [n/a] Have you written or updated unit tests to verify your changes? - [n/a] 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)? - [n/a] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [n/a] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [n/a] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [n/a] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jtstorck/nifi NIFI-5696 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3071.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3071 commit 8c5329eb64fe14a55b12e0af08783bdcbc6a7c0b Author: Jeff Storck Date: 2018-10-12T20:57:15Z NIFI-5696 Update references to default value for nifi.cluster.node.load.load.balance.port > Update references to default value for > nifi.cluster.node.load.load.balance.port > --- > > Key: NIFI-5696 > URL: https://issues.apache.org/jira/browse/NIFI-5696 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Minor > Fix For: 1.8.0 > > > Update the maven filtering value of nifi.cluster.node.load.balance.port in > nifi-resources/pom.xml from 7320 to 6342 to match the default value for > NiFiProperties.DEFAULT_LOAD_BALANCE_PORT. > Update NodeIdentifier constructor that passes '6342' as the load balance port > to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit > value, which already matched the constant's value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3071: NIFI-5696 Update references to default value for ni...
GitHub user jtstorck opened a pull request: https://github.com/apache/nifi/pull/3071 NIFI-5696 Update references to default value for nifi.cluster.node.lo⦠â¦ad.load.balance.port Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [n/a] Have you written or updated unit tests to verify your changes? - [n/a] 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)? - [n/a] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [n/a] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [n/a] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [n/a] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jtstorck/nifi NIFI-5696 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3071.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3071 commit 8c5329eb64fe14a55b12e0af08783bdcbc6a7c0b Author: Jeff Storck Date: 2018-10-12T20:57:15Z NIFI-5696 Update references to default value for nifi.cluster.node.load.load.balance.port ---
[jira] [Updated] (NIFI-5696) Update references to default value for nifi.cluster.node.load.load.balance.port
[ https://issues.apache.org/jira/browse/NIFI-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5696: -- Status: Patch Available (was: Open) > Update references to default value for > nifi.cluster.node.load.load.balance.port > --- > > Key: NIFI-5696 > URL: https://issues.apache.org/jira/browse/NIFI-5696 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Minor > Fix For: 1.8.0 > > > Update the maven filtering value of nifi.cluster.node.load.balance.port in > nifi-resources/pom.xml from 7320 to 6342 to match the default value for > NiFiProperties.DEFAULT_LOAD_BALANCE_PORT. > Update NodeIdentifier constructor that passes '6342' as the load balance port > to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit > value, which already matched the constant's value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5667) Hive3 PutOrc processors, error when using nestled Avro Record types
[
https://issues.apache.org/jira/browse/NIFI-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648425#comment-16648425
]
ASF GitHub Bot commented on NIFI-5667:
--
Github user mattyb149 commented on the issue:
https://github.com/apache/nifi/pull/3057
Updated the rest of the backticks, thanks @VikingK and @bbende for your
reviews!
> Hive3 PutOrc processors, error when using nestled Avro Record types
> ---
>
> Key: NIFI-5667
> URL: https://issues.apache.org/jira/browse/NIFI-5667
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Centos 7 and Docker Image from Hortonworks
>Reporter: Viking Karstorp
>Assignee: Matt Burgess
>Priority: Major
>
> I have been testing out the new PutOrc processor that was introduced in 1.7
> to see if I can replace the ConvertAvroToOrc processer I currently use.
> When I sent in some of the complex Avro messages in my flow I encountered the
> following error (see full stack further down)
> java.lang.IllegalArgumentException: Error converting object of type
> org.apache.nifi.serialization.record.MapRecord to ORC type The older
> ConvertAvroToOrc processor processed the flowfile without issues. Also to
> note is that the PutOrc processor handles the flowfile fine if there is no
> Avro data with only the schema present. It seems to be related to nestled
> "Record" types.
> How to reproduce:
> Avro schema: bug.avsc
> {code}
> {
> "name": "nifi_hive3_test",
> "namespace": "analytics.models.test",
> "type": "record",
> "fields": [
>{
> "name": "Serial",
> "type":
> {
> "name": "Serial",
> "namespace": "analytics.models.common.serial",
> "type": "record",
> "fields": [
> {
> "name": "Serial",
> "type": "long"
> }
> ]
> }
> }
> ]
> }
> {code}
> Small python script to create an Avro file.
> {code}
> import avro.schema
> from avro.datafile import DataFileReader, DataFileWriter
> from avro.io import DatumReader, DatumWriter
> schema = avro.schema.parse(open("bug.avsc", "rb").read())
> writer = DataFileWriter(open("bug.avro", "wb"), DatumWriter(), schema)
> writer.append({'Serial': {'Serial': 110881615L}})
> writer.close()
> #Print whats entered into the avro file
> reader1 = DataFileReader(open("bug.avro", "rb"), DatumReader())
> for user in reader1:
> print user
> {code}
> Then just load the avro file using ListFIle -> FetchFile
> Full error message:
> {code}
> 2018-10-06 15:54:10,201 ERROR [Timer-Driven Process Thread-8]
> org.apache.nifi.processors.orc.PutORC
> PutORC[id=8be207cb-b16e-3578-1765-1c9e0c0aa383] Failed to write due to
> java.lang.IllegalArgumentException: Error converting object of type
> org.apache.nifi.serialization.record.MapRecord to ORC type
> struct: java.lang.IllegalArgumentException: Error converting
> object of type org.apache.nifi.serialization.record.MapRecord to ORC type
> struct
> java.lang.IllegalArgumentException: Error converting object of type
> org.apache.nifi.serialization.record.MapRecord to ORC type
> struct
> at
> org.apache.hadoop.hive.ql.io.orc.NiFiOrcUtils.convertToORCObject(NiFiOrcUtils.java:206)
> at
> org.apache.nifi.processors.orc.record.ORCHDFSRecordWriter.write(ORCHDFSRecordWriter.java:71)
> at
> org.apache.nifi.processors.orc.record.ORCHDFSRecordWriter.write(ORCHDFSRecordWriter.java:91)
> at
> org.apache.nifi.processors.hadoop.AbstractPutHDFSRecord.lambda$null$0(AbstractPutHDFSRecord.java:324)
> at
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2218)
> at
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2186)
> at
> org.apache.nifi.processors.hadoop.AbstractPutHDFSRecord.lambda$onTrigger$1(AbstractPutHDFSRecord.java:305)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1662)
> at
> org.apache.nifi.processors.hadoop.AbstractPutHDFSRecord.onTrigger(AbstractPutHDFSRecord.java:272)
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1165)
> at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:203)
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
>
[GitHub] nifi issue #3057: NIFI-5667: Add nested record support for PutORC
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/3057 Updated the rest of the backticks, thanks @VikingK and @bbende for your reviews! ---
[jira] [Updated] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-5695: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648418#comment-16648418 ] ASF subversion and git services commented on NIFI-5695: --- Commit 270ce8570df7a00a26f431d8d8ae0245b898bf69 in nifi's branch refs/heads/master from [~markap14] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=270ce85 ] NIFI-5695: Fixed bug that caused ports to not properly map to their correct child group on Flow Import if the child group is independently versioned This closes #3070. Signed-off-by: Bryan Bende > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648419#comment-16648419 ] ASF GitHub Bot commented on NIFI-5695: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3070 > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3070: NIFI-5695: Fixed bug that caused ports to not prope...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3070 ---
[jira] [Commented] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648416#comment-16648416 ] ASF GitHub Bot commented on NIFI-5695: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/3070 Verified this fixes the issue, looks good to me. > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3070: NIFI-5695: Fixed bug that caused ports to not properly map...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/3070 Verified this fixes the issue, looks good to me. ---
[jira] [Updated] (NIFI-5696) Update references to default value for nifi.cluster.node.load.load.balance.port
[ https://issues.apache.org/jira/browse/NIFI-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5696: -- Description: Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. Update NodeIdentifier constructor that passes '6342' as the load balance port to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit value, which already matched the constant's value. was:Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. > Update references to default value for > nifi.cluster.node.load.load.balance.port > --- > > Key: NIFI-5696 > URL: https://issues.apache.org/jira/browse/NIFI-5696 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Minor > Fix For: 1.8.0 > > > Update the maven filtering value of nifi.cluster.node.load.balance.port in > nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. > Update NodeIdentifier constructor that passes '6342' as the load balance port > to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit > value, which already matched the constant's value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5696) Update references to default value for nifi.cluster.node.load.load.balance.port
[ https://issues.apache.org/jira/browse/NIFI-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5696: -- Description: Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6342 to match the default value for NiFiProperties.DEFAULT_LOAD_BALANCE_PORT. Update NodeIdentifier constructor that passes '6342' as the load balance port to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit value, which already matched the constant's value. was: Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. Update NodeIdentifier constructor that passes '6342' as the load balance port to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit value, which already matched the constant's value. > Update references to default value for > nifi.cluster.node.load.load.balance.port > --- > > Key: NIFI-5696 > URL: https://issues.apache.org/jira/browse/NIFI-5696 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Minor > Fix For: 1.8.0 > > > Update the maven filtering value of nifi.cluster.node.load.balance.port in > nifi-resources/pom.xml from 7320 to 6342 to match the default value for > NiFiProperties.DEFAULT_LOAD_BALANCE_PORT. > Update NodeIdentifier constructor that passes '6342' as the load balance port > to use NiFiProperties.DEFAULT_LOAD_BALANCE_PORT rather than an explicit > value, which already matched the constant's value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5696) Update references to default value for nifi.cluster.node.load.load.balance.port
[ https://issues.apache.org/jira/browse/NIFI-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5696: -- Summary: Update references to default value for nifi.cluster.node.load.load.balance.port (was: Update maven filtering value for nifi.cluster.node.load.load.balance.port) > Update references to default value for > nifi.cluster.node.load.load.balance.port > --- > > Key: NIFI-5696 > URL: https://issues.apache.org/jira/browse/NIFI-5696 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Minor > Fix For: 1.8.0 > > > Update the maven filtering value of nifi.cluster.node.load.balance.port in > nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5696) Update maven filtering value for nifi.cluster.node.load.load.balance.port
[ https://issues.apache.org/jira/browse/NIFI-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5696: -- Description: Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. (was: Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6432 to match the default in the code.) > Update maven filtering value for nifi.cluster.node.load.load.balance.port > - > > Key: NIFI-5696 > URL: https://issues.apache.org/jira/browse/NIFI-5696 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Minor > Fix For: 1.8.0 > > > Update the maven filtering value of nifi.cluster.node.load.balance.port in > nifi-resources/pom.xml from 7320 to 6342 to match the default in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648390#comment-16648390 ] ASF GitHub Bot commented on NIFI-5665: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3067 > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman resolved NIFI-5665. --- Resolution: Fixed > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648389#comment-16648389 ] ASF GitHub Bot commented on NIFI-5665: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/3067 Thanks @thenatog! This has been merged to master. > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648387#comment-16648387 ] ASF subversion and git services commented on NIFI-5665: --- Commit 5eb5e96b1621d87bf8cca96d18a2c36177a1f54e in nifi's branch refs/heads/master from thenatog [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=5eb5e96 ] NIFI-5665 - Changed netty versions to more closely match the original netty dependency version. NIFI-5665 - Fixed version for nifi-spark-bundle. NIFI-5665 - Fixing copy and paste error. This closes #3067 > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648384#comment-16648384 ] ASF subversion and git services commented on NIFI-5665: --- Commit 5eb5e96b1621d87bf8cca96d18a2c36177a1f54e in nifi's branch refs/heads/master from thenatog [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=5eb5e96 ] NIFI-5665 - Changed netty versions to more closely match the original netty dependency version. NIFI-5665 - Fixed version for nifi-spark-bundle. NIFI-5665 - Fixing copy and paste error. This closes #3067 > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3067: NIFI-5665 - Setting zookeeper's io.netty:netty tran...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3067 ---
[GitHub] nifi issue #3067: NIFI-5665 - Setting zookeeper's io.netty:netty transitive ...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/3067 Thanks @thenatog! This has been merged to master. ---
[jira] [Commented] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648386#comment-16648386 ] ASF subversion and git services commented on NIFI-5665: --- Commit 5eb5e96b1621d87bf8cca96d18a2c36177a1f54e in nifi's branch refs/heads/master from thenatog [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=5eb5e96 ] NIFI-5665 - Changed netty versions to more closely match the original netty dependency version. NIFI-5665 - Fixed version for nifi-spark-bundle. NIFI-5665 - Fixing copy and paste error. This closes #3067 > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-5696) Update maven filtering value for nifi.cluster.node.load.load.balance.port
Jeff Storck created NIFI-5696: - Summary: Update maven filtering value for nifi.cluster.node.load.load.balance.port Key: NIFI-5696 URL: https://issues.apache.org/jira/browse/NIFI-5696 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.8.0 Reporter: Jeff Storck Assignee: Jeff Storck Fix For: 1.8.0 Update the maven filtering value of nifi.cluster.node.load.balance.port in nifi-resources/pom.xml from 7320 to 6432 to match the default in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648354#comment-16648354 ] ASF GitHub Bot commented on NIFI-5695: -- Github user ottobackwards commented on the issue: https://github.com/apache/nifi/pull/3070 Is there a way that the duplicated code can be shared? > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3070: NIFI-5695: Fixed bug that caused ports to not properly map...
Github user ottobackwards commented on the issue: https://github.com/apache/nifi/pull/3070 Is there a way that the duplicated code can be shared? ---
[GitHub] nifi-minifi pull request #138: MINIFI-472 Updating dependency versions for i...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi/pull/138 ---
[jira] [Updated] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5695: - Status: Patch Available (was: Open) > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5695: - Priority: Critical (was: Major) > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5695: - Fix Version/s: 1.8.0 > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648347#comment-16648347 ] ASF GitHub Bot commented on NIFI-5695: -- GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/3070 NIFI-5695: Fixed bug that caused ports to not properly map to their c… …orrect child group on Flow Import if the child group is independently versioned Thank you for submitting a contribution to Apache NiFi. 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- where 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 master)? - [ ] Is your initial contribution a single, squashed commit? ### 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? - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-5695 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3070.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3070 commit c9cd1909b787076c5ddd81dd6f9f61dafe5e4632 Author: Mark Payne Date: 2018-10-12T19:27:10Z NIFI-5695: Fixed bug that caused ports to not properly map to their correct child group on Flow Import if the child group is independently versioned > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.8.0 > > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3070: NIFI-5695: Fixed bug that caused ports to not prope...
GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/3070 NIFI-5695: Fixed bug that caused ports to not properly map to their c⦠â¦orrect child group on Flow Import if the child group is independently versioned Thank you for submitting a contribution to Apache NiFi. 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- where 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 master)? - [ ] Is your initial contribution a single, squashed commit? ### 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? - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-5695 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3070.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3070 commit c9cd1909b787076c5ddd81dd6f9f61dafe5e4632 Author: Mark Payne Date: 2018-10-12T19:27:10Z NIFI-5695: Fixed bug that caused ports to not properly map to their correct child group on Flow Import if the child group is independently versioned ---
[jira] [Updated] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5695: - Attachment: Original-Group.png > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Attachments: Group-After-Import.png, Original-Group.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-618) Add C2 triggers for local updates
[ https://issues.apache.org/jira/browse/MINIFICPP-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648343#comment-16648343 ] ASF GitHub Bot commented on MINIFICPP-618: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/415 > Add C2 triggers for local updates > - > > Key: MINIFICPP-618 > URL: https://issues.apache.org/jira/browse/MINIFICPP-618 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
[ https://issues.apache.org/jira/browse/NIFI-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5695: - Attachment: Group-After-Import.png > Connections to/from child groups' ports get confused when importing flow from > Flow Registry > --- > > Key: NIFI-5695 > URL: https://issues.apache.org/jira/browse/NIFI-5695 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Attachments: Group-After-Import.png > > > To replicate, create a Process Group with the following components: > InputPort -> LogAttribute -> OutputPort > Then move to the higher group and add this to Version Control. > Next, import another copy of the same group. > Connect the first child group's OutputPort to the second group's InputPort. > Add a GenerateFlowFile and connect it to the first group's Input Port. > Add a LogAttribute and connect the second group's OutputPort to it. > Now, version control the outer group. > At this point, all should behave as expected. > Now, if you import a second copy of the outer group, the newly imported group > has connections going to/from the wrong ports. It appears that NiFi is not > properly mapping a port in a child group to the appropriate child group if > there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #415: MINIFICPP-618: Add C2 triggers, first of ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/415 ---
[jira] [Commented] (MINIFICPP-624) Internal C2 configuration options are not consistent in naming
[ https://issues.apache.org/jira/browse/MINIFICPP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648341#comment-16648341 ] Aldrin Piri commented on MINIFICPP-624: --- Resolved via ed8221b14d8ba9b4d1713cb618bca6f194e6bcf7 > Internal C2 configuration options are not consistent in naming > -- > > Key: MINIFICPP-624 > URL: https://issues.apache.org/jira/browse/MINIFICPP-624 > Project: NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Make consistent by supporting backwards compatibility -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-618) Add C2 triggers for local updates
[ https://issues.apache.org/jira/browse/MINIFICPP-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri updated MINIFICPP-618: -- Resolution: Done Status: Resolved (was: Patch Available) > Add C2 triggers for local updates > - > > Key: MINIFICPP-618 > URL: https://issues.apache.org/jira/browse/MINIFICPP-618 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MINIFICPP-624) Internal C2 configuration options are not consistent in naming
[ https://issues.apache.org/jira/browse/MINIFICPP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri resolved MINIFICPP-624. --- Resolution: Fixed > Internal C2 configuration options are not consistent in naming > -- > > Key: MINIFICPP-624 > URL: https://issues.apache.org/jira/browse/MINIFICPP-624 > Project: NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Make consistent by supporting backwards compatibility -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-5695) Connections to/from child groups' ports get confused when importing flow from Flow Registry
Mark Payne created NIFI-5695: Summary: Connections to/from child groups' ports get confused when importing flow from Flow Registry Key: NIFI-5695 URL: https://issues.apache.org/jira/browse/NIFI-5695 Project: Apache NiFi Issue Type: Bug Components: Core Framework Reporter: Mark Payne Assignee: Mark Payne To replicate, create a Process Group with the following components: InputPort -> LogAttribute -> OutputPort Then move to the higher group and add this to Version Control. Next, import another copy of the same group. Connect the first child group's OutputPort to the second group's InputPort. Add a GenerateFlowFile and connect it to the first group's Input Port. Add a LogAttribute and connect the second group's OutputPort to it. Now, version control the outer group. At this point, all should behave as expected. Now, if you import a second copy of the outer group, the newly imported group has connections going to/from the wrong ports. It appears that NiFi is not properly mapping a port in a child group to the appropriate child group if there are multiple copies of the (independently versioned) child group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-618) Add C2 triggers for local updates
[ https://issues.apache.org/jira/browse/MINIFICPP-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648339#comment-16648339 ] ASF GitHub Bot commented on MINIFICPP-618: -- Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/415 Organization and docs look good, will get this merged in. Thanks! > Add C2 triggers for local updates > - > > Key: MINIFICPP-618 > URL: https://issues.apache.org/jira/browse/MINIFICPP-618 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp issue #415: MINIFICPP-618: Add C2 triggers, first of which m...
Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/415 Organization and docs look good, will get this merged in. Thanks! ---
[jira] [Commented] (MINIFICPP-618) Add C2 triggers for local updates
[ https://issues.apache.org/jira/browse/MINIFICPP-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648331#comment-16648331 ] ASF GitHub Bot commented on MINIFICPP-618: -- Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/415 I see now that those changes came in just as I posted those comments. Those updates look good here. > Add C2 triggers for local updates > - > > Key: MINIFICPP-618 > URL: https://issues.apache.org/jira/browse/MINIFICPP-618 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp issue #415: MINIFICPP-618: Add C2 triggers, first of which m...
Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/415 I see now that those changes came in just as I posted those comments. Those updates look good here. ---
[jira] [Commented] (MINIFICPP-618) Add C2 triggers for local updates
[
https://issues.apache.org/jira/browse/MINIFICPP-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648321#comment-16648321
]
ASF GitHub Bot commented on MINIFICPP-618:
--
Github user apiri commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/415#discussion_r224886539
--- Diff: libminifi/src/c2/C2Agent.cpp ---
@@ -187,6 +209,22 @@ void C2Agent::configure(const
std::shared_ptr , bool reconf
}
}
+ std::string trigger_classes;
+ if (configure->get("nifi.c2.agent.trigger.classes",
"c2.agent.trigger.classes", trigger_classes)) {
--- End diff --
Looks like this is missing from the docs to specify a class or should be
assumed when the property pertaining to the file update trigger is provided in
the configuration.
> Add C2 triggers for local updates
> -
>
> Key: MINIFICPP-618
> URL: https://issues.apache.org/jira/browse/MINIFICPP-618
> Project: NiFi MiNiFi C++
> Issue Type: New Feature
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.6.0
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #415: MINIFICPP-618: Add C2 triggers, first of ...
Github user apiri commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/415#discussion_r224886539
--- Diff: libminifi/src/c2/C2Agent.cpp ---
@@ -187,6 +209,22 @@ void C2Agent::configure(const
std::shared_ptr , bool reconf
}
}
+ std::string trigger_classes;
+ if (configure->get("nifi.c2.agent.trigger.classes",
"c2.agent.trigger.classes", trigger_classes)) {
--- End diff --
Looks like this is missing from the docs to specify a class or should be
assumed when the property pertaining to the file update trigger is provided in
the configuration.
---
[jira] [Commented] (NIFI-4806) Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported against all releases prior to 1.19
[ https://issues.apache.org/jira/browse/NIFI-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648316#comment-16648316 ] ASF GitHub Bot commented on NIFI-4806: -- Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/3069 +1 for sure assuming build work sout > Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported > against all releases prior to 1.19 > --- > > Key: NIFI-4806 > URL: https://issues.apache.org/jira/browse/NIFI-4806 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.5.0 >Reporter: Joseph Witt >Assignee: Matt Gilman >Priority: Blocker > Fix For: 1.8.0 > > > The nifi-media-processors depend on Tika-Parsers 1.16 as of now. They need > to be upgraded to at least Tika-Parsers 1.18 to resolve the licensing problem > identified to the Tika team and which they resolved in > https://issues.apache.org/jira/browse/TIKA-2535 > > We aren't susceptible to the licensing problem at this time because when we > did the last update for Tika-Parsers this was flagged and excluded though we > could be exposing bugs for certain datayptes we'd do mime detection on > (maybe). I have a comment about this in our pom. > > This Jira is to upgrade, ensure no invalid libs are used, and clean up the > comments and move on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4806) Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported against all releases prior to 1.19
[ https://issues.apache.org/jira/browse/NIFI-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648279#comment-16648279 ] ASF GitHub Bot commented on NIFI-4806: -- GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/3069 NIFI-4806: Bumping to tika 1.19.1 NIFI-4806: - Bumping to tika 1.19.1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-4806 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3069.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3069 commit bba58ee1cdfc7bcd36484e6849401af08cd6f23e Author: Matt Gilman Date: 2018-10-12T18:30:34Z NIFI-4806: - Bumping to tika 1.19.1. > Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported > against all releases prior to 1.19 > --- > > Key: NIFI-4806 > URL: https://issues.apache.org/jira/browse/NIFI-4806 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.5.0 >Reporter: Joseph Witt >Assignee: Matt Gilman >Priority: Blocker > Fix For: 1.8.0 > > > The nifi-media-processors depend on Tika-Parsers 1.16 as of now. They need > to be upgraded to at least Tika-Parsers 1.18 to resolve the licensing problem > identified to the Tika team and which they resolved in > https://issues.apache.org/jira/browse/TIKA-2535 > > We aren't susceptible to the licensing problem at this time because when we > did the last update for Tika-Parsers this was flagged and excluded though we > could be exposing bugs for certain datayptes we'd do mime detection on > (maybe). I have a comment about this in our pom. > > This Jira is to upgrade, ensure no invalid libs are used, and clean up the > comments and move on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4806) Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported against all releases prior to 1.19
[ https://issues.apache.org/jira/browse/NIFI-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-4806: -- Status: Patch Available (was: In Progress) > Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported > against all releases prior to 1.19 > --- > > Key: NIFI-4806 > URL: https://issues.apache.org/jira/browse/NIFI-4806 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.5.0 >Reporter: Joseph Witt >Assignee: Matt Gilman >Priority: Blocker > Fix For: 1.8.0 > > > The nifi-media-processors depend on Tika-Parsers 1.16 as of now. They need > to be upgraded to at least Tika-Parsers 1.18 to resolve the licensing problem > identified to the Tika team and which they resolved in > https://issues.apache.org/jira/browse/TIKA-2535 > > We aren't susceptible to the licensing problem at this time because when we > did the last update for Tika-Parsers this was flagged and excluded though we > could be exposing bugs for certain datayptes we'd do mime detection on > (maybe). I have a comment about this in our pom. > > This Jira is to upgrade, ensure no invalid libs are used, and clean up the > comments and move on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3069: NIFI-4806: Bumping to tika 1.19.1
GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/3069 NIFI-4806: Bumping to tika 1.19.1 NIFI-4806: - Bumping to tika 1.19.1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-4806 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3069.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3069 commit bba58ee1cdfc7bcd36484e6849401af08cd6f23e Author: Matt Gilman Date: 2018-10-12T18:30:34Z NIFI-4806: - Bumping to tika 1.19.1. ---
[jira] [Commented] (NIFI-5680) Using inconsistent location URL for Registry Client on different NiFi instances will break ability to import version controlled flows that contain nested version control
[ https://issues.apache.org/jira/browse/NIFI-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648274#comment-16648274 ] ASF GitHub Bot commented on NIFI-5680: -- Github user markap14 commented on the issue: https://github.com/apache/nifi/pull/3065 Thanks @bbende, all looks good to me. +1 merged to master. > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > --- > > Key: NIFI-5680 > URL: https://issues.apache.org/jira/browse/NIFI-5680 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.5.0, 1.6.0, 1.7.0 >Reporter: Matthew Clarke >Assignee: Bryan Bende >Priority: Major > Fix For: 1.8.0 > > > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > For example: > on NiFi instance 1, configure "Registry Client" location URL with > https://:/ > on NiFi instance 2, configure "Registry Client" location URL with > https://: > notice that one contains a trailing "/" > On one of your NiFi instances, create a Process Group (PG). > Inside that PG, create another "sub-PG". > Start version control of sub-PG. > Go back to parent PG and also start version control on that "PG". > Go to your other NiFi instance and try to "import" the "PG" version > controlled flow. > Import will fail and throw following error in nifi-user.log: > o.a.n.w.a.c.IllegalArgumentExceptionMapper > java.lang.IllegalArgumentException: The Flow Registry with ID reports > that no Flow exists with Bucket , Flow Request response. > Even though registry does include the referenced UUIDs in that log output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5680) Using inconsistent location URL for Registry Client on different NiFi instances will break ability to import version controlled flows that contain nested version controlle
[ https://issues.apache.org/jira/browse/NIFI-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5680: - Resolution: Fixed Fix Version/s: 1.8.0 Status: Resolved (was: Patch Available) > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > --- > > Key: NIFI-5680 > URL: https://issues.apache.org/jira/browse/NIFI-5680 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.5.0, 1.6.0, 1.7.0 >Reporter: Matthew Clarke >Assignee: Bryan Bende >Priority: Major > Fix For: 1.8.0 > > > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > For example: > on NiFi instance 1, configure "Registry Client" location URL with > https://:/ > on NiFi instance 2, configure "Registry Client" location URL with > https://: > notice that one contains a trailing "/" > On one of your NiFi instances, create a Process Group (PG). > Inside that PG, create another "sub-PG". > Start version control of sub-PG. > Go back to parent PG and also start version control on that "PG". > Go to your other NiFi instance and try to "import" the "PG" version > controlled flow. > Import will fail and throw following error in nifi-user.log: > o.a.n.w.a.c.IllegalArgumentExceptionMapper > java.lang.IllegalArgumentException: The Flow Registry with ID reports > that no Flow exists with Bucket , Flow Request response. > Even though registry does include the referenced UUIDs in that log output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5680) Using inconsistent location URL for Registry Client on different NiFi instances will break ability to import version controlled flows that contain nested version control
[ https://issues.apache.org/jira/browse/NIFI-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648275#comment-16648275 ] ASF GitHub Bot commented on NIFI-5680: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3065 > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > --- > > Key: NIFI-5680 > URL: https://issues.apache.org/jira/browse/NIFI-5680 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.5.0, 1.6.0, 1.7.0 >Reporter: Matthew Clarke >Assignee: Bryan Bende >Priority: Major > Fix For: 1.8.0 > > > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > For example: > on NiFi instance 1, configure "Registry Client" location URL with > https://:/ > on NiFi instance 2, configure "Registry Client" location URL with > https://: > notice that one contains a trailing "/" > On one of your NiFi instances, create a Process Group (PG). > Inside that PG, create another "sub-PG". > Start version control of sub-PG. > Go back to parent PG and also start version control on that "PG". > Go to your other NiFi instance and try to "import" the "PG" version > controlled flow. > Import will fail and throw following error in nifi-user.log: > o.a.n.w.a.c.IllegalArgumentExceptionMapper > java.lang.IllegalArgumentException: The Flow Registry with ID reports > that no Flow exists with Bucket , Flow Request response. > Even though registry does include the referenced UUIDs in that log output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3065: NIFI-5680 Handling trailing slashes on URLs of regi...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3065 ---
[GitHub] nifi issue #3065: NIFI-5680 Handling trailing slashes on URLs of registry cl...
Github user markap14 commented on the issue: https://github.com/apache/nifi/pull/3065 Thanks @bbende, all looks good to me. +1 merged to master. ---
[jira] [Commented] (NIFI-5680) Using inconsistent location URL for Registry Client on different NiFi instances will break ability to import version controlled flows that contain nested version control
[ https://issues.apache.org/jira/browse/NIFI-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648272#comment-16648272 ] ASF subversion and git services commented on NIFI-5680: --- Commit 02e0a16a681bea3a2bee6a90aa87baed2404a25e in nifi's branch refs/heads/master from [~bbende] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=02e0a16 ] NIFI-5680 Handling trailing slashes on URLs of registry clients This closes #3065. Signed-off-by: Mark Payne > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > --- > > Key: NIFI-5680 > URL: https://issues.apache.org/jira/browse/NIFI-5680 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.5.0, 1.6.0, 1.7.0 >Reporter: Matthew Clarke >Assignee: Bryan Bende >Priority: Major > > Using inconsistent location URL for Registry Client on different NiFi > instances will break ability to import version controlled flows that contain > nested version controlled flows. > For example: > on NiFi instance 1, configure "Registry Client" location URL with > https://:/ > on NiFi instance 2, configure "Registry Client" location URL with > https://: > notice that one contains a trailing "/" > On one of your NiFi instances, create a Process Group (PG). > Inside that PG, create another "sub-PG". > Start version control of sub-PG. > Go back to parent PG and also start version control on that "PG". > Go to your other NiFi instance and try to "import" the "PG" version > controlled flow. > Import will fail and throw following error in nifi-user.log: > o.a.n.w.a.c.IllegalArgumentExceptionMapper > java.lang.IllegalArgumentException: The Flow Registry with ID reports > that no Flow exists with Bucket , Flow Request response. > Even though registry does include the referenced UUIDs in that log output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5686) Test failure in TestStandardProcessScheduler
[
https://issues.apache.org/jira/browse/NIFI-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648253#comment-16648253
]
ASF GitHub Bot commented on NIFI-5686:
--
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3062
@joewitt thanks, I've pushed another commit.
> Test failure in TestStandardProcessScheduler
>
>
> Key: NIFI-5686
> URL: https://issues.apache.org/jira/browse/NIFI-5686
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.8.0
>
>
> The {{testReportingTaskDoesntKeepRunningAfterStop}} test in
> {{TestStandardProcessScheduler}} now fails. This was \{{@Ignore}} d in
> NIFI-5666 but should be addressed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi issue #3062: NIFI-5686: Updated StandardProcessScheduler so that if it ...
Github user markap14 commented on the issue: https://github.com/apache/nifi/pull/3062 @joewitt thanks, I've pushed another commit. ---
[jira] [Reopened] (NIFI-4806) Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported against all releases prior to 1.19
[ https://issues.apache.org/jira/browse/NIFI-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman reopened NIFI-4806: --- Assignee: Matt Gilman (was: Joseph Witt) Reopening to bump to tika 1.19.1 > Upgrade to Tika/Tika-Parsers 1.19 to resolve TIKA-2535 and CVEs reported > against all releases prior to 1.19 > --- > > Key: NIFI-4806 > URL: https://issues.apache.org/jira/browse/NIFI-4806 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.5.0 >Reporter: Joseph Witt >Assignee: Matt Gilman >Priority: Blocker > Fix For: 1.8.0 > > > The nifi-media-processors depend on Tika-Parsers 1.16 as of now. They need > to be upgraded to at least Tika-Parsers 1.18 to resolve the licensing problem > identified to the Tika team and which they resolved in > https://issues.apache.org/jira/browse/TIKA-2535 > > We aren't susceptible to the licensing problem at this time because when we > did the last update for Tika-Parsers this was flagged and excluded though we > could be exposing bugs for certain datayptes we'd do mime detection on > (maybe). I have a comment about this in our pom. > > This Jira is to upgrade, ensure no invalid libs are used, and clean up the > comments and move on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5691) Upgrade Jackson for AWS NARs
[ https://issues.apache.org/jira/browse/NIFI-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri updated NIFI-5691: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Jackson for AWS NARs > > > Key: NIFI-5691 > URL: https://issues.apache.org/jira/browse/NIFI-5691 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.8.0 > > > The AWS NARs are currently bundling an old version of Jackson. According to > AWS this is because they are maintaining capability with Java 6. They also > state that client applications are welcome to override that version if they > want to [1]. > Will override to bring Jackson usage in line with the rest of the application. > [1] https://github.com/aws/aws-sdk-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5691) Upgrade Jackson for AWS NARs
[ https://issues.apache.org/jira/browse/NIFI-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri updated NIFI-5691: -- Fix Version/s: 1.8.0 > Upgrade Jackson for AWS NARs > > > Key: NIFI-5691 > URL: https://issues.apache.org/jira/browse/NIFI-5691 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.8.0 > > > The AWS NARs are currently bundling an old version of Jackson. According to > AWS this is because they are maintaining capability with Java 6. They also > state that client applications are welcome to override that version if they > want to [1]. > Will override to bring Jackson usage in line with the rest of the application. > [1] https://github.com/aws/aws-sdk-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5691) Upgrade Jackson for AWS NARs
[ https://issues.apache.org/jira/browse/NIFI-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648168#comment-16648168 ] ASF subversion and git services commented on NIFI-5691: --- Commit 0f8880547fad35243dae0d4d4ab6d8a5eb38d516 in nifi's branch refs/heads/master from [~mcgilman] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=0f88805 ] NIFI-5691: - Overriding the version of jackson in aws java sdk. This closes #3066. Signed-off-by: Aldrin Piri > Upgrade Jackson for AWS NARs > > > Key: NIFI-5691 > URL: https://issues.apache.org/jira/browse/NIFI-5691 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.8.0 > > > The AWS NARs are currently bundling an old version of Jackson. According to > AWS this is because they are maintaining capability with Java 6. They also > state that client applications are welcome to override that version if they > want to [1]. > Will override to bring Jackson usage in line with the rest of the application. > [1] https://github.com/aws/aws-sdk-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5691) Upgrade Jackson for AWS NARs
[ https://issues.apache.org/jira/browse/NIFI-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648170#comment-16648170 ] ASF GitHub Bot commented on NIFI-5691: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3066 > Upgrade Jackson for AWS NARs > > > Key: NIFI-5691 > URL: https://issues.apache.org/jira/browse/NIFI-5691 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.8.0 > > > The AWS NARs are currently bundling an old version of Jackson. According to > AWS this is because they are maintaining capability with Java 6. They also > state that client applications are welcome to override that version if they > want to [1]. > Will override to bring Jackson usage in line with the rest of the application. > [1] https://github.com/aws/aws-sdk-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3066: NIFI-5691: Overriding the version of jackson in aws...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3066 ---
[jira] [Commented] (NIFI-5691) Upgrade Jackson for AWS NARs
[ https://issues.apache.org/jira/browse/NIFI-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648163#comment-16648163 ] ASF GitHub Bot commented on NIFI-5691: -- Github user apiri commented on the issue: https://github.com/apache/nifi/pull/3066 Verified the build and functionality against AWS resources. I did note that the jackson-dataformat-cbor dependency was outdated and also updated that to the latest of 2.9.7. All operations worked as anticipated. Will get this merged. > Upgrade Jackson for AWS NARs > > > Key: NIFI-5691 > URL: https://issues.apache.org/jira/browse/NIFI-5691 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > > The AWS NARs are currently bundling an old version of Jackson. According to > AWS this is because they are maintaining capability with Java 6. They also > state that client applications are welcome to override that version if they > want to [1]. > Will override to bring Jackson usage in line with the rest of the application. > [1] https://github.com/aws/aws-sdk-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3066: NIFI-5691: Overriding the version of jackson in aws java s...
Github user apiri commented on the issue: https://github.com/apache/nifi/pull/3066 Verified the build and functionality against AWS resources. I did note that the jackson-dataformat-cbor dependency was outdated and also updated that to the latest of 2.9.7. All operations worked as anticipated. Will get this merged. ---
[jira] [Commented] (NIFI-5694) StandardSSLContextService references configContext in a non-thread safe manner
[
https://issues.apache.org/jira/browse/NIFI-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648112#comment-16648112
]
Joseph Percivall commented on NIFI-5694:
FYI, I originally had another comment in the description[1] but turns out this
wasn't a root cause. I've not super well versed on why/how but I have a PKCS12
file which is also valid as a JKS file (verified using openssl + keytool).
Something weird with the generation of the trust factory leads it to a state
where it successfully created the trust factory when treating the file as JKS
but not as PKCS12.
This ticket is still an issue though and should be addressed.
[1]
{noformat}
I believe this is the cause of the weirdness I'm seeing where I have the SSL
context "successfully" configured with a truststore of type "JKS" and am able
to use it with an InovokeHttp processor. The problem is that the truststore is
actually P12 (verified on the command line). I believe the issue came about
because I wasn't sure if the type/password was correct and was
enabling+disabling+reconfiguring it in rapid succession. {noformat}
> StandardSSLContextService references configContext in a non-thread safe manner
> --
>
> Key: NIFI-5694
> URL: https://issues.apache.org/jira/browse/NIFI-5694
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.7.1
>Reporter: Joseph Percivall
>Priority: Major
>
> configContext is a variable which is accessed from many different threads
> (validate, enable, and any processor which calls "createSSLContext"). It is
> not declared with any thread safe modifier[1]. Potentially leading to odd
> behavior.
>
> The other shared variables should be marked with a thread-safe modifier as
> well.
> [1]
> [https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardSSLContextService.java#L121]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NIFI-5694) StandardSSLContextService references configContext in a non-thread safe manner
[ https://issues.apache.org/jira/browse/NIFI-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated NIFI-5694: --- Description: configContext is a variable which is accessed from many different threads (validate, enable, and any processor which calls "createSSLContext"). It is not declared with any thread safe modifier[1]. Potentially leading to odd behavior. The other shared variables should be marked with a thread-safe modifier as well. [1] [https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardSSLContextService.java#L121] was: configContext is a variable which is accessed from many different threads (validate, enable, and any processor which calls "createSSLContext"). It is not declared with any thread safe modifier[1]. Potentially leading to odd behavior. I believe this is the cause of the weirdness I'm seeing where I have the SSL context "successfully" configured with a truststore of type "JKS" and am able to use it with an InovokeHttp processor. The problem is that the truststore is actually P12 (verified on the command line). I believe the issue came about because I wasn't sure if the type/password was correct and was enabling+disabling+reconfiguring it in rapid succession. The other shared variables should be marked with a thread-safe modifier as well. [1] https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardSSLContextService.java#L121 > StandardSSLContextService references configContext in a non-thread safe manner > -- > > Key: NIFI-5694 > URL: https://issues.apache.org/jira/browse/NIFI-5694 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Joseph Percivall >Priority: Major > > configContext is a variable which is accessed from many different threads > (validate, enable, and any processor which calls "createSSLContext"). It is > not declared with any thread safe modifier[1]. Potentially leading to odd > behavior. > > The other shared variables should be marked with a thread-safe modifier as > well. > [1] > [https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardSSLContextService.java#L121] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5448) Failed EL date parsing live-locks processors without a failure relationship
[
https://issues.apache.org/jira/browse/NIFI-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Witt updated NIFI-5448:
--
Fix Version/s: (was: 1.8.0)
> Failed EL date parsing live-locks processors without a failure relationship
> ---
>
> Key: NIFI-5448
> URL: https://issues.apache.org/jira/browse/NIFI-5448
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Koster
>Assignee: Mike Thomsen
>Priority: Major
>
> Processors that utilize the Expression Language need to always present a
> failure relationship.
> If a processor with only a success relationship, for example UpdateAttribute,
> utilizes the expression language to perform type coercion to a date and
> fails, the processor will be unable to dispose of the FlowFile and remain
> blocked indefinitely.
> Recreation flow:
> GenerateFlowFile -> Update Attribute #1 -> Update Attribute #2 -> Anything
> Update Attribute #1 - test = "Hello World"
> Update Attribute #2 - test = ${test:toDate('-MM-dd')}
>
> Generates an IllegalAttributeException on UpdateAttribute.
>
> The behavior should match numerical type coercion and silently skip the
> processing or offer failure relationships on processors supporting EL
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NIFI-5448) Failed EL date parsing live-locks processors without a failure relationship
[
https://issues.apache.org/jira/browse/NIFI-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648067#comment-16648067
]
ASF subversion and git services commented on NIFI-5448:
---
Commit 6b77e7dd895affa739c55a7db969fa6bcde44ad1 in nifi's branch
refs/heads/master from joewitt
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=6b77e7d ]
Revert "NIFI-5448 Changed from 'stop' to 'penalize' in allowablevalue field to
make the popup more consistent."
This reverts commit 9d2b698c1cdfb54411b9f147573767bdda6e355c.
> Failed EL date parsing live-locks processors without a failure relationship
> ---
>
> Key: NIFI-5448
> URL: https://issues.apache.org/jira/browse/NIFI-5448
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Koster
>Assignee: Mike Thomsen
>Priority: Major
> Fix For: 1.8.0
>
>
> Processors that utilize the Expression Language need to always present a
> failure relationship.
> If a processor with only a success relationship, for example UpdateAttribute,
> utilizes the expression language to perform type coercion to a date and
> fails, the processor will be unable to dispose of the FlowFile and remain
> blocked indefinitely.
> Recreation flow:
> GenerateFlowFile -> Update Attribute #1 -> Update Attribute #2 -> Anything
> Update Attribute #1 - test = "Hello World"
> Update Attribute #2 - test = ${test:toDate('-MM-dd')}
>
> Generates an IllegalAttributeException on UpdateAttribute.
>
> The behavior should match numerical type coercion and silently skip the
> processing or offer failure relationships on processors supporting EL
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NIFI-5448) Failed EL date parsing live-locks processors without a failure relationship
[
https://issues.apache.org/jira/browse/NIFI-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648068#comment-16648068
]
ASF subversion and git services commented on NIFI-5448:
---
Commit e25b26e9cf860db038da8e23e8e64bdb1b8dba88 in nifi's branch
refs/heads/master from joewitt
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=e25b26e ]
Revert "NIFI-5448 Added failure relationship to UpdateAttributes to handle bad
expression language logic."
This reverts commit 32ee552ada328ed1189ed2bd0a2af18ed213ddc8.
> Failed EL date parsing live-locks processors without a failure relationship
> ---
>
> Key: NIFI-5448
> URL: https://issues.apache.org/jira/browse/NIFI-5448
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Koster
>Assignee: Mike Thomsen
>Priority: Major
> Fix For: 1.8.0
>
>
> Processors that utilize the Expression Language need to always present a
> failure relationship.
> If a processor with only a success relationship, for example UpdateAttribute,
> utilizes the expression language to perform type coercion to a date and
> fails, the processor will be unable to dispose of the FlowFile and remain
> blocked indefinitely.
> Recreation flow:
> GenerateFlowFile -> Update Attribute #1 -> Update Attribute #2 -> Anything
> Update Attribute #1 - test = "Hello World"
> Update Attribute #2 - test = ${test:toDate('-MM-dd')}
>
> Generates an IllegalAttributeException on UpdateAttribute.
>
> The behavior should match numerical type coercion and silently skip the
> processing or offer failure relationships on processors supporting EL
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (NIFI-5402) Reduce artifact size by only building .zip archive
[ https://issues.apache.org/jira/browse/NIFI-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-5402: --- Comment: was deleted (was: Original discussion here: https://lists.apache.org/thread.html/58cc05e07d31de0c46a80b337bfda599d98b961c9f6359a4e69b6d07@%3Cdev.nifi.apache.org%3E) > Reduce artifact size by only building .zip archive > -- > > Key: NIFI-5402 > URL: https://issues.apache.org/jira/browse/NIFI-5402 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.7.0 >Reporter: Andy LoPresto >Assignee: Nathan Gough >Priority: Major > Labels: archive, build, format, maven, tar, zip > > The maven build bundles two identical builds (one in .tar.gz format and one > in .zip format). Based on community discussion, there is no longer a need for > separate .tar.gz, and removing this would increase the speed of the build and > greatly decrease the hosting requirements for the binaries. > That said, building a .tar.gz archive should be available through an > (inactive) profile if a user wants to enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5402) Reduce artifact size by only building .zip archive
[ https://issues.apache.org/jira/browse/NIFI-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648054#comment-16648054 ] Nathan Gough commented on NIFI-5402: Original discussion here: https://lists.apache.org/thread.html/58cc05e07d31de0c46a80b337bfda599d98b961c9f6359a4e69b6d07@%3Cdev.nifi.apache.org%3E > Reduce artifact size by only building .zip archive > -- > > Key: NIFI-5402 > URL: https://issues.apache.org/jira/browse/NIFI-5402 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.7.0 >Reporter: Andy LoPresto >Assignee: Nathan Gough >Priority: Major > Labels: archive, build, format, maven, tar, zip > > The maven build bundles two identical builds (one in .tar.gz format and one > in .zip format). Based on community discussion, there is no longer a need for > separate .tar.gz, and removing this would increase the speed of the build and > greatly decrease the hosting requirements for the binaries. > That said, building a .tar.gz archive should be available through an > (inactive) profile if a user wants to enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-640) C API: how to support dynamic properties?
Arpad Boda created MINIFICPP-640: Summary: C API: how to support dynamic properties? Key: MINIFICPP-640 URL: https://issues.apache.org/jira/browse/MINIFICPP-640 Project: NiFi MiNiFi C++ Issue Type: Brainstorming Reporter: Arpad Boda Assignee: Arpad Boda The current C API implementation only allows static properties to be set/updated, which means processors that would require dynamic attributes, such as UpdateAttribute cannot be configured properly. The question is whether the difference between static and dynamic properties should be transparent via the API or this should be hidden and handled inside. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (NIFI-5402) Reduce artifact size by only building .zip archive
[ https://issues.apache.org/jira/browse/NIFI-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648034#comment-16648034 ] Kevin Doran edited comment on NIFI-5402 at 10/12/18 3:42 PM: - -Currently, the Dockerfiles for the nifi and nifi-toolkit images require the .tag.gz binaries for published versions. I think there was some discussion on the mailing list about this a while back, but do we have a solution for this so that we don't break our Dockerfiles?- Disregard, it looks like there was a PR to address this. See NIFI-5468 and the mailing list discussion below. was (Author: kdoran): Currently, the Dockerfiles for the nifi and nifi-toolkit images require the .tag.gz binaries for published versions. I think there was some discussion on the mailing list about this a while back, but do we have a solution for this so that we don't break our Dockerfiles? > Reduce artifact size by only building .zip archive > -- > > Key: NIFI-5402 > URL: https://issues.apache.org/jira/browse/NIFI-5402 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.7.0 >Reporter: Andy LoPresto >Assignee: Nathan Gough >Priority: Major > Labels: archive, build, format, maven, tar, zip > > The maven build bundles two identical builds (one in .tar.gz format and one > in .zip format). Based on community discussion, there is no longer a need for > separate .tar.gz, and removing this would increase the speed of the build and > greatly decrease the hosting requirements for the binaries. > That said, building a .tar.gz archive should be available through an > (inactive) profile if a user wants to enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5402) Reduce artifact size by only building .zip archive
[ https://issues.apache.org/jira/browse/NIFI-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648048#comment-16648048 ] Kevin Doran commented on NIFI-5402: --- Mailing list discussion: https://lists.apache.org/thread.html/58cc05e07d31de0c46a80b337bfda599d98b961c9f6359a4e69b6d07@%3Cdev.nifi.apache.org%3E > Reduce artifact size by only building .zip archive > -- > > Key: NIFI-5402 > URL: https://issues.apache.org/jira/browse/NIFI-5402 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.7.0 >Reporter: Andy LoPresto >Assignee: Nathan Gough >Priority: Major > Labels: archive, build, format, maven, tar, zip > > The maven build bundles two identical builds (one in .tar.gz format and one > in .zip format). Based on community discussion, there is no longer a need for > separate .tar.gz, and removing this would increase the speed of the build and > greatly decrease the hosting requirements for the binaries. > That said, building a .tar.gz archive should be available through an > (inactive) profile if a user wants to enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4811) Use a newer version of spring-data-redis
[ https://issues.apache.org/jira/browse/NIFI-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648038#comment-16648038 ] ASF GitHub Bot commented on NIFI-4811: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2856 @joewitt we should be good to go now. > Use a newer version of spring-data-redis > > > Key: NIFI-4811 > URL: https://issues.apache.org/jira/browse/NIFI-4811 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Johan Oceanstorm >Assignee: Mike Thomsen >Priority: Major > Fix For: 1.8.0 > > > NiFi uses version 1.8.3 of spring-data-redis (as you can see > [here|[https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-redis-bundle/pom.xml#L31].] > This version is an old version. The newer stable version is 2.0.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2856: NIFI-4811 Added two missing entries to the nifi-redis-serv...
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2856 @joewitt we should be good to go now. ---
[jira] [Commented] (NIFI-5402) Reduce artifact size by only building .zip archive
[ https://issues.apache.org/jira/browse/NIFI-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648034#comment-16648034 ] Kevin Doran commented on NIFI-5402: --- Currently, the Dockerfiles for the nifi and nifi-toolkit images require the .tag.gz binaries for published versions. I think there was some discussion on the mailing list about this a while back, but do we have a solution for this so that we don't break our Dockerfiles? > Reduce artifact size by only building .zip archive > -- > > Key: NIFI-5402 > URL: https://issues.apache.org/jira/browse/NIFI-5402 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.7.0 >Reporter: Andy LoPresto >Assignee: Nathan Gough >Priority: Major > Labels: archive, build, format, maven, tar, zip > > The maven build bundles two identical builds (one in .tar.gz format and one > in .zip format). Based on community discussion, there is no longer a need for > separate .tar.gz, and removing this would increase the speed of the build and > greatly decrease the hosting requirements for the binaries. > That said, building a .tar.gz archive should be available through an > (inactive) profile if a user wants to enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5448) Failed EL date parsing live-locks processors without a failure relationship
[
https://issues.apache.org/jira/browse/NIFI-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648030#comment-16648030
]
Joseph Witt commented on NIFI-5448:
---
reverting both
commit e25b26e9cf860db038da8e23e8e64bdb1b8dba88 (HEAD -> master)
Author: joewitt
Date: Fri Oct 12 11:27:48 2018 -0400
Revert "NIFI-5448 Added failure relationship to UpdateAttributes to handle
bad expression language logic."
This reverts commit 32ee552ada328ed1189ed2bd0a2af18ed213ddc8.
commit 6b77e7dd895affa739c55a7db969fa6bcde44ad1
Author: joewitt
Date: Fri Oct 12 11:08:22 2018 -0400
Revert "NIFI-5448 Changed from 'stop' to 'penalize' in allowablevalue field
to make the popup more consistent."
This reverts commit 9d2b698c1cdfb54411b9f147573767bdda6e355c.
> Failed EL date parsing live-locks processors without a failure relationship
> ---
>
> Key: NIFI-5448
> URL: https://issues.apache.org/jira/browse/NIFI-5448
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Koster
>Assignee: Mike Thomsen
>Priority: Major
> Fix For: 1.8.0
>
>
> Processors that utilize the Expression Language need to always present a
> failure relationship.
> If a processor with only a success relationship, for example UpdateAttribute,
> utilizes the expression language to perform type coercion to a date and
> fails, the processor will be unable to dispose of the FlowFile and remain
> blocked indefinitely.
> Recreation flow:
> GenerateFlowFile -> Update Attribute #1 -> Update Attribute #2 -> Anything
> Update Attribute #1 - test = "Hello World"
> Update Attribute #2 - test = ${test:toDate('-MM-dd')}
>
> Generates an IllegalAttributeException on UpdateAttribute.
>
> The behavior should match numerical type coercion and silently skip the
> processing or offer failure relationships on processors supporting EL
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (NIFI-5402) Reduce artifact size by only building .zip archive
[ https://issues.apache.org/jira/browse/NIFI-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough reassigned NIFI-5402: -- Assignee: Nathan Gough > Reduce artifact size by only building .zip archive > -- > > Key: NIFI-5402 > URL: https://issues.apache.org/jira/browse/NIFI-5402 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.7.0 >Reporter: Andy LoPresto >Assignee: Nathan Gough >Priority: Major > Labels: archive, build, format, maven, tar, zip > > The maven build bundles two identical builds (one in .tar.gz format and one > in .zip format). Based on community discussion, there is no longer a need for > separate .tar.gz, and removing this would increase the speed of the build and > greatly decrease the hosting requirements for the binaries. > That said, building a .tar.gz archive should be available through an > (inactive) profile if a user wants to enable it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5665) Upgrade io.netty dependencies
[ https://issues.apache.org/jira/browse/NIFI-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648015#comment-16648015 ] ASF GitHub Bot commented on NIFI-5665: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/3067 Will review... > Upgrade io.netty dependencies > - > > Key: NIFI-5665 > URL: https://issues.apache.org/jira/browse/NIFI-5665 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.7.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.8.0 > > > The io.netty dependencies are a few years old, and should be upgraded for the > latest features and bug fixes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
