[jira] [Commented] (NIFI-2542) Revisions for Controller Service Referencing Components
[ https://issues.apache.org/jira/browse/NIFI-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417454#comment-15417454 ] ASF GitHub Bot commented on NIFI-2542: -- GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/837 Controller Services - Addressing issues with transitive referencing components NIFI-2542: - Ensuring transitive referencing components are able to be returned. NIFI-2543: - Ensuring we have permissions before attempting to reload a controller service. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2542 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/837.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 #837 commit 17fbf55972fa81e7f5cccfd01fe833dbdc6326f7 Author: Matt Gilman Date: 2016-08-11T14:52:04Z NIFI-2542: - Ensuring transitive referencing components are able to be returned. NIFI-2543: - Ensuring we have permissions before attempting to reload a controller service. > Revisions for Controller Service Referencing Components > --- > > Key: NIFI-2542 > URL: https://issues.apache.org/jira/browse/NIFI-2542 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Critical > Fix For: 1.0.0 > > > The revisions for components that reference controller services transitively > are not available when generating the response DTOs. > Additionally, it doesn't appear that the transitive references are being > returned or rendered correctly. It is unclear which is the case due to the > issue described above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #837: Controller Services - Addressing issues with transit...
GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/837 Controller Services - Addressing issues with transitive referencing components NIFI-2542: - Ensuring transitive referencing components are able to be returned. NIFI-2543: - Ensuring we have permissions before attempting to reload a controller service. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2542 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/837.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 #837 commit 17fbf55972fa81e7f5cccfd01fe833dbdc6326f7 Author: Matt Gilman Date: 2016-08-11T14:52:04Z NIFI-2542: - Ensuring transitive referencing components are able to be returned. NIFI-2543: - Ensuring we have permissions before attempting to reload a controller service. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2380) ExtractEmailAttachments processor should support TNEF files (aka winmail.dat)
[ https://issues.apache.org/jira/browse/NIFI-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417449#comment-15417449 ] ASF GitHub Bot commented on NIFI-2380: -- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/817 @JPercivall - Given your review of ExtractEmailAttachments do you mind reviewing this PR? Cheers > ExtractEmailAttachments processor should support TNEF files (aka winmail.dat) > - > > Key: NIFI-2380 > URL: https://issues.apache.org/jira/browse/NIFI-2380 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > during the review of NIFI-1899 Dan Marshall highlighted some use cases for > email processing that have not been addressed as part of the initial > development cycle. > One of these use cases was the decoding of Microsoft Transport Neutral > Encoding Files (TNEF). > This type of attachments is popularly know as winmail.dat and uses a non RFC > compliant structure to transfer attachments across different Microsoft > Outlook clients. > Given the prevalence of outlook and the issues with winmail.dat files, it > would be nice to be able to decode TNEF as we currently do with MIME > attachments. > Permalink to Dan's comments > http://mail-archives.apache.org/mod_mbox/nifi-dev/201607.mbox/%3C1468716836729-12827.post%40n7.nabble.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2380) ExtractEmailAttachments processor should support TNEF files (aka winmail.dat)
[ https://issues.apache.org/jira/browse/NIFI-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417448#comment-15417448 ] ASF GitHub Bot commented on NIFI-2380: -- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/817 @joewitt - 3rd party test files have been replaced with new files containing only NiFi & MiNiFi logos > ExtractEmailAttachments processor should support TNEF files (aka winmail.dat) > - > > Key: NIFI-2380 > URL: https://issues.apache.org/jira/browse/NIFI-2380 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > during the review of NIFI-1899 Dan Marshall highlighted some use cases for > email processing that have not been addressed as part of the initial > development cycle. > One of these use cases was the decoding of Microsoft Transport Neutral > Encoding Files (TNEF). > This type of attachments is popularly know as winmail.dat and uses a non RFC > compliant structure to transfer attachments across different Microsoft > Outlook clients. > Given the prevalence of outlook and the issues with winmail.dat files, it > would be nice to be able to decode TNEF as we currently do with MIME > attachments. > Permalink to Dan's comments > http://mail-archives.apache.org/mod_mbox/nifi-dev/201607.mbox/%3C1468716836729-12827.post%40n7.nabble.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #817: NIFI-2380 - Introduce ExtractTNEFAttachments
Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/817 @JPercivall - Given your review of ExtractEmailAttachments do you mind reviewing this PR? Cheers --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #817: NIFI-2380 - Introduce ExtractTNEFAttachments
Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/817 @joewitt - 3rd party test files have been replaced with new files containing only NiFi & MiNiFi logos --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2552) HiveQL processors fail when Zookeeper quorum in URL
[ https://issues.apache.org/jira/browse/NIFI-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417439#comment-15417439 ] Matt Burgess commented on NIFI-2552: Proposed solution is to force the version of Curator to 2.11.0 and regression test the Hadoop and Hive processors. > HiveQL processors fail when Zookeeper quorum in URL > --- > > Key: NIFI-2552 > URL: https://issues.apache.org/jira/browse/NIFI-2552 > Project: Apache NiFi > Issue Type: Bug >Reporter: Matt Burgess >Assignee: Matt Burgess > > [~YolandaMDavis] discovered a bug in the HiveQL processors, when using a > Zookeeper quorum in the Hive JDBC URL: > java.lang.NoSuchMethodError: > org.apache.curator.utils.ZKPaths.fixForNamespace(Ljava/lang/String;Ljava/lang/String;Z)Ljava/lang/String; > at > org.apache.curator.framework.imps.NamespaceImpl.fixForNamespace(NamespaceImpl.java:104) > ~[curator-framework-2.11.0.jar:na] > at > org.apache.curator.framework.imps.CuratorFrameworkImpl.fixForNamespace(CuratorFrameworkImpl.java:594) > ~[curator-framework-2.11.0.jar:na] > at > org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:198) > ~[curator-framework-2.11.0.jar:na] > at > org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:40) > ~[curator-framework-2.11.0.jar:na] > This method is in the Apache Curator 2.11.0 JAR (and has been since 2.8.0), > but the Hive NAR's parent is the Hadoop Libraries NAR, which transitively > brings in Curator 2.6.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2552) HiveQL processors fail when Zookeeper quorum in URL
Matt Burgess created NIFI-2552: -- Summary: HiveQL processors fail when Zookeeper quorum in URL Key: NIFI-2552 URL: https://issues.apache.org/jira/browse/NIFI-2552 Project: Apache NiFi Issue Type: Bug Reporter: Matt Burgess Assignee: Matt Burgess [~YolandaMDavis] discovered a bug in the HiveQL processors, when using a Zookeeper quorum in the Hive JDBC URL: java.lang.NoSuchMethodError: org.apache.curator.utils.ZKPaths.fixForNamespace(Ljava/lang/String;Ljava/lang/String;Z)Ljava/lang/String; at org.apache.curator.framework.imps.NamespaceImpl.fixForNamespace(NamespaceImpl.java:104) ~[curator-framework-2.11.0.jar:na] at org.apache.curator.framework.imps.CuratorFrameworkImpl.fixForNamespace(CuratorFrameworkImpl.java:594) ~[curator-framework-2.11.0.jar:na] at org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:198) ~[curator-framework-2.11.0.jar:na] at org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:40) ~[curator-framework-2.11.0.jar:na] This method is in the Apache Curator 2.11.0 JAR (and has been since 2.8.0), but the Hive NAR's parent is the Hadoop Libraries NAR, which transitively brings in Curator 2.6.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #655: DataDog support added
Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/655 @Ramizjon, another great resource for learning Git is this "Explain Git with D3" page[1]. It visually and interactively explains the different commands. [1] https://onlywei.github.io/explain-git-with-d3/ --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417418#comment-15417418 ] ASF GitHub Bot commented on NIFI-2519: -- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/827 @olegz You are clearly confusing envelope (the data exchanged within an SMTP session) with header information (the data added to the body of the message after the DATA command). They don't need to match. MAIL FROM is an envelope detail it is NOT added to a message. Please refer back to this comment: https://github.com/apache/nifi/pull/827#discussion_r74362397 Note how although MAIL FROM was set to a...@aaa.com this information never makes into the resulting flowfile. The RCPT TO input makes to it but requires a multiline regex to parse it and that regex will be quite brittle as resolution will require a IPv4 / IPv6 match, variable domains and so it goes. > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/827 @olegz You are clearly confusing envelope (the data exchanged within an SMTP session) with header information (the data added to the body of the message after the DATA command). They don't need to match. MAIL FROM is an envelope detail it is NOT added to a message. Please refer back to this comment: https://github.com/apache/nifi/pull/827#discussion_r74362397 Note how although MAIL FROM was set to a...@aaa.com this information never makes into the resulting flowfile. The RCPT TO input makes to it but requires a multiline regex to parse it and that regex will be quite brittle as resolution will require a IPv4 / IPv6 match, variable domains and so it goes. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2545) Cannot tell a processor is "STOPPING", can edit, cannot restart it
[
https://issues.apache.org/jira/browse/NIFI-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Payne updated NIFI-2545:
-
Status: Patch Available (was: Open)
> Cannot tell a processor is "STOPPING", can edit, cannot restart it
> --
>
> Key: NIFI-2545
> URL: https://issues.apache.org/jira/browse/NIFI-2545
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Testing ListenSMTP processor. It has some bad behavior whereby it will not
> stop when told to. But on the UI i cannot tell that at all. So, i went to
> edit the processor config which I was able to do. Then went to start it and
> I get
> {quote}
> 7667f0c7-0156-1000-8181-5b556f8544da cannot be started because it is not
> stopped. Current state is STOPPING
> {quote}
> There should be a visual indicator of its status and we should not be able to
> edit a processor which is not stopped.
> More details on that specific case here
> https://issues.apache.org/jira/browse/NIFI-2519#
> But key is that a bad behaving processor can allow the user to do things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417410#comment-15417410 ] ASF GitHub Bot commented on NIFI-2519: -- Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/827 based on @olegz and @trixpan comments about port 25 i agree we should leave it unset. > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #833: Add String Escape Utils to Nifi Expression Language (redo)
Github user mattyb149 commented on the issue:
https://github.com/apache/nifi/pull/833
I'm seeing CheckStyle errors:
[INFO] --- maven-checkstyle-plugin:2.15:check (check-style) @
nifi-expression-language ---
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[12]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[13:1]
(blocks) LeftCurly: '{' should be on the previous line.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[15:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[17]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[19:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[21]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[23:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[27:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[29]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[31:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[33]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[35:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[37]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[39:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[41]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[43:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[47:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[49]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[51:5]
(whitespace) FileTabCharacter: Line contains a tab character.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[53]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
[WARNING]
src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/CharSequenceTranslatorEvaluator.java[54]
(regexp) RegexpSinglelineJava: Line has trailing whitespace.
Can you format this file? You can check to see if there are errors by going
to the nifi-commons/nifi-expression-language module and running "mvn clean
install -Pcontrib-check".
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/827 based on @olegz and @trixpan comments about port 25 i agree we should leave it unset. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #777: Add String Escape Utils to Nifi Expression Language
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/777 yes please :) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2545) Cannot tell a processor is "STOPPING", can edit, cannot restart it
[
https://issues.apache.org/jira/browse/NIFI-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417405#comment-15417405
]
ASF GitHub Bot commented on NIFI-2545:
--
GitHub user markap14 opened a pull request:
https://github.com/apache/nifi/pull/836
NIFI-2545: Ensure that when @OnUnscheduled and @OnStopped methods are…
… called that the active thread count takes that thread into account
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/markap14/nifi NIFI-2545
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/836.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 #836
commit d6417ef43db2e0697b35ff1c67722abcfccf66c2
Author: Mark Payne
Date: 2016-08-11T15:18:50Z
NIFI-2545: Ensure that when @OnUnscheduled and @OnStopped methods are
called that the active thread count takes that thread into account
> Cannot tell a processor is "STOPPING", can edit, cannot restart it
> --
>
> Key: NIFI-2545
> URL: https://issues.apache.org/jira/browse/NIFI-2545
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Testing ListenSMTP processor. It has some bad behavior whereby it will not
> stop when told to. But on the UI i cannot tell that at all. So, i went to
> edit the processor config which I was able to do. Then went to start it and
> I get
> {quote}
> 7667f0c7-0156-1000-8181-5b556f8544da cannot be started because it is not
> stopped. Current state is STOPPING
> {quote}
> There should be a visual indicator of its status and we should not be able to
> edit a processor which is not stopped.
> More details on that specific case here
> https://issues.apache.org/jira/browse/NIFI-2519#
> But key is that a bad behaving processor can allow the user to do things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #655: DataDog support added
Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/655 No problem, happy to help get it right and learn. When you do "git status" on the master branch it will tel you "you are X number of commits ahead of origin/master and Y number of commits behind origin/master" (may be other way around, did it from memory). This just means that you start differing from what origin/master has X commits ago and there are Y more commits beyond that point in origin/master. So you will do "git reset HEAD~X" where X is the number of commits you are ahead. This will bring you back to a common point with origin/master but leave the changes that were made as unstaged/uncommitted changes. After performing the steps you should be at a point where it says (when running "git status") "you are 1 commit ahead of master". This 1 commit should have all the changes you made for the Datadog implementation (and only those changes). The "reflog" is a history of all the git commands you do. So if you get too mixed up, you can use reflog to rewind back to a certain command (ie. before you started everything). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #836: NIFI-2545: Ensure that when @OnUnscheduled and @OnSt...
GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/836 NIFI-2545: Ensure that when @OnUnscheduled and @OnStopped methods are⦠⦠called that the active thread count takes that thread into account You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-2545 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/836.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 #836 commit d6417ef43db2e0697b35ff1c67722abcfccf66c2 Author: Mark Payne Date: 2016-08-11T15:18:50Z NIFI-2545: Ensure that when @OnUnscheduled and @OnStopped methods are called that the active thread count takes that thread into account --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (NIFI-2551) Rare condition causes FileSystemRepository NPE
[
https://issues.apache.org/jira/browse/NIFI-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Moser reassigned NIFI-2551:
---
Assignee: Michael Moser
> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:919)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
>
> Suppressed: java.lang.NullPointerException
> at
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:935)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (NIFI-2551) Rare condition causes FileSystemRepository NPE
[
https://issues.apache.org/jira/browse/NIFI-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417383#comment-15417383
]
Michael Moser edited comment on NIFI-2551 at 8/11/16 3:07 PM:
--
Applying debug logging shows this is happening:
[Thread-1] StandardProcessSession.write() calls FileSystemRepository.create()
and reuses claim #100
[Thread-2] StandardProcessSession.removeTemporaryClaim() calls
FileSystemRepository.decrementClaimantCount() then calls
FileSystemRepository.remove() on claim #100
[Thread-1] StandardProcessSession.write() calls FileSystemRepository.write() to
claim #100, gets an error, and the try-with-resources block closes the
OutputStream which gets an NPE.
was (Author: mosermw):
Applying debug logging shows this is happening:
[Thread-1] StandardProcessSession.write() calls FileSystemRepository.create()
and reuses claim #100
[Thread-2] StandardProcessSession.removeTemporaryClaim() calls
FileSystemRepository.decrementClaimantCount() then calls FileSystemRe
pository.remove() on claim #100
[Thread-1] StandardProcessSession.write() calls FileSystemRepository.write() to
claim #100, gets an error, and the try-with-resources block closes the
OutputStream which gets an NPE.
> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:919)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
>
> Suppressed: java.lang.NullPointerException
> at
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:935)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #655: DataDog support added
Github user Ramizjon commented on the issue: https://github.com/apache/nifi/pull/655 @JPercivall Thank you for you answer. Just a few moments to clarify: > 2: do a soft reset far enough back that you can later fast-forward to the latest apache master commit Should i soft reset to my very first commit, by specifying it's hash? And after performing all the steps you've described, should i do some extra steps for squashing or that will be enough? Sorry, i am not very confident with extra git features, that's why i want to clarify all to do everything right. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2551) Rare condition causes FileSystemRepository NPE
[
https://issues.apache.org/jira/browse/NIFI-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417386#comment-15417386
]
Michael Moser commented on NIFI-2551:
-
I have a patch that provides extra synchronization in the FileSystemRepository
public methods incrementClaimantCount(), getClaimantCount(), and
decrementClaimantCount(). This helps synchronize the state of the claim counts
in resourceClaimManager and the ResourceClaims stored in writableClaimQueue.
This patch did fix the problem on a NiFi system that actually saw this NPE
regularly.
But now I'm thinking perhaps more needs to be done in
StandardProcessSession.removeTemporaryClaim() and destroyContent() to operate
on the FileSystemRepository more atmoically.
> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:919)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
>
> Suppressed: java.lang.NullPointerException
> at
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:935)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2551) Rare condition causes FileSystemRepository NPE
[
https://issues.apache.org/jira/browse/NIFI-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417383#comment-15417383
]
Michael Moser commented on NIFI-2551:
-
Applying debug logging shows this is happening:
[Thread-1] StandardProcessSession.write() calls FileSystemRepository.create()
and reuses claim #100
[Thread-2] StandardProcessSession.removeTemporaryClaim() calls
FileSystemRepository.decrementClaimantCount() then calls FileSystemRe
pository.remove() on claim #100
[Thread-1] StandardProcessSession.write() calls FileSystemRepository.write() to
claim #100, gets an error, and the try-with-resources block closes the
OutputStream which gets an NPE.
> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:919)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
>
> Suppressed: java.lang.NullPointerException
> at
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:935)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (NIFI-2551) Rare condition causes FileSystemRepository NPE
[
https://issues.apache.org/jira/browse/NIFI-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417386#comment-15417386
]
Michael Moser edited comment on NIFI-2551 at 8/11/16 3:07 PM:
--
I have a patch that provides extra synchronization in the FileSystemRepository
public methods incrementClaimantCount(), getClaimantCount(), and
decrementClaimantCount(). This helps synchronize the state of the claim counts
in resourceClaimManager and the ResourceClaims stored in writableClaimQueue.
This patch did fix the problem on a NiFi system that actually saw this NPE
regularly.
But now I'm thinking perhaps more needs to be done in
StandardProcessSession.removeTemporaryClaim() and destroyContent() to operate
on the FileSystemRepository more atomically.
was (Author: mosermw):
I have a patch that provides extra synchronization in the FileSystemRepository
public methods incrementClaimantCount(), getClaimantCount(), and
decrementClaimantCount(). This helps synchronize the state of the claim counts
in resourceClaimManager and the ResourceClaims stored in writableClaimQueue.
This patch did fix the problem on a NiFi system that actually saw this NPE
regularly.
But now I'm thinking perhaps more needs to be done in
StandardProcessSession.removeTemporaryClaim() and destroyContent() to operate
on the FileSystemRepository more atmoically.
> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:919)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
>
> Suppressed: java.lang.NullPointerException
> at
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:935)
> [nifi-framework-core-0.7.0.jar]
> at
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (NIFI-2551) Rare condition causes FileSystemRepository NPE
Michael Moser created NIFI-2551:
---
Summary: Rare condition causes FileSystemRepository NPE
Key: NIFI-2551
URL: https://issues.apache.org/jira/browse/NIFI-2551
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework
Affects Versions: 0.7.0, 1.0.0
Reporter: Michael Moser
Priority: Blocker
In rare unpredictable cases when NiFi is processing a heavy load, we see
FileSystemRepository throw a NullPointerException
{noformat}
java.lang.NullPointerException
at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:919)
[nifi-framework-core-0.7.0.jar]
at
o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
Suppressed: java.lang.NullPointerException
at
o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:935)
[nifi-framework-core-0.7.0.jar]
at
o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #655: DataDog support added
Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/655 @Ramizjon don't need to create a whole repo. You can probably achieve it this way (first do "git fetch --all" to make sure you're up to date): 1: branch off of your master branch (the one with the Datadog changes) to a new branch 2: do a soft reset far enough back that you can later fast-forward to the latest apache master commit 3: commit just the changes you want to make (may need to do a "git reset HEAD --hard" after committing your changes to get rid of any random changes you don't want to commit) 4: do "git rebase origin/master". This should fast forward your Datadog commit ahead of the latest of the master branch. Also you may want to check out this documentation on how to re-write history in Git[1]. If you get too messed up you can always use "reflog" to rewind. Let me know if you have any questions. Also I didn't realize I needed to explicitly create a dashboard, I thought it would at least show a notification that I connected (especially when using HTTP). I will re-test once we get everything squashed. [1] https://www.atlassian.com/git/tutorials/rewriting-history --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2544) Create integration tests for Zero-Master Clustering
[ https://issues.apache.org/jira/browse/NIFI-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417353#comment-15417353 ] ASF subversion and git services commented on NIFI-2544: --- Commit 76a4a2c48b154719c3ea750b14d568f9998069ba in nifi's branch refs/heads/master from [~markap14] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=76a4a2c ] NIFI-2544: Created integration tests for clustering and addressed a few minor bugs that were found in doing so This closes #832. Signed-off-by: Bryan Bende > Create integration tests for Zero-Master Clustering > --- > > Key: NIFI-2544 > URL: https://issues.apache.org/jira/browse/NIFI-2544 > Project: Apache NiFi > Issue Type: Task > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > With the new Zero-Master Clustering, we have been testing a lot using manual > testing, but we should have automated integration tests, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2544) Create integration tests for Zero-Master Clustering
[ https://issues.apache.org/jira/browse/NIFI-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417354#comment-15417354 ] ASF GitHub Bot commented on NIFI-2544: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/832 > Create integration tests for Zero-Master Clustering > --- > > Key: NIFI-2544 > URL: https://issues.apache.org/jira/browse/NIFI-2544 > Project: Apache NiFi > Issue Type: Task > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > With the new Zero-Master Clustering, we have been testing a lot using manual > testing, but we should have automated integration tests, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2535) SSL context service property in Publish/ConsumeKafka is causing clustering issue
[
https://issues.apache.org/jira/browse/NIFI-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Bende updated NIFI-2535:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> SSL context service property in Publish/ConsumeKafka is causing clustering
> issue
> -
>
> Key: NIFI-2535
> URL: https://issues.apache.org/jira/browse/NIFI-2535
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Haimo Liu
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.0.0
>
>
> NIFI build Aug.9th
> I have a flow with the new kafka processors (publish, consume). it seems like
> the newly added SSL context service property is causing clustering issue (one
> of the nodes cannot join cluster), logs below (tried to copy the flow.xml.gz
> file from node 1 to the other nodes so that they are completely identical,
> doesn't fix the issue):
> 2016-08-09 16:52:38,893 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator Resetting cluster node statuses from
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=8],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=4]} to
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=30],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Primary Node],
> updateId=32]}
> 2016-08-09 16:52:40,071 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.UninheritableFlowException: Failed to
> connect node to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:863)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:589)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.access$300(StandardFlowService.java:97)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService$2.run(StandardFlowService.java:401)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEssl.context.serviceNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.pr
> Cluster Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.processors.standard.GenerateF
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:240)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1429)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:81)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:668)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:839)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> ... 4 common frames omitted
> 2016-08-09 16:52:40,071 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator localhost:8891 requested disconnection
> from cluster due to org.apache.nifi.controller.UninheritableFlowException:
> Failed to connect node to cluster because local flow is different than
> cluster flow.
> 2016-08-09 16:52:40,071 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator Status of localhost:8891 changed from
> NodeConnectionStatus[state=CONNEC
[jira] [Resolved] (NIFI-2544) Create integration tests for Zero-Master Clustering
[ https://issues.apache.org/jira/browse/NIFI-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende resolved NIFI-2544. --- Resolution: Fixed > Create integration tests for Zero-Master Clustering > --- > > Key: NIFI-2544 > URL: https://issues.apache.org/jira/browse/NIFI-2544 > Project: Apache NiFi > Issue Type: Task > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > With the new Zero-Master Clustering, we have been testing a lot using manual > testing, but we should have automated integration tests, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2535) SSL context service property in Publish/ConsumeKafka is causing clustering issue
[
https://issues.apache.org/jira/browse/NIFI-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417359#comment-15417359
]
ASF GitHub Bot commented on NIFI-2535:
--
Github user asfgit closed the pull request at:
https://github.com/apache/nifi/pull/829
> SSL context service property in Publish/ConsumeKafka is causing clustering
> issue
> -
>
> Key: NIFI-2535
> URL: https://issues.apache.org/jira/browse/NIFI-2535
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Haimo Liu
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.0.0
>
>
> NIFI build Aug.9th
> I have a flow with the new kafka processors (publish, consume). it seems like
> the newly added SSL context service property is causing clustering issue (one
> of the nodes cannot join cluster), logs below (tried to copy the flow.xml.gz
> file from node 1 to the other nodes so that they are completely identical,
> doesn't fix the issue):
> 2016-08-09 16:52:38,893 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator Resetting cluster node statuses from
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=8],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=4]} to
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=30],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Primary Node],
> updateId=32]}
> 2016-08-09 16:52:40,071 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.UninheritableFlowException: Failed to
> connect node to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:863)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:589)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.access$300(StandardFlowService.java:97)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService$2.run(StandardFlowService.java:401)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEssl.context.serviceNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.pr
> Cluster Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.processors.standard.GenerateF
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:240)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1429)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:81)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:668)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:839)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> ... 4 common frames omitted
> 2016-08-09 16:52:40,071 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator localhost:8891 requested disconnection
> from cluster due to org.apache.nifi.controller.UninheritableFlowException:
> Failed to connect node to cluster because local flow is different than
> cluster flow.
> 2016-08-09 16:52:40,071 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeCluster
[jira] [Commented] (NIFI-2535) SSL context service property in Publish/ConsumeKafka is causing clustering issue
[
https://issues.apache.org/jira/browse/NIFI-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417357#comment-15417357
]
ASF subversion and git services commented on NIFI-2535:
---
Commit 25a2fac453f1a39db9d1f7f759a4fdca80269eca in nifi's branch
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=25a2fac ]
NIFI-2535: Do not include properties that are unset in flow fingerprint. This
allows a new property to be added to a processor without affecting the
fingerprint, if the value is never set
This closes #829.
Signed-off-by: Bryan Bende
> SSL context service property in Publish/ConsumeKafka is causing clustering
> issue
> -
>
> Key: NIFI-2535
> URL: https://issues.apache.org/jira/browse/NIFI-2535
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Haimo Liu
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.0.0
>
>
> NIFI build Aug.9th
> I have a flow with the new kafka processors (publish, consume). it seems like
> the newly added SSL context service property is causing clustering issue (one
> of the nodes cannot join cluster), logs below (tried to copy the flow.xml.gz
> file from node 1 to the other nodes so that they are completely identical,
> doesn't fix the issue):
> 2016-08-09 16:52:38,893 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator Resetting cluster node statuses from
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=8],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=4]} to
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=30],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Primary Node],
> updateId=32]}
> 2016-08-09 16:52:40,071 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.UninheritableFlowException: Failed to
> connect node to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:863)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:589)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.access$300(StandardFlowService.java:97)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService$2.run(StandardFlowService.java:401)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEssl.context.serviceNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.pr
> Cluster Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.processors.standard.GenerateF
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:240)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1429)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:81)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:668)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:839)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> ... 4 common frames omitted
> 2016-08-09 16:52:40,071 INFO [Reconne
[GitHub] nifi pull request #829: NIFI-2535: Do not include properties that are unset ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/829 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #832: NIFI-2544: Created integration tests for clustering ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/832 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2544) Create integration tests for Zero-Master Clustering
[ https://issues.apache.org/jira/browse/NIFI-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417349#comment-15417349 ] ASF GitHub Bot commented on NIFI-2544: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/832 This PR appears to have fixed an issue I was seeing while testing PR 829. Full build passed with contrib-check, ran the IT test which passed, and setup a three node cluster with no issues, so I'm a +1. > Create integration tests for Zero-Master Clustering > --- > > Key: NIFI-2544 > URL: https://issues.apache.org/jira/browse/NIFI-2544 > Project: Apache NiFi > Issue Type: Task > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > With the new Zero-Master Clustering, we have been testing a lot using manual > testing, but we should have automated integration tests, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #832: NIFI-2544: Created integration tests for clustering and add...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/832 This PR appears to have fixed an issue I was seeing while testing PR 829. Full build passed with contrib-check, ran the IT test which passed, and setup a three node cluster with no issues, so I'm a +1. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2535) SSL context service property in Publish/ConsumeKafka is causing clustering issue
[
https://issues.apache.org/jira/browse/NIFI-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417345#comment-15417345
]
ASF GitHub Bot commented on NIFI-2535:
--
Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/829
I've been testing this with PR 832, which has a few minor clustering fixes,
and together everything has been working well. I have repeatedly taken an old
flow.xml that previously produced an uninheritable error in a cluster and can
no longer produce that error with these two PRs applied. So I'm a +1 for both
PRs to be merged to master.
> SSL context service property in Publish/ConsumeKafka is causing clustering
> issue
> -
>
> Key: NIFI-2535
> URL: https://issues.apache.org/jira/browse/NIFI-2535
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Haimo Liu
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.0.0
>
>
> NIFI build Aug.9th
> I have a flow with the new kafka processors (publish, consume). it seems like
> the newly added SSL context service property is causing clustering issue (one
> of the nodes cannot join cluster), logs below (tried to copy the flow.xml.gz
> file from node 1 to the other nodes so that they are completely identical,
> doesn't fix the issue):
> 2016-08-09 16:52:38,893 INFO [Reconnect to Cluster]
> o.a.n.c.c.node.NodeClusterCoordinator Resetting cluster node statuses from
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=8],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=4]} to
> {localhost:8893=NodeConnectionStatus[state=CONNECTED, roles=[Cluster
> Coordinator], updateId=30],
> localhost:8891=NodeConnectionStatus[state=CONNECTING, roles=[], updateId=33],
> localhost:8892=NodeConnectionStatus[state=CONNECTED, roles=[Primary Node],
> updateId=32]}
> 2016-08-09 16:52:40,071 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.UninheritableFlowException: Failed to
> connect node to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:863)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:589)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.access$300(StandardFlowService.java:97)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService$2.run(StandardFlowService.java:401)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEssl.context.serviceNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.pr
> Cluster Fingerprint:
> he.nifi.processors.kafka.pubsub.Partitioners$RoundRobinPartitionersasl.kerberos.service.nameNO_VALUEtopicWARNINGsuccess04015ca0-0156-1000--4224fe88org.apache.nifi.processors.standard.GenerateF
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:240)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1429)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:81)
> ~[nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:668)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:839)
> [nifi-framework-core-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> ... 4 common frames omitted
> 2016-08-09 16:52:40,071 INFO [Reconnect
[GitHub] nifi issue #829: NIFI-2535: Do not include properties that are unset in flow...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/829 I've been testing this with PR 832, which has a few minor clustering fixes, and together everything has been working well. I have repeatedly taken an old flow.xml that previously produced an uninheritable error in a cluster and can no longer produce that error with these two PRs applied. So I'm a +1 for both PRs to be merged to master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2543) UI - Refresh Controller Service Referenced Services
[ https://issues.apache.org/jira/browse/NIFI-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2543: -- Description: After updating a Controller Service, we attempt to refresh all components that reference it and services it references. It appears the UI is attempting to reload referenced services regardless of permissions. This needs to be done selectively or it generates an Unauthorized error message that is confusing as it appears the update failed. (was: After updating a Controller Service, we attempt to refresh all components that reference it. It appears that the UI is attempting to refresh a referencing component that the user does not have access to. This is resulting in a confusing error message to the user as it appears the save was unsuccessful. The updating should be done more selectively or through an endpoint that returns the services in a filtered form (like listing all services).) > UI - Refresh Controller Service Referenced Services > --- > > Key: NIFI-2543 > URL: https://issues.apache.org/jira/browse/NIFI-2543 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Critical > Fix For: 1.0.0 > > > After updating a Controller Service, we attempt to refresh all components > that reference it and services it references. It appears the UI is attempting > to reload referenced services regardless of permissions. This needs to be > done selectively or it generates an Unauthorized error message that is > confusing as it appears the update failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #655: DataDog support added
Github user Ramizjon commented on the issue: https://github.com/apache/nifi/pull/655 @JPercivall Trying to squash all commits seems to be unsuccessful, as it causes squashing upstream commits as well and generally is painful. Probably i'll create new repo with current state of the working copy and open new PR from there with only one commit? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2543) UI - Refresh Controller Service Referenced Services
[ https://issues.apache.org/jira/browse/NIFI-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2543: -- Summary: UI - Refresh Controller Service Referenced Services (was: UI - Refresh Controller Service Referencing Components) > UI - Refresh Controller Service Referenced Services > --- > > Key: NIFI-2543 > URL: https://issues.apache.org/jira/browse/NIFI-2543 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Critical > Fix For: 1.0.0 > > > After updating a Controller Service, we attempt to refresh all components > that reference it. It appears that the UI is attempting to refresh a > referencing component that the user does not have access to. This is > resulting in a confusing error message to the user as it appears the save was > unsuccessful. > The updating should be done more selectively or through an endpoint that > returns the services in a filtered form (like listing all services). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2477) Document tls-toolkit
[ https://issues.apache.org/jira/browse/NIFI-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Lim updated NIFI-2477: - Fix Version/s: 1.0.0 > Document tls-toolkit > > > Key: NIFI-2477 > URL: https://issues.apache.org/jira/browse/NIFI-2477 > Project: Apache NiFi > Issue Type: Task >Reporter: Bryan Rosander >Assignee: Andrew Lim > Fix For: 1.0.0 > > > tls-toolkit created as part of NIFI-2193 needs to be documented in order to > be a useful utility to ease the burden of configuring tls for one or more > NiFi instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2449) Need to document Variable Registry work in 1.0
[ https://issues.apache.org/jira/browse/NIFI-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417296#comment-15417296 ] Andrew Lim commented on NIFI-2449: -- First draft of content to add to Getting Started guide after “Working with Attributes” section: Custom Properties within Expression Language In addition to using FlowFile attributes, you can also define custom properties for Expression Language use. Defining custom properties gives you additional flexibility in processing and configuring dataflows. For example, you can refer to custom properties for connection, server, and service properties. When you define custom properties, ensure that the following criteria are met: -Each custom property contains a distinct property value, so that it is not overridden by existing environment properties, system properties, or FlowFile attributes. -Each node in a clustered environment is configured with the same custom properties. Once you have created custom properties, you can identify their location in the nifi.variable.registry.properties field in the nifi.properties file. After you have updated the nifi.properties file and restarted NiFi, you are able to use custom properties as needed. > Need to document Variable Registry work in 1.0 > -- > > Key: NIFI-2449 > URL: https://issues.apache.org/jira/browse/NIFI-2449 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Affects Versions: 1.0.0 >Reporter: Andrew Lim >Assignee: Andrew Lim > Fix For: 1.0.0 > > > Need to capture work done in NIFI-2208. Admin and Getting Started guides > should be updated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74423248 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- @olegz I see where you come from but put file is controlled by the DFM, ListenSMTP is an exposed service True, we don't do it everywhere but it is present on GetFile as well as other processors crossing administrative domains (DFM <> FS) and so it goes --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417274#comment-15417274
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74425136
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
If you are intending to speak SMTP tgan you need to follow the relevant
RFC, this means a connecting MTA should be actively informed of a time out
otherwise it will indefinitely hang connected as you do not return a 4XX code
nor an ok, instead we just leave the connection for dead. This means all
clients will have to wait for their own timeouts before disconnecting
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<<
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed:
> 0.038 sec <<< FAILURE!
> j
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417290#comment-15417290
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74427203
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
Agree with that.
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<<
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed:
> 0.038 sec <<< FAILURE!
> java.lang.AssertionError: Sending email failed
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at
> org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188)
> Running org.apache.nifi.processors.email.TestExtrac
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74427203
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
Agree with that.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74425136
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
If you are intending to speak SMTP tgan you need to follow the relevant
RFC, this means a connecting MTA should be actively informed of a time out
otherwise it will indefinitely hang connected as you do not return a 4XX code
nor an ok, instead we just leave the connection for dead. This means all
clients will have to wait for their own timeouts before disconnecting
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417282#comment-15417282 ] ASF GitHub Bot commented on NIFI-2519: -- Github user olegz commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74425869 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- We can definitely look at this as an improvement in the future > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417280#comment-15417280
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74425691
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
I have no intention to speak SMTP. I am relying on the underlying API to do
that and if it's inadequate, then let's look for a better API.
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<<
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed:
> 0.038 sec <<< FAILURE!
> java.lang.AssertionError: Sending email failed
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at
> org.apache.nifi.p
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user olegz commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74425869 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- We can definitely look at this as an improvement in the future --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74425691
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
I have no intention to speak SMTP. I am relying on the underlying API to do
that and if it's inadequate, then let's look for a better API.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2526) Fix DN order, allow multiple standalone runs, standalone generate client certificates,
[ https://issues.apache.org/jira/browse/NIFI-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417267#comment-15417267 ] ASF GitHub Bot commented on NIFI-2526: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/824 This looks good to me. I am able to build cleanly on a JDK without the unlimited crypto, and I can run the toolkit to generate certs, listing the contents of the client p12 and the keystore/truststore JKS now shows the DN with the CN before the OU. > Fix DN order, allow multiple standalone runs, standalone generate client > certificates, > --- > > Key: NIFI-2526 > URL: https://issues.apache.org/jira/browse/NIFI-2526 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > NiFi authorization framework currently expects OU to come before CN, the tool > should reflect that by default. > Standalone tool would be much more useful if you could keep running and > refining in the same directory with the same CA certificate. > Standalone tool would be much more useful if it could also generate client > certificates. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #824: NIFI-2526 - DN order, multiple standalone runs, client cert...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/824 This looks good to me. I am able to build cleanly on a JDK without the unlimited crypto, and I can run the toolkit to generate certs, listing the contents of the client p12 and the keystore/truststore JKS now shows the DN with the CN before the OU. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417259#comment-15417259 ] ASF GitHub Bot commented on NIFI-2519: -- Github user trixpan commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74423248 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- @olegz I see where you come from but put file is controlled by the DFM, ListenSMTP is an exposed service True, we don't do it everywhere but it is present on GetFile as well as other processors crossing administrative domains (DFM <> FS) and so it goes > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417247#comment-15417247
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74422525
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
I am not sure hat you're saying. If Subethasmtp is inadequate API, then we
have to scrap it and use something different. But once again, let's keep in
mind that the job of this processor is to simply open up a socket with attached
application layer capable of speaking SMTP. That is all. For anything else use
commercial server and attache to it via available mail protocols.
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<<
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed:
> 0.038 sec <<< FAILURE
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74422525
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
I am not sure hat you're saying. If Subethasmtp is inadequate API, then we
have to scrap it and use something different. But once again, let's keep in
mind that the job of this processor is to simply open up a socket with attached
application layer capable of speaking SMTP. That is all. For anything else use
commercial server and attache to it via available mail protocols.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417238#comment-15417238 ] ASF GitHub Bot commented on NIFI-2519: -- Github user olegz commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74421827 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- Yes it goes straight to disc via the Function that is passed to the SmtpConsumer. As far as enforcing data size we can address it in the future if that is a problem. For example we don't have the same enforcement in PutFile and other processors unless memory is involved which in this case it isn't. Also, in all honesty I can't see someone using ListenSMTP or email in general to send large data or to move data. There are better more suitable protocols for it. > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user olegz commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74421827 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- Yes it goes straight to disc via the Function that is passed to the SmtpConsumer. As far as enforcing data size we can address it in the future if that is a problem. For example we don't have the same enforcement in PutFile and other processors unless memory is involved which in this case it isn't. Also, in all honesty I can't see someone using ListenSMTP or email in general to send large data or to move data. There are better more suitable protocols for it. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417235#comment-15417235
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74421721
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
It will cause clients to hang around indefinitely
Subethasmtp is a weird API. I don't truly understand the reason why it was
coded like that but it transfers good chunks of the smtp conversation to the
developer making use of it.
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<<
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed:
> 0.038 sec <<< FAILURE!
> java.lang.AssertionError: Sending email failed
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74421721
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
It will cause clients to hang around indefinitely
Subethasmtp is a weird API. I don't truly understand the reason why it was
coded like that but it transfers good chunks of the smtp conversation to the
developer making use of it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417221#comment-15417221 ] ASF GitHub Bot commented on NIFI-2519: -- Github user trixpan commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74420800 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- I imagine you write straight to disk? If so we should enforce this somehow. It would be sort of concerning to have a client filling up your disk with a single message? > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74420800 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- I imagine you write straight to disk? If so we should enforce this somehow. It would be sort of concerning to have a client filling up your disk with a single message? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417199#comment-15417199
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74418537
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
Same as above. The property is simply propagated to the underlying API
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<<
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed:
> 0.038 sec <<< FAILURE!
> java.lang.AssertionError: Sending email failed
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at
> org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188)
>
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74418537
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
Same as above. The property is simply propagated to the underlying API
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417198#comment-15417198
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74418332
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
Is SMTP_TIMEOUT being enforced at the DATA stage?
The server seems to hang around the data stage with the connection open no
matter how long the client idles for.
Typing . and quit do not work
```
$ time telnet 0 2525
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 localhost ESMTP Apache NiFi
helo .
250 localhost
mail from: x
250 Ok
rcpt to: a
250 Ok
data
354 End data with .
H
.
^]
telnet> quit
Connection closed.
real1m24.348s
user0m0.000s
sys 0m0.002s
```
> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While running a full NiFi parallel build received the following. So there is
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
> [deprecation] stop() in Thread has been deprecated
> [WARNING]
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
> [deprecation] stop() in Thread has been deprecated
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @
> nifi-email-processors ---
> [INFO] Surefire report directory:
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
> T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Te
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74418332
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -106,26 +69,17 @@
.addValidator(StandardValidators.PORT_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_HOSTNAME = new
PropertyDescriptor.Builder()
-.name("SMTP_HOSTNAME")
-.displayName("SMTP hostname")
-.description("The hostname to be embedded into the banner
displayed when an " +
-"SMTP client connects to the processor TCP port .")
-.required(true)
-.expressionLanguageSupported(false)
-.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
-.build();
-
-protected static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS =
new PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_MAXIMUM_CONNECTIONS = new
PropertyDescriptor.Builder()
.name("SMTP_MAXIMUM_CONNECTIONS")
.displayName("Maximum number of SMTP connection")
.description("The maximum number of simultaneous SMTP
connections.")
.required(true)
+.defaultValue("1")
.expressionLanguageSupported(false)
.addValidator(StandardValidators.INTEGER_VALIDATOR)
.build();
-protected static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor SMTP_TIMEOUT = new
PropertyDescriptor.Builder()
--- End diff --
Is SMTP_TIMEOUT being enforced at the DATA stage?
The server seems to hang around the data stage with the connection open no
matter how long the client idles for.
Typing . and quit do not work
```
$ time telnet 0 2525
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 localhost ESMTP Apache NiFi
helo .
250 localhost
mail from: x
250 Ok
rcpt to: a
250 Ok
data
354 End data with .
H
.
^]
telnet> quit
Connection closed.
real1m24.348s
user0m0.000s
sys 0m0.002s
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Assigned] (NIFI-2545) Cannot tell a processor is "STOPPING", can edit, cannot restart it
[
https://issues.apache.org/jira/browse/NIFI-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Payne reassigned NIFI-2545:
Assignee: Mark Payne
> Cannot tell a processor is "STOPPING", can edit, cannot restart it
> --
>
> Key: NIFI-2545
> URL: https://issues.apache.org/jira/browse/NIFI-2545
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Testing ListenSMTP processor. It has some bad behavior whereby it will not
> stop when told to. But on the UI i cannot tell that at all. So, i went to
> edit the processor config which I was able to do. Then went to start it and
> I get
> {quote}
> 7667f0c7-0156-1000-8181-5b556f8544da cannot be started because it is not
> stopped. Current state is STOPPING
> {quote}
> There should be a visual indicator of its status and we should not be able to
> edit a processor which is not stopped.
> More details on that specific case here
> https://issues.apache.org/jira/browse/NIFI-2519#
> But key is that a bad behaving processor can allow the user to do things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2545) Cannot tell a processor is "STOPPING", can edit, cannot restart it
[
https://issues.apache.org/jira/browse/NIFI-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417180#comment-15417180
]
Mark Payne commented on NIFI-2545:
--
Yes - I believe all that you said here is accurate.
> Cannot tell a processor is "STOPPING", can edit, cannot restart it
> --
>
> Key: NIFI-2545
> URL: https://issues.apache.org/jira/browse/NIFI-2545
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Testing ListenSMTP processor. It has some bad behavior whereby it will not
> stop when told to. But on the UI i cannot tell that at all. So, i went to
> edit the processor config which I was able to do. Then went to start it and
> I get
> {quote}
> 7667f0c7-0156-1000-8181-5b556f8544da cannot be started because it is not
> stopped. Current state is STOPPING
> {quote}
> There should be a visual indicator of its status and we should not be able to
> edit a processor which is not stopped.
> More details on that specific case here
> https://issues.apache.org/jira/browse/NIFI-2519#
> But key is that a bad behaving processor can allow the user to do things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417177#comment-15417177 ] ASF GitHub Bot commented on NIFI-2519: -- Github user olegz commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74417054 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- I was just propagating property value to it's corresponding property in SMTPServer, so IMO if server doesn't care why should we? Note that with the refactoring we never write a message into memory so even if you try to send TB it will be successful. If on the other hand we are to provide some type of enforcement on the NiFi side , then we should completely disassociate this property from SMTPServer or have some other property to eliminate the confusion. > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user olegz commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74417054 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- I was just propagating property value to it's corresponding property in SMTPServer, so IMO if server doesn't care why should we? Note that with the refactoring we never write a message into memory so even if you try to send TB it will be successful. If on the other hand we are to provide some type of enforcement on the NiFi side , then we should completely disassociate this property from SMTPServer or have some other property to eliminate the confusion. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[ https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417168#comment-15417168 ] ASF GitHub Bot commented on NIFI-2519: -- Github user trixpan commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74416389 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- Is SMTP_MAXIMUM_SIZE being enforced? I've set it to 512 B and ended up with a message of 1KB? Note that setMaxMessageSize has no effective role in dropping messages, instead all it does is to configure the EHLO response: ``` $ telnet 0 2525 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. 220 localhost ESMTP Apache NiFi EHLO . 250-localhost 250-8BITMIME 250-SIZE 512 250 Ok ``` > TestListenSMTP ValidEmail fails during parallel build > - > > Key: NIFI-2519 > URL: https://issues.apache.org/jira/browse/NIFI-2519 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Joseph Witt >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > While running a full NiFi parallel build received the following. So there is > some test issue at least that is impacting build stability. > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 4 source files to > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24] > [deprecation] stop() in Thread has been deprecated > [WARNING] > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24] > [deprecation] stop() in Thread has been deprecated > [INFO] > [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ > nifi-email-processors --- > [INFO] Changes detected - recompiling the module! > [INFO] Nothing to compile - all classes are up to date > [INFO] > [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ > nifi-email-processors --- > [INFO] Surefire report directory: > /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports > [INFO] Using configured provider > org.apache.maven.surefire.junit4.JUnit4Provider > --- > T E S T S > --- > Running org.apache.nifi.processors.email.TestListenSMTP > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< > FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP > ValidEmail(org.apache.nifi.processors.email.TestListenSMTP) Time elapsed: > 0.038 sec <<< FAILURE! > java.lang.AssertionError: Sending email failed > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at > org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188) > Running org.apache.nifi.processors.email.TestExtractEmailAttachments > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in > org.apache.nifi.processors.email.TestExtractEmailAttachments > Running org.apache.nifi.processors.email.TestExtractEmailHeaders > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - > in org.apache.nifi.processors.email.TestExtractEmailHeaders > Results : > Failed tests: > TestListenSMTP.ValidEmail:188 Sending email failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request: https://github.com/apache/nifi/pull/827#discussion_r74416389 --- Diff: nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java --- @@ -135,29 +89,17 @@ .addValidator(StandardValidators.TIME_PERIOD_VALIDATOR) .build(); -protected static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() +static final PropertyDescriptor SMTP_MAXIMUM_MSG_SIZE = new PropertyDescriptor.Builder() --- End diff -- Is SMTP_MAXIMUM_SIZE being enforced? I've set it to 512 B and ended up with a message of 1KB? Note that setMaxMessageSize has no effective role in dropping messages, instead all it does is to configure the EHLO response: ``` $ telnet 0 2525 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. 220 localhost ESMTP Apache NiFi EHLO . 250-localhost 250-8BITMIME 250-SIZE 512 250 Ok ``` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417151#comment-15417151
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74414544
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -166,317 +108,158 @@
.identifiesControllerService(SSLContextService.class)
.build();
-public static final PropertyDescriptor CLIENT_AUTH = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor CLIENT_AUTH = new
PropertyDescriptor.Builder()
.name("CLIENT_AUTH")
.displayName("Client Auth")
.description("The client authentication policy to use for the
SSL Context. Only used if an SSL Context Service is provided.")
.required(false)
.allowableValues(SSLContextService.ClientAuth.NONE.toString(),
SSLContextService.ClientAuth.REQUIRED.toString())
.build();
-@Override
-protected Collection customValidate(final
ValidationContext validationContext) {
-final List results = new ArrayList<>();
+static final Relationship REL_SUCCESS = new Relationship.Builder()
+.name("success")
+.description("All new messages will be routed as FlowFiles to
this relationship")
+.build();
-final String clientAuth =
validationContext.getProperty(CLIENT_AUTH).getValue();
-final SSLContextService sslContextService =
validationContext.getProperty(SSL_CONTEXT_SERVICE).asControllerService(SSLContextService.class);
+private final static List propertyDescriptors;
-if (sslContextService != null && StringUtils.isBlank(clientAuth)) {
-results.add(new ValidationResult.Builder()
-.explanation("Client Auth must be provided when using
TLS/SSL")
-.valid(false).subject("Client Auth").build());
-}
+private final static Set relationships;
-return results;
+static {
+List _propertyDescriptors = new ArrayList<>();
+_propertyDescriptors.add(SMTP_PORT);
+_propertyDescriptors.add(SMTP_MAXIMUM_CONNECTIONS);
+_propertyDescriptors.add(SMTP_TIMEOUT);
+_propertyDescriptors.add(SMTP_MAXIMUM_MSG_SIZE);
+_propertyDescriptors.add(SSL_CONTEXT_SERVICE);
+_propertyDescriptors.add(CLIENT_AUTH);
+propertyDescriptors =
Collections.unmodifiableList(_propertyDescriptors);
+Set _relationships = new HashSet<>();
+_relationships.add(REL_SUCCESS);
+relationships = Collections.unmodifiableSet(_relationships);
}
+private volatile SMTPServer smtp;
-public static final Relationship REL_SUCCESS = new
Relationship.Builder()
-.name("success")
-.description("Extraction was successful")
-.build();
+private volatile SmtpConsumer smtpConsumer;
-private Set relationships;
-private List propertyDescriptors;
-private volatile LinkedBlockingQueue incomingMessages;
+/**
+ *
+ */
+@Override
+public void onTrigger(ProcessContext context, ProcessSessionFactory
sessionFactory) throws ProcessException {
+ProcessSession processSession = sessionFactory.createSession();
+if (this.smtp == null) {
+this.setupSmtpIfNecessary(context, processSession);
+}
+
+if (this.smtpConsumer.hasMessage()) {
+try {
+/*
+ * Will consume incoming message directly from the wire
and into
+ * FlowFile/Content repository before exiting. This
essentially
+ * limits any potential data loss by allowing SMTPServer
thread
+ * to actually commit NiFi session if all good. However in
the
+ * event of exception, such exception will be propagated
back to
+ * the email sender via "undeliverable message" allowing
such
+ * user to re-send the message
+ */
+this.smtpConsumer.consumeUsing((inputDataStream) -> {
+FlowFile flowFile = processSession.create();
+AtomicInteger size = new AtomicInteger();
+flowFile = processSession.write(flowFile, new
OutputStreamCallback() {
+@Override
+public v
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74414544
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -166,317 +108,158 @@
.identifiesControllerService(SSLContextService.class)
.build();
-public static final PropertyDescriptor CLIENT_AUTH = new
PropertyDescriptor.Builder()
+static final PropertyDescriptor CLIENT_AUTH = new
PropertyDescriptor.Builder()
.name("CLIENT_AUTH")
.displayName("Client Auth")
.description("The client authentication policy to use for the
SSL Context. Only used if an SSL Context Service is provided.")
.required(false)
.allowableValues(SSLContextService.ClientAuth.NONE.toString(),
SSLContextService.ClientAuth.REQUIRED.toString())
.build();
-@Override
-protected Collection customValidate(final
ValidationContext validationContext) {
-final List results = new ArrayList<>();
+static final Relationship REL_SUCCESS = new Relationship.Builder()
+.name("success")
+.description("All new messages will be routed as FlowFiles to
this relationship")
+.build();
-final String clientAuth =
validationContext.getProperty(CLIENT_AUTH).getValue();
-final SSLContextService sslContextService =
validationContext.getProperty(SSL_CONTEXT_SERVICE).asControllerService(SSLContextService.class);
+private final static List propertyDescriptors;
-if (sslContextService != null && StringUtils.isBlank(clientAuth)) {
-results.add(new ValidationResult.Builder()
-.explanation("Client Auth must be provided when using
TLS/SSL")
-.valid(false).subject("Client Auth").build());
-}
+private final static Set relationships;
-return results;
+static {
+List _propertyDescriptors = new ArrayList<>();
+_propertyDescriptors.add(SMTP_PORT);
+_propertyDescriptors.add(SMTP_MAXIMUM_CONNECTIONS);
+_propertyDescriptors.add(SMTP_TIMEOUT);
+_propertyDescriptors.add(SMTP_MAXIMUM_MSG_SIZE);
+_propertyDescriptors.add(SSL_CONTEXT_SERVICE);
+_propertyDescriptors.add(CLIENT_AUTH);
+propertyDescriptors =
Collections.unmodifiableList(_propertyDescriptors);
+Set _relationships = new HashSet<>();
+_relationships.add(REL_SUCCESS);
+relationships = Collections.unmodifiableSet(_relationships);
}
+private volatile SMTPServer smtp;
-public static final Relationship REL_SUCCESS = new
Relationship.Builder()
-.name("success")
-.description("Extraction was successful")
-.build();
+private volatile SmtpConsumer smtpConsumer;
-private Set relationships;
-private List propertyDescriptors;
-private volatile LinkedBlockingQueue incomingMessages;
+/**
+ *
+ */
+@Override
+public void onTrigger(ProcessContext context, ProcessSessionFactory
sessionFactory) throws ProcessException {
+ProcessSession processSession = sessionFactory.createSession();
+if (this.smtp == null) {
+this.setupSmtpIfNecessary(context, processSession);
+}
+
+if (this.smtpConsumer.hasMessage()) {
+try {
+/*
+ * Will consume incoming message directly from the wire
and into
+ * FlowFile/Content repository before exiting. This
essentially
+ * limits any potential data loss by allowing SMTPServer
thread
+ * to actually commit NiFi session if all good. However in
the
+ * event of exception, such exception will be propagated
back to
+ * the email sender via "undeliverable message" allowing
such
+ * user to re-send the message
+ */
+this.smtpConsumer.consumeUsing((inputDataStream) -> {
+FlowFile flowFile = processSession.create();
+AtomicInteger size = new AtomicInteger();
+flowFile = processSession.write(flowFile, new
OutputStreamCallback() {
+@Override
+public void process(final OutputStream out) throws
IOException {
+size.set(IOUtils.copy(inputDataStream, out));
+}
+});
+
processSession.getProvenanceRe
[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build
[
https://issues.apache.org/jira/browse/NIFI-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417145#comment-15417145
]
ASF GitHub Bot commented on NIFI-2519:
--
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74414087
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -13,89 +13,52 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
-*/
+ */
package org.apache.nifi.processors.email;
-import javax.net.ssl.SSLContext;
-import javax.net.ssl.SSLSocket;
-import javax.net.ssl.SSLSocketFactory;
import java.io.IOException;
-import java.io.InputStream;
+import java.io.OutputStream;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.util.ArrayList;
-import java.util.Collection;
import java.util.Collections;
-import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
-import java.util.Map;
import java.util.Set;
-import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.TimeUnit;
-import java.util.concurrent.atomic.AtomicBoolean;
-
-import org.apache.commons.lang3.StringUtils;
-
-import org.subethamail.smtp.server.SMTPServer;
-
-
-import org.apache.nifi.annotation.lifecycle.OnStopped;
-import org.apache.nifi.annotation.lifecycle.OnUnscheduled;
-import org.apache.nifi.flowfile.attributes.CoreAttributes;
-import org.apache.nifi.processor.DataUnit;
+import java.util.concurrent.atomic.AtomicInteger;
-import org.apache.nifi.annotation.lifecycle.OnScheduled;
-import org.apache.nifi.components.PropertyDescriptor;
-import org.apache.nifi.processor.AbstractProcessor;
-import org.apache.nifi.processor.ProcessorInitializationContext;
-import org.apache.nifi.processor.Relationship;
-import org.apache.nifi.processor.util.StandardValidators;
+import javax.net.ssl.SSLContext;
+import javax.net.ssl.SSLSocket;
+import javax.net.ssl.SSLSocketFactory;
+import org.apache.commons.io.IOUtils;
import org.apache.nifi.annotation.behavior.InputRequirement;
-import org.apache.nifi.annotation.behavior.WritesAttribute;
-import org.apache.nifi.annotation.behavior.WritesAttributes;
import org.apache.nifi.annotation.documentation.CapabilityDescription;
import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractSessionFactoryProcessor;
+import org.apache.nifi.processor.DataUnit;
import org.apache.nifi.processor.ProcessContext;
import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessSessionFactory;
+import org.apache.nifi.processor.Relationship;
import org.apache.nifi.processor.exception.ProcessException;
-import org.apache.nifi.components.ValidationContext;
-import org.apache.nifi.components.ValidationResult;
-import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.io.OutputStreamCallback;
+import org.apache.nifi.processor.util.StandardValidators;
import org.apache.nifi.ssl.SSLContextService;
-
-import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
-import org.apache.nifi.processors.email.smtp.handler.SMTPResultCode;
-import
org.apache.nifi.processors.email.smtp.handler.SMTPMessageHandlerFactory;
+import org.subethamail.smtp.server.SMTPServer;
@Tags({"listen", "email", "smtp"})
@InputRequirement(InputRequirement.Requirement.INPUT_FORBIDDEN)
-@CapabilityDescription("This processor implements a lightweight SMTP
server to an arbitrary port, " +
-"allowing nifi to listen for incoming email. " +
-"" +
-"Note this server does not perform any email validation. If direct
exposure to the internet is sought," +
-"it may be a better idea to use the combination of NiFi and an
industrial scale MTA (e.g. Postfix)")
-@WritesAttributes({
-@WritesAttribute(attribute = "mime.type", description = "The value
used during HELO"),
-@WritesAttribute(attribute = "smtp.helo", description = "The value
used during HELO"),
-@WritesAttribute(attribute = "smtp.certificates.*.serial",
description = "The serial numbers for each of the " +
-"certificates used by an TLS peer"),
-@WritesAttribute(attribute = "smtp.certificates.*.p
[GitHub] nifi pull request #827: NIFI-2519 Fixed and refactored ListenSMTP processor
Github user trixpan commented on a diff in the pull request:
https://github.com/apache/nifi/pull/827#discussion_r74414087
--- Diff:
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ListenSMTP.java
---
@@ -13,89 +13,52 @@
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
-*/
+ */
package org.apache.nifi.processors.email;
-import javax.net.ssl.SSLContext;
-import javax.net.ssl.SSLSocket;
-import javax.net.ssl.SSLSocketFactory;
import java.io.IOException;
-import java.io.InputStream;
+import java.io.OutputStream;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.util.ArrayList;
-import java.util.Collection;
import java.util.Collections;
-import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
-import java.util.Map;
import java.util.Set;
-import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.TimeUnit;
-import java.util.concurrent.atomic.AtomicBoolean;
-
-import org.apache.commons.lang3.StringUtils;
-
-import org.subethamail.smtp.server.SMTPServer;
-
-
-import org.apache.nifi.annotation.lifecycle.OnStopped;
-import org.apache.nifi.annotation.lifecycle.OnUnscheduled;
-import org.apache.nifi.flowfile.attributes.CoreAttributes;
-import org.apache.nifi.processor.DataUnit;
+import java.util.concurrent.atomic.AtomicInteger;
-import org.apache.nifi.annotation.lifecycle.OnScheduled;
-import org.apache.nifi.components.PropertyDescriptor;
-import org.apache.nifi.processor.AbstractProcessor;
-import org.apache.nifi.processor.ProcessorInitializationContext;
-import org.apache.nifi.processor.Relationship;
-import org.apache.nifi.processor.util.StandardValidators;
+import javax.net.ssl.SSLContext;
+import javax.net.ssl.SSLSocket;
+import javax.net.ssl.SSLSocketFactory;
+import org.apache.commons.io.IOUtils;
import org.apache.nifi.annotation.behavior.InputRequirement;
-import org.apache.nifi.annotation.behavior.WritesAttribute;
-import org.apache.nifi.annotation.behavior.WritesAttributes;
import org.apache.nifi.annotation.documentation.CapabilityDescription;
import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractSessionFactoryProcessor;
+import org.apache.nifi.processor.DataUnit;
import org.apache.nifi.processor.ProcessContext;
import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessSessionFactory;
+import org.apache.nifi.processor.Relationship;
import org.apache.nifi.processor.exception.ProcessException;
-import org.apache.nifi.components.ValidationContext;
-import org.apache.nifi.components.ValidationResult;
-import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.io.OutputStreamCallback;
+import org.apache.nifi.processor.util.StandardValidators;
import org.apache.nifi.ssl.SSLContextService;
-
-import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
-import org.apache.nifi.processors.email.smtp.handler.SMTPResultCode;
-import
org.apache.nifi.processors.email.smtp.handler.SMTPMessageHandlerFactory;
+import org.subethamail.smtp.server.SMTPServer;
@Tags({"listen", "email", "smtp"})
@InputRequirement(InputRequirement.Requirement.INPUT_FORBIDDEN)
-@CapabilityDescription("This processor implements a lightweight SMTP
server to an arbitrary port, " +
-"allowing nifi to listen for incoming email. " +
-"" +
-"Note this server does not perform any email validation. If direct
exposure to the internet is sought," +
-"it may be a better idea to use the combination of NiFi and an
industrial scale MTA (e.g. Postfix)")
-@WritesAttributes({
-@WritesAttribute(attribute = "mime.type", description = "The value
used during HELO"),
-@WritesAttribute(attribute = "smtp.helo", description = "The value
used during HELO"),
-@WritesAttribute(attribute = "smtp.certificates.*.serial",
description = "The serial numbers for each of the " +
-"certificates used by an TLS peer"),
-@WritesAttribute(attribute = "smtp.certificates.*.principal",
description = "The principal for each of the " +
-"certificates used by an TLS peer"),
-@WritesAttribute(attribute = "smtp.from", description = "The value
used during MAIL FROM (i.e. envelope)"),
-
[jira] [Updated] (NIFI-2550) Input port requires 'receive data via site-to-site' policy for both ends
[ https://issues.apache.org/jira/browse/NIFI-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2550: Attachment: screenshot-1.png > Input port requires 'receive data via site-to-site' policy for both ends > > > Key: NIFI-2550 > URL: https://issues.apache.org/jira/browse/NIFI-2550 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 > Environment: Site-to-Site, Secure Cluster to Secure Cluster >Reporter: Koji Kawamura > Attachments: screenshot-1.png > > > I'm trying to setup a Site-to-Site connection between two NiFi clusters (P > and Q). Both secured. > At NiFi Q, there's an input-port, then NiFi P sends data to it. > NiFi P -> https -> NiFi Q > NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity > on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. > Confirmed that NiFi P Remote Process Group can get site-to-site detail. > However, it couldn't access input-port. > I've added 'p-nifi' group to 'receive data via site-to-site' policy of the > input-port, but still it can't accessed. > I found that > org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization > checks all the DN chain. By debugging, I found that it checks not only NiFi P > nodes, but also NiFi Q nodes. The DN chain looked like below: > [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, > C=US, CN=1.q.nifi] > After adding 'q-nifi' group to the input port policy, NiFi P can access the > remote input port. > There maybe some reason for doing this, but as an user, I didn't expect that > I need to add NiFi Q to that policy. > Is this an expected behavior? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2550) Input port requires 'receive data via site-to-site' policy for both ends
[ https://issues.apache.org/jira/browse/NIFI-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2550: Description: I'm trying to setup a Site-to-Site connection between two NiFi clusters (P and Q). Both secured. At NiFi Q, there's an input-port, then NiFi P sends data to it. NiFi P -> https -> NiFi Q NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. Confirmed that NiFi P Remote Process Group can get site-to-site detail. [screenshot-1|https://issues.apache.org/jira/secure/attachment/12823222/screenshot-1.png] However, it couldn't access input-port. I've added 'p-nifi' group to 'receive data via site-to-site' policy of the input-port, but still it can't accessed. [screenshot-2|https://issues.apache.org/jira/secure/attachment/12823223/screenshot-2.png] I found that org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization checks all the DN chain. By debugging, I found that it checks not only NiFi P nodes, but also NiFi Q nodes. The DN chain looked like below: [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, C=US, CN=1.q.nifi] After adding 'q-nifi' group to the input port policy, NiFi P can access the remote input port. There maybe some reason for doing this, but as an user, I didn't expect that I need to add NiFi Q to that policy. Is this an expected behavior? was: I'm trying to setup a Site-to-Site connection between two NiFi clusters (P and Q). Both secured. At NiFi Q, there's an input-port, then NiFi P sends data to it. NiFi P -> https -> NiFi Q NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. Confirmed that NiFi P Remote Process Group can get site-to-site detail. [screenshot-1|https://issues.apache.org/jira/secure/attachment/12823222/screenshot-1.png] However, it couldn't access input-port. I've added 'p-nifi' group to 'receive data via site-to-site' policy of the input-port, but still it can't accessed. I found that org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization checks all the DN chain. By debugging, I found that it checks not only NiFi P nodes, but also NiFi Q nodes. The DN chain looked like below: [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, C=US, CN=1.q.nifi] After adding 'q-nifi' group to the input port policy, NiFi P can access the remote input port. There maybe some reason for doing this, but as an user, I didn't expect that I need to add NiFi Q to that policy. Is this an expected behavior? > Input port requires 'receive data via site-to-site' policy for both ends > > > Key: NIFI-2550 > URL: https://issues.apache.org/jira/browse/NIFI-2550 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 > Environment: Site-to-Site, Secure Cluster to Secure Cluster >Reporter: Koji Kawamura > Attachments: screenshot-1.png, screenshot-2.png > > > I'm trying to setup a Site-to-Site connection between two NiFi clusters (P > and Q). Both secured. > At NiFi Q, there's an input-port, then NiFi P sends data to it. > NiFi P -> https -> NiFi Q > NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity > on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. > Confirmed that NiFi P Remote Process Group can get site-to-site detail. > [screenshot-1|https://issues.apache.org/jira/secure/attachment/12823222/screenshot-1.png] > However, it couldn't access input-port. > I've added 'p-nifi' group to 'receive data via site-to-site' policy of the > input-port, but still it can't accessed. > [screenshot-2|https://issues.apache.org/jira/secure/attachment/12823223/screenshot-2.png] > I found that > org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization > checks all the DN chain. By debugging, I found that it checks not only NiFi P > nodes, but also NiFi Q nodes. The DN chain looked like below: > [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, > C=US, CN=1.q.nifi] > After adding 'q-nifi' group to the input port policy, NiFi P can access the > remote input port. > There maybe some reason for doing this, but as an user, I didn't expect that > I need to add NiFi Q to that policy. > Is this an expected behavior? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2550) Input port requires 'receive data via site-to-site' policy for both ends
[ https://issues.apache.org/jira/browse/NIFI-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2550: Description: I'm trying to setup a Site-to-Site connection between two NiFi clusters (P and Q). Both secured. At NiFi Q, there's an input-port, then NiFi P sends data to it. NiFi P -> https -> NiFi Q NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. Confirmed that NiFi P Remote Process Group can get site-to-site detail. [screenshot-1|https://issues.apache.org/jira/secure/attachment/12823222/screenshot-1.png] However, it couldn't access input-port. I've added 'p-nifi' group to 'receive data via site-to-site' policy of the input-port, but still it can't accessed. I found that org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization checks all the DN chain. By debugging, I found that it checks not only NiFi P nodes, but also NiFi Q nodes. The DN chain looked like below: [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, C=US, CN=1.q.nifi] After adding 'q-nifi' group to the input port policy, NiFi P can access the remote input port. There maybe some reason for doing this, but as an user, I didn't expect that I need to add NiFi Q to that policy. Is this an expected behavior? was: I'm trying to setup a Site-to-Site connection between two NiFi clusters (P and Q). Both secured. At NiFi Q, there's an input-port, then NiFi P sends data to it. NiFi P -> https -> NiFi Q NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. Confirmed that NiFi P Remote Process Group can get site-to-site detail. However, it couldn't access input-port. I've added 'p-nifi' group to 'receive data via site-to-site' policy of the input-port, but still it can't accessed. I found that org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization checks all the DN chain. By debugging, I found that it checks not only NiFi P nodes, but also NiFi Q nodes. The DN chain looked like below: [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, C=US, CN=1.q.nifi] After adding 'q-nifi' group to the input port policy, NiFi P can access the remote input port. There maybe some reason for doing this, but as an user, I didn't expect that I need to add NiFi Q to that policy. Is this an expected behavior? > Input port requires 'receive data via site-to-site' policy for both ends > > > Key: NIFI-2550 > URL: https://issues.apache.org/jira/browse/NIFI-2550 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 > Environment: Site-to-Site, Secure Cluster to Secure Cluster >Reporter: Koji Kawamura > Attachments: screenshot-1.png, screenshot-2.png > > > I'm trying to setup a Site-to-Site connection between two NiFi clusters (P > and Q). Both secured. > At NiFi Q, there's an input-port, then NiFi P sends data to it. > NiFi P -> https -> NiFi Q > NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity > on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. > Confirmed that NiFi P Remote Process Group can get site-to-site detail. > [screenshot-1|https://issues.apache.org/jira/secure/attachment/12823222/screenshot-1.png] > However, it couldn't access input-port. > I've added 'p-nifi' group to 'receive data via site-to-site' policy of the > input-port, but still it can't accessed. > I found that > org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization > checks all the DN chain. By debugging, I found that it checks not only NiFi P > nodes, but also NiFi Q nodes. The DN chain looked like below: > [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, > C=US, CN=1.q.nifi] > After adding 'q-nifi' group to the input port policy, NiFi P can access the > remote input port. > There maybe some reason for doing this, but as an user, I didn't expect that > I need to add NiFi Q to that policy. > Is this an expected behavior? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2545) Cannot tell a processor is "STOPPING", can edit, cannot restart it
[
https://issues.apache.org/jira/browse/NIFI-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417117#comment-15417117
]
Matt Gilman commented on NIFI-2545:
---
[~joewitt] [~markap14] Does this mean that the processor was told to stop and
all of its active threads completed. However, it's OnStopped lifecycle hook has
not returned? What triggers the transition from STOPPING to STOPPED?
What is the expected behavior in this case? A component should only be editable
(and restartable) when it is actually STOPPED?
> Cannot tell a processor is "STOPPING", can edit, cannot restart it
> --
>
> Key: NIFI-2545
> URL: https://issues.apache.org/jira/browse/NIFI-2545
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
> Fix For: 1.0.0
>
>
> Testing ListenSMTP processor. It has some bad behavior whereby it will not
> stop when told to. But on the UI i cannot tell that at all. So, i went to
> edit the processor config which I was able to do. Then went to start it and
> I get
> {quote}
> 7667f0c7-0156-1000-8181-5b556f8544da cannot be started because it is not
> stopped. Current state is STOPPING
> {quote}
> There should be a visual indicator of its status and we should not be able to
> edit a processor which is not stopped.
> More details on that specific case here
> https://issues.apache.org/jira/browse/NIFI-2519#
> But key is that a bad behaving processor can allow the user to do things they
> should not be able to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-2550) Input port requires 'receive data via site-to-site' policy for both ends
[ https://issues.apache.org/jira/browse/NIFI-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2550: Attachment: screenshot-2.png > Input port requires 'receive data via site-to-site' policy for both ends > > > Key: NIFI-2550 > URL: https://issues.apache.org/jira/browse/NIFI-2550 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 > Environment: Site-to-Site, Secure Cluster to Secure Cluster >Reporter: Koji Kawamura > Attachments: screenshot-1.png, screenshot-2.png > > > I'm trying to setup a Site-to-Site connection between two NiFi clusters (P > and Q). Both secured. > At NiFi Q, there's an input-port, then NiFi P sends data to it. > NiFi P -> https -> NiFi Q > NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity > on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. > Confirmed that NiFi P Remote Process Group can get site-to-site detail. > However, it couldn't access input-port. > I've added 'p-nifi' group to 'receive data via site-to-site' policy of the > input-port, but still it can't accessed. > I found that > org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization > checks all the DN chain. By debugging, I found that it checks not only NiFi P > nodes, but also NiFi Q nodes. The DN chain looked like below: > [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, > C=US, CN=1.q.nifi] > After adding 'q-nifi' group to the input port policy, NiFi P can access the > remote input port. > There maybe some reason for doing this, but as an user, I didn't expect that > I need to add NiFi Q to that policy. > Is this an expected behavior? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2550) Input port requires 'receive data via site-to-site' policy for both ends
Koji Kawamura created NIFI-2550: --- Summary: Input port requires 'receive data via site-to-site' policy for both ends Key: NIFI-2550 URL: https://issues.apache.org/jira/browse/NIFI-2550 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.0.0 Environment: Site-to-Site, Secure Cluster to Secure Cluster Reporter: Koji Kawamura I'm trying to setup a Site-to-Site connection between two NiFi clusters (P and Q). Both secured. At NiFi Q, there's an input-port, then NiFi P sends data to it. NiFi P -> https -> NiFi Q NiFi P has two nodes, so I created a group 'p-nifi' having the nodes identity on NiFi Q. Then add 'p-nifi' group to 'retrieve site-to-site detail' policy. Confirmed that NiFi P Remote Process Group can get site-to-site detail. However, it couldn't access input-port. I've added 'p-nifi' group to 'receive data via site-to-site' policy of the input-port, but still it can't accessed. I found that org.apache.nifi.authorization.resource.DataAuthorizable.checkAuthorization checks all the DN chain. By debugging, I found that it checks not only NiFi P nodes, but also NiFi Q nodes. The DN chain looked like below: [L=1.p.nifi, C=US, CN=1.p.nifi, L=0.q.nifi, C=US, CN=0.q.nifi, L=1.q.nifi, C=US, CN=1.q.nifi] After adding 'q-nifi' group to the input port policy, NiFi P can access the remote input port. There maybe some reason for doing this, but as an user, I didn't expect that I need to add NiFi Q to that policy. Is this an expected behavior? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2543) UI - Refresh Controller Service Referencing Components
[ https://issues.apache.org/jira/browse/NIFI-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman reassigned NIFI-2543: - Assignee: Matt Gilman > UI - Refresh Controller Service Referencing Components > -- > > Key: NIFI-2543 > URL: https://issues.apache.org/jira/browse/NIFI-2543 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Critical > Fix For: 1.0.0 > > > After updating a Controller Service, we attempt to refresh all components > that reference it. It appears that the UI is attempting to refresh a > referencing component that the user does not have access to. This is > resulting in a confusing error message to the user as it appears the save was > unsuccessful. > The updating should be done more selectively or through an endpoint that > returns the services in a filtered form (like listing all services). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2542) Revisions for Controller Service Referencing Components
[ https://issues.apache.org/jira/browse/NIFI-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman reassigned NIFI-2542: - Assignee: Matt Gilman > Revisions for Controller Service Referencing Components > --- > > Key: NIFI-2542 > URL: https://issues.apache.org/jira/browse/NIFI-2542 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Critical > Fix For: 1.0.0 > > > The revisions for components that reference controller services transitively > are not available when generating the response DTOs. > Additionally, it doesn't appear that the transitive references are being > returned or rendered correctly. It is unclear which is the case due to the > issue described above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2501) UI - Process Group configuration requires write permissions
[ https://issues.apache.org/jira/browse/NIFI-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2501: -- Status: Patch Available (was: In Progress) > UI - Process Group configuration requires write permissions > --- > > Key: NIFI-2501 > URL: https://issues.apache.org/jira/browse/NIFI-2501 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > Since Controller Services are accessed through the Process Group > configuration, we need to allow users without read/write permissions to > access that dialog in case they do have permissions to a controller service > in there. The Controller settings dialog is already updated to support this > case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2501) UI - Process Group configuration requires write permissions
[ https://issues.apache.org/jira/browse/NIFI-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417108#comment-15417108 ] ASF GitHub Bot commented on NIFI-2501: -- GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/835 Ensuring users can access the Controller Service and Reporting Tasks lists NIFI-2501: - Ensuring users can access the controller service list regardless of permissions on the corresponding process group or controller. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2501 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/835.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 #835 commit 8e99c338c17d08ee465f9fac9f178cc8127f20ee Author: Matt Gilman Date: 2016-08-10T18:52:59Z NIFI-2501: - Ensuring users can access the controller service list regardless of permissions on the corresponding process group or controller. > UI - Process Group configuration requires write permissions > --- > > Key: NIFI-2501 > URL: https://issues.apache.org/jira/browse/NIFI-2501 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > Since Controller Services are accessed through the Process Group > configuration, we need to allow users without read/write permissions to > access that dialog in case they do have permissions to a controller service > in there. The Controller settings dialog is already updated to support this > case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #835: Ensuring users can access the Controller Service and...
GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/835 Ensuring users can access the Controller Service and Reporting Tasks lists NIFI-2501: - Ensuring users can access the controller service list regardless of permissions on the corresponding process group or controller. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2501 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/835.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 #835 commit 8e99c338c17d08ee465f9fac9f178cc8127f20ee Author: Matt Gilman Date: 2016-08-10T18:52:59Z NIFI-2501: - Ensuring users can access the controller service list regardless of permissions on the corresponding process group or controller. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (NIFI-2549) Change Query name and number to a unique identifier
[ https://issues.apache.org/jira/browse/NIFI-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Ellison closed NIFI-2549. - > Change Query name and number to a unique identifier > --- > > Key: NIFI-2549 > URL: https://issues.apache.org/jira/browse/NIFI-2549 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Tim Ellison > > Presently, each individual Query can be identified by a (String) name and > (double) number. These are not used by Pirk, but aid in identifying the > query to the user, in debug, etc. > The proposed improvement is to merge these into a universally unique > identifier (UUID). While the UUID may not be as readable as a user defined > string, there is less opportunity for inadvertent identity collision, and > taken together with the query schema name still makes identifying a > particular query easy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-2549) Change Query name and number to a unique identifier
[ https://issues.apache.org/jira/browse/NIFI-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Ellison resolved NIFI-2549. --- Resolution: Invalid Apologies, wrong project! > Change Query name and number to a unique identifier > --- > > Key: NIFI-2549 > URL: https://issues.apache.org/jira/browse/NIFI-2549 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Tim Ellison > > Presently, each individual Query can be identified by a (String) name and > (double) number. These are not used by Pirk, but aid in identifying the > query to the user, in debug, etc. > The proposed improvement is to merge these into a universally unique > identifier (UUID). While the UUID may not be as readable as a user defined > string, there is less opportunity for inadvertent identity collision, and > taken together with the query schema name still makes identifying a > particular query easy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2549) Change Query name and number to a unique identifier
Tim Ellison created NIFI-2549: - Summary: Change Query name and number to a unique identifier Key: NIFI-2549 URL: https://issues.apache.org/jira/browse/NIFI-2549 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: Tim Ellison Presently, each individual Query can be identified by a (String) name and (double) number. These are not used by Pirk, but aid in identifying the query to the user, in debug, etc. The proposed improvement is to merge these into a universally unique identifier (UUID). While the UUID may not be as readable as a user defined string, there is less opportunity for inadvertent identity collision, and taken together with the query schema name still makes identifying a particular query easy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2548) Group can't be added to a policy with 'More than one user matches xxx' message
[ https://issues.apache.org/jira/browse/NIFI-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2548: Description: When adding a group to a policy, if there're users having the group name in its name, the group can't be added to the policy. I'm using two NiFi clusters (P and Q), both secured. In order to use Site-to-Site, I wanted to create a group containing other clusters node identities, to make policy management easy. NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. Then when I tried to add the group to the 'retrieve site-to-site details' policy, UI shows 'More than one user matches p.nifi' message, because there are also individual users having 'p.nifi' in its name. Please refer attached screenshot, too. Prioritize this as 'Minor' because renaming the group can avoid this issue easily. Ex) 'p.nifi' to 'p-nifi' in my case. was: When adding a group to a policy, if there're users having the group name in its name, the group can't be added to the policy. I'm using two NiFi clusters (P and Q), both secured. In order to use Site-to-Site, I wanted to create a group containing other clusters node identities, to make policy management easy. NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. Then when I tried to add the group to the 'retrieve site-to-site details' policy, UI shows 'More than one user matches p.nifi' message, because there are also individual users having 'p.nifi' in its name. Please refer attached screenshot, too. > Group can't be added to a policy with 'More than one user matches xxx' message > -- > > Key: NIFI-2548 > URL: https://issues.apache.org/jira/browse/NIFI-2548 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Koji Kawamura >Priority: Minor > Attachments: screenshot-1.png, screenshot-2.png > > > When adding a group to a policy, if there're users having the group name in > its name, the group can't be added to the policy. > I'm using two NiFi clusters (P and Q), both secured. In order to use > Site-to-Site, I wanted to create a group containing other clusters node > identities, to make policy management easy. > NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. > Then when I tried to add the group to the 'retrieve site-to-site details' > policy, UI shows 'More than one user matches p.nifi' message, because there > are also individual users having 'p.nifi' in its name. > Please refer attached screenshot, too. > Prioritize this as 'Minor' because renaming the group can avoid this issue > easily. Ex) 'p.nifi' to 'p-nifi' in my case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2548) Group can't be added to a policy with 'More than one user matches xxx' message
[ https://issues.apache.org/jira/browse/NIFI-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2548: Description: When adding a group to a policy, if there're users having the group name in its name, the group can't be added to the policy. I'm using two NiFi clusters (P and Q), both secured. In order to use Site-to-Site, I wanted to create a group containing other clusters node identities, to make policy management easy. NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. Then when I tried to add the group to the 'retrieve site-to-site details' policy, UI shows 'More than one user matches p.nifi' message, because there are also individual users having 'p.nifi' in its name. Please refer attached screenshot, too. was: When adding a group to a policy, if there're users having the group name in its name, the group can't be added to the policy. I'm using two NiFi clusters (P and Q), both secured. In order to use Site-to-Site, I wanted to create a group containing other clusters node identities, to make policy management easy. NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. Then when I tried to add the group to the root process group policy, UI shows 'More than one user matches p.nifi' message, because there are also individual users having 'p.nifi' in its name. Please refer attached screenshot, too. > Group can't be added to a policy with 'More than one user matches xxx' message > -- > > Key: NIFI-2548 > URL: https://issues.apache.org/jira/browse/NIFI-2548 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Koji Kawamura >Priority: Minor > Attachments: screenshot-1.png, screenshot-2.png > > > When adding a group to a policy, if there're users having the group name in > its name, the group can't be added to the policy. > I'm using two NiFi clusters (P and Q), both secured. In order to use > Site-to-Site, I wanted to create a group containing other clusters node > identities, to make policy management easy. > NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. > Then when I tried to add the group to the 'retrieve site-to-site details' > policy, UI shows 'More than one user matches p.nifi' message, because there > are also individual users having 'p.nifi' in its name. > Please refer attached screenshot, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2548) Group can't be added to a policy with 'More than one user matches xxx' message
[ https://issues.apache.org/jira/browse/NIFI-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15416735#comment-15416735 ] Koji Kawamura commented on NIFI-2548: - Steps to reproduce: Search with 'p.nifi', a group and users are shown. Select the group, then click 'OK'. > Group can't be added to a policy with 'More than one user matches xxx' message > -- > > Key: NIFI-2548 > URL: https://issues.apache.org/jira/browse/NIFI-2548 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Koji Kawamura >Priority: Minor > Attachments: screenshot-1.png, screenshot-2.png > > > When adding a group to a policy, if there're users having the group name in > its name, the group can't be added to the policy. > I'm using two NiFi clusters (P and Q), both secured. In order to use > Site-to-Site, I wanted to create a group containing other clusters node > identities, to make policy management easy. > NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. > Then when I tried to add the group to the root process group policy, UI shows > 'More than one user matches p.nifi' message, because there are also > individual users having 'p.nifi' in its name. > Please refer attached screenshot, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2548) Group can't be added to a policy with 'More than one user matches xxx' message
[ https://issues.apache.org/jira/browse/NIFI-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2548: Attachment: screenshot-2.png > Group can't be added to a policy with 'More than one user matches xxx' message > -- > > Key: NIFI-2548 > URL: https://issues.apache.org/jira/browse/NIFI-2548 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Koji Kawamura >Priority: Minor > Attachments: screenshot-1.png, screenshot-2.png > > > When adding a group to a policy, if there're users having the group name in > its name, the group can't be added to the policy. > I'm using two NiFi clusters (P and Q), both secured. In order to use > Site-to-Site, I wanted to create a group containing other clusters node > identities, to make policy management easy. > NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. > Then when I tried to add the group to the root process group policy, UI shows > 'More than one user matches p.nifi' message, because there are also > individual users having 'p.nifi' in its name. > Please refer attached screenshot, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2548) Group can't be added to a policy with 'More than one user matches xxx' message
[ https://issues.apache.org/jira/browse/NIFI-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-2548: Attachment: screenshot-1.png > Group can't be added to a policy with 'More than one user matches xxx' message > -- > > Key: NIFI-2548 > URL: https://issues.apache.org/jira/browse/NIFI-2548 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Koji Kawamura >Priority: Minor > Attachments: screenshot-1.png > > > When adding a group to a policy, if there're users having the group name in > its name, the group can't be added to the policy. > I'm using two NiFi clusters (P and Q), both secured. In order to use > Site-to-Site, I wanted to create a group containing other clusters node > identities, to make policy management easy. > NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. > Then when I tried to add the group to the root process group policy, UI shows > 'More than one user matches p.nifi' message, because there are also > individual users having 'p.nifi' in its name. > Please refer attached screenshot, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2548) Group can't be added to a policy with 'More than one user matches xxx' message
Koji Kawamura created NIFI-2548: --- Summary: Group can't be added to a policy with 'More than one user matches xxx' message Key: NIFI-2548 URL: https://issues.apache.org/jira/browse/NIFI-2548 Project: Apache NiFi Issue Type: Bug Components: Core UI Affects Versions: 1.0.0 Reporter: Koji Kawamura Priority: Minor When adding a group to a policy, if there're users having the group name in its name, the group can't be added to the policy. I'm using two NiFi clusters (P and Q), both secured. In order to use Site-to-Site, I wanted to create a group containing other clusters node identities, to make policy management easy. NiFi P is pushing data via Site-to-Site, so I added 'p.nifi' group in NiFi Q. Then when I tried to add the group to the root process group policy, UI shows 'More than one user matches p.nifi' message, because there are also individual users having 'p.nifi' in its name. Please refer attached screenshot, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
