[jira] [Created] (NIFI-3439) Making password property in hive connection pool a hidden show.
Ramakrishnan V created NIFI-3439: Summary: Making password property in hive connection pool a hidden show. Key: NIFI-3439 URL: https://issues.apache.org/jira/browse/NIFI-3439 Project: Apache NiFi Issue Type: Improvement Components: Core UI Affects Versions: 1.1.1 Environment: Google Chrome browser Reporter: Ramakrishnan V Priority: Minor When user types the password in the password attribute in hive connection pool controller service, the characters are visible. Once completed the password is encrypted and no longer visible. shouldn't be me made as normal hidden show password box ? The user always has the option to delete the controller service and re-configure if he has entered a wrong password. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3114) Update ListenHTTP processor documentation
[
https://issues.apache.org/jira/browse/NIFI-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852275#comment-15852275
]
Michael Moser commented on NIFI-3114:
-
Aand I forgot to signoff and put This closes #1369 into the commit
message. Would you close the PR please [~pvillard]?
> Update ListenHTTP processor documentation
> -
>
> Key: NIFI-3114
> URL: https://issues.apache.org/jira/browse/NIFI-3114
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Documentation & Website
>Affects Versions: 1.1.0
>Reporter: Andy LoPresto
>Assignee: Pierre Villard
> Labels: documentation
> Fix For: 1.2.0
>
>
> The processor documentation for
> [{{ListenHTTP}}|https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.ListenHTTP/index.html]
> describes it as
> bq. Starts an HTTP Server that is used to receive FlowFiles from remote
> sources.
> # the wording implies that users should use this processor for communication
> between NiFi instances, when [Site to
> Site|https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#site-to-site]
> offers a more compelling and robust inter-NiFi communication platform.
> # the documentation makes no mention that only the {{POST}} and {{HEAD}} HTTP
> methods are supported, while {{GET}}, {{PUT}}, and {{DELETE}} will result in
> a error and the HTTP response status code {{405}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (NIFI-3114) Update ListenHTTP processor documentation
[
https://issues.apache.org/jira/browse/NIFI-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Moser updated NIFI-3114:
Resolution: Fixed
Fix Version/s: 1.2.0
Status: Resolved (was: Patch Available)
> Update ListenHTTP processor documentation
> -
>
> Key: NIFI-3114
> URL: https://issues.apache.org/jira/browse/NIFI-3114
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Documentation & Website
>Affects Versions: 1.1.0
>Reporter: Andy LoPresto
>Assignee: Pierre Villard
> Labels: documentation
> Fix For: 1.2.0
>
>
> The processor documentation for
> [{{ListenHTTP}}|https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.ListenHTTP/index.html]
> describes it as
> bq. Starts an HTTP Server that is used to receive FlowFiles from remote
> sources.
> # the wording implies that users should use this processor for communication
> between NiFi instances, when [Site to
> Site|https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#site-to-site]
> offers a more compelling and robust inter-NiFi communication platform.
> # the documentation makes no mention that only the {{POST}} and {{HEAD}} HTTP
> methods are supported, while {{GET}}, {{PUT}}, and {{DELETE}} will result in
> a error and the HTTP response status code {{405}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NIFI-3114) Update ListenHTTP processor documentation
[
https://issues.apache.org/jira/browse/NIFI-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852272#comment-15852272
]
ASF GitHub Bot commented on NIFI-3114:
--
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/1369
Confirmed new docs in a running NiFi. Looks good to me. Merged to master.
> Update ListenHTTP processor documentation
> -
>
> Key: NIFI-3114
> URL: https://issues.apache.org/jira/browse/NIFI-3114
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Documentation & Website
>Affects Versions: 1.1.0
>Reporter: Andy LoPresto
>Assignee: Pierre Villard
> Labels: documentation
>
> The processor documentation for
> [{{ListenHTTP}}|https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.ListenHTTP/index.html]
> describes it as
> bq. Starts an HTTP Server that is used to receive FlowFiles from remote
> sources.
> # the wording implies that users should use this processor for communication
> between NiFi instances, when [Site to
> Site|https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#site-to-site]
> offers a more compelling and robust inter-NiFi communication platform.
> # the documentation makes no mention that only the {{POST}} and {{HEAD}} HTTP
> methods are supported, while {{GET}}, {{PUT}}, and {{DELETE}} will result in
> a error and the HTTP response status code {{405}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] nifi issue #1369: NIFI-3114 Updated documentation of ListenHTTP
Github user mosermw commented on the issue: https://github.com/apache/nifi/pull/1369 Confirmed new docs in a running NiFi. Looks good to me. 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] [Resolved] (NIFI-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Moser resolved NIFI-3055. - Resolution: Fixed Fix Version/s: 1.2.0 0.8.0 Merged to master and 0.x. Would you close PR #1470? Thanks [~jskora]. > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > Fix For: 0.8.0, 1.2.0 > > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852202#comment-15852202 ] ASF GitHub Bot commented on NIFI-3055: -- Github user mosermw commented on the issue: https://github.com/apache/nifi/pull/1470 Reviewed along with #1469 and looks good to me. Will squash and merge to 0.x > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi issue #1470: NIFI-3055 StandardRecordWriter Can Throw UTFDataFormatExce...
Github user mosermw commented on the issue: https://github.com/apache/nifi/pull/1470 Reviewed along with #1469 and looks good to me. Will squash and merge to 0.x --- 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-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852201#comment-15852201 ] ASF subversion and git services commented on NIFI-3055: --- Commit 4f72e3491f2372c8c45afb96a765c1f5cdd2f07d in nifi's branch refs/heads/0.x from [~jskora] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=4f72e34 ] NIFI-3055 StandardRecordWriter Can Throw UTFDataFormatException (0.x) * Updated StandardRecordWriter to consider the encoding behavior of * java.io.DataOutputStream.writeUTF() and truncate string values such that * the UTF representation will not be longer than that DataOutputStream's * 64K byte UTF format limit. * Add test to confirm handling of large UTF strings. Signed-off-by: Mike Moser This closes #1470. > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3389) FlowFileSchema writes attribute name and value as STRING instead of LONG_STRING
[ https://issues.apache.org/jira/browse/NIFI-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852157#comment-15852157 ] Michael Moser commented on NIFI-3389: - The 65535 byte limit is a symptom of DataOutputStream writeUTF(), which is used by SchemaRecordWriter writeRecord(). NIFI-3055 fixes SchemaRecordWriter so that it truncates and logs a WARN rather than throwing an exception. I think I will bump the priority of this ticket, because this is a significant regression. > FlowFileSchema writes attribute name and value as STRING instead of > LONG_STRING > --- > > Key: NIFI-3389 > URL: https://issues.apache.org/jira/browse/NIFI-3389 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Bryan Rosander >Assignee: Bryan Rosander > Labels: regression > > This causes errors when the names or values of attributes exceeds 65535 bytes > when encoded as UTF-8. > The fix would be pretty trivial but it has backwards compatibility > implications and the schema will need to be versioned to still be able to > read old flow files. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NIFI-3389) FlowFileSchema writes attribute name and value as STRING instead of LONG_STRING
[ https://issues.apache.org/jira/browse/NIFI-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Moser updated NIFI-3389: Priority: Critical (was: Major) > FlowFileSchema writes attribute name and value as STRING instead of > LONG_STRING > --- > > Key: NIFI-3389 > URL: https://issues.apache.org/jira/browse/NIFI-3389 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Bryan Rosander >Assignee: Bryan Rosander >Priority: Critical > Labels: regression > > This causes errors when the names or values of attributes exceeds 65535 bytes > when encoded as UTF-8. > The fix would be pretty trivial but it has backwards compatibility > implications and the schema will need to be versioned to still be able to > read old flow files. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852125#comment-15852125 ] ASF subversion and git services commented on NIFI-3055: --- Commit 376af83a3dcfa5361be0859b54d91d30c685494e in nifi's branch refs/heads/master from [~jskora] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=376af83 ] NIFI-3055 StandardRecordWriter Can Throw UTFDataFormatException * Updated StandardRecordWriter, even though it is now deprecated to consider the encoding behavior of java.io.DataOutputStream.writeUTF() and truncate string values such that the UTF representation will not be longer than that DataOutputStream's 64K UTF format limit. * Updated the new SchemaRecordWriter class to similarly truncate long Strings that will be written as UTF. * Add tests to confirm handling of large UTF strings and various edge conditions of UTF string handling. Signed-off-by: Mike Moser This closes #1469. > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi pull request #1469: NIFI-3055 StandardRecordWriter Can Throw UTFDataFor...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1469 --- 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-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852126#comment-15852126 ] ASF GitHub Bot commented on NIFI-3055: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1469 > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852100#comment-15852100 ] ASF GitHub Bot commented on NIFI-3055: -- Github user mosermw commented on the issue: https://github.com/apache/nifi/pull/1469 +1 looks good. I like the unit tests! I tested master branch before (exceptions galore and all partitions in flowfile repository was blacklisted) and after, we get appropriate WARN truncation messages in the logs. Will squash and merge. > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi issue #1469: NIFI-3055 StandardRecordWriter Can Throw UTFDataFormatExce...
Github user mosermw commented on the issue: https://github.com/apache/nifi/pull/1469 +1 looks good. I like the unit tests! I tested master branch before (exceptions galore and all partitions in flowfile repository was blacklisted) and after, we get appropriate WARN truncation messages in the logs. Will squash and merge. --- 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-3438) Ability to link to a view in Nifi (process group, processor, etc...)
[ https://issues.apache.org/jira/browse/NIFI-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852079#comment-15852079 ] Joseph Witt commented on NIFI-3438: --- really like the idea to be able to get better/deeper links to share to ease working across teams/etc.. > Ability to link to a view in Nifi (process group, processor, etc...) > > > Key: NIFI-3438 > URL: https://issues.apache.org/jira/browse/NIFI-3438 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Nicholas Carenza >Priority: Minor > > I would like to be able to share a link to a particular view in the Nifi UI. > For example: > #/ might just bring me to that processor, center it in view and > reset the zoom. If it is a process group, it might go to it an bring all > processors into view. > #//config might then also bring up the configuration for that > processor > #//config/properties might then also set the tab to 'properties' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3437) KafkaConsumer pause/resume
[ https://issues.apache.org/jira/browse/NIFI-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852074#comment-15852074 ] Joseph Witt commented on NIFI-3437: --- [~ncarenza] That is already how that processor works. It is the group id in that processor which determines how it will be tracked against the offset it has consumed up to. You can stop/restart/rename the processor and have no issues at all. You can even create a totally new and or additional processor and if it uses the same group identifier it will be tracked as an additional kafka consumer, assigned partitions, and its offset will be appropriately tracked. Are you seeing behavior that does not align to what I'm saying? > KafkaConsumer pause/resume > -- > > Key: NIFI-3437 > URL: https://issues.apache.org/jira/browse/NIFI-3437 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Nicholas Carenza >Priority: Minor > > Could the KafkaConsumer processor keep track of it's position so that if it > is stopped and started again it can attempt to resume consuming from that > position? > If I have to restart nifi or rename the consumer processor I want to make > sure I don't miss any messages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NIFI-3437) KafkaConsumer pause/resume
[ https://issues.apache.org/jira/browse/NIFI-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Carenza updated NIFI-3437: --- Priority: Minor (was: Major) > KafkaConsumer pause/resume > -- > > Key: NIFI-3437 > URL: https://issues.apache.org/jira/browse/NIFI-3437 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Nicholas Carenza >Priority: Minor > > Could the KafkaConsumer processor keep track of it's position so that if it > is stopped and started again it can attempt to resume consuming from that > position? > If I have to restart nifi or rename the consumer processor I want to make > sure I don't miss any messages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NIFI-3438) Ability to link to a view in Nifi (process group, processor, etc...)
Nicholas Carenza created NIFI-3438: -- Summary: Ability to link to a view in Nifi (process group, processor, etc...) Key: NIFI-3438 URL: https://issues.apache.org/jira/browse/NIFI-3438 Project: Apache NiFi Issue Type: Improvement Components: Core UI Reporter: Nicholas Carenza Priority: Minor I would like to be able to share a link to a particular view in the Nifi UI. For example: #/ might just bring me to that processor, center it in view and reset the zoom. If it is a process group, it might go to it an bring all processors into view. #//config might then also bring up the configuration for that processor #//config/properties might then also set the tab to 'properties' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3426) Add ability to set JDBC properties via dynamic properties in DBCPConnectionPool
[ https://issues.apache.org/jira/browse/NIFI-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851990#comment-15851990 ] ASF subversion and git services commented on NIFI-3426: --- Commit 2d6d7710c776a4e5608f1da63eba9e8435f72506 in nifi's branch refs/heads/master from [~mattyb149] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=2d6d771 ] NIFI-3426: Add dynamic property support to DBCPConnectionPool Signed-off-by: James Wing This closes #1461. > Add ability to set JDBC properties via dynamic properties in > DBCPConnectionPool > --- > > Key: NIFI-3426 > URL: https://issues.apache.org/jira/browse/NIFI-3426 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Minor > > Although many JDBC drivers allow for the setting of connection-specific > properties via the JDBC URL, some JDBC drivers only accept specific > configuration properties for a connection via programmatic calls to add > properties to the Connection object; those same properties will not be parsed > from the URL. > In general, a proposed improvement is to add support for Dynamic Properties > to the DBCPConnectionPool controller service. Each dynamic property would be > set as a property on the DataSource when the controller service is enabled. > Note that Expression Language can be supported, but as no flow file will be > available at enable-time, flow file attributes cannot be used in EL > expressions. However the Variable Registry could be leveraged to provide > different values in different environments (dev, test, production, e.g.). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3426) Add ability to set JDBC properties via dynamic properties in DBCPConnectionPool
[ https://issues.apache.org/jira/browse/NIFI-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851991#comment-15851991 ] ASF GitHub Bot commented on NIFI-3426: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1461 > Add ability to set JDBC properties via dynamic properties in > DBCPConnectionPool > --- > > Key: NIFI-3426 > URL: https://issues.apache.org/jira/browse/NIFI-3426 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Minor > > Although many JDBC drivers allow for the setting of connection-specific > properties via the JDBC URL, some JDBC drivers only accept specific > configuration properties for a connection via programmatic calls to add > properties to the Connection object; those same properties will not be parsed > from the URL. > In general, a proposed improvement is to add support for Dynamic Properties > to the DBCPConnectionPool controller service. Each dynamic property would be > set as a property on the DataSource when the controller service is enabled. > Note that Expression Language can be supported, but as no flow file will be > available at enable-time, flow file attributes cannot be used in EL > expressions. However the Variable Registry could be leveraged to provide > different values in different environments (dev, test, production, e.g.). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi pull request #1461: NIFI-3426: Add dynamic property support to DBCPConn...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1461 --- 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] [Created] (NIFI-3437) KafkaConsumer pause/resume
Nicholas Carenza created NIFI-3437: -- Summary: KafkaConsumer pause/resume Key: NIFI-3437 URL: https://issues.apache.org/jira/browse/NIFI-3437 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: Nicholas Carenza Could the KafkaConsumer processor keep track of it's position so that if it is stopped and started again it can attempt to resume consuming from that position? If I have to restart nifi or rename the consumer processor I want to make sure I don't miss any messages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3426) Add ability to set JDBC properties via dynamic properties in DBCPConnectionPool
[ https://issues.apache.org/jira/browse/NIFI-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851964#comment-15851964 ] ASF GitHub Bot commented on NIFI-3426: -- Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1461 @mattyb149 This looks very good, I will merge. Thanks for adding this feature. > Add ability to set JDBC properties via dynamic properties in > DBCPConnectionPool > --- > > Key: NIFI-3426 > URL: https://issues.apache.org/jira/browse/NIFI-3426 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Minor > > Although many JDBC drivers allow for the setting of connection-specific > properties via the JDBC URL, some JDBC drivers only accept specific > configuration properties for a connection via programmatic calls to add > properties to the Connection object; those same properties will not be parsed > from the URL. > In general, a proposed improvement is to add support for Dynamic Properties > to the DBCPConnectionPool controller service. Each dynamic property would be > set as a property on the DataSource when the controller service is enabled. > Note that Expression Language can be supported, but as no flow file will be > available at enable-time, flow file attributes cannot be used in EL > expressions. However the Variable Registry could be leveraged to provide > different values in different environments (dev, test, production, e.g.). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi issue #1461: NIFI-3426: Add dynamic property support to DBCPConnectionP...
Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1461 @mattyb149 This looks very good, I will merge. Thanks for adding this feature. --- 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-3408) Add an attribute for failure reason to InvokeHTTP in all cases to match docs
[ https://issues.apache.org/jira/browse/NIFI-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851900#comment-15851900 ] ASF GitHub Bot commented on NIFI-3408: -- Github user gglanzani commented on the issue: https://github.com/apache/nifi/pull/1467 I see the tests are failing here, but seemingly due to the npm registry. > Add an attribute for failure reason to InvokeHTTP in all cases to match docs > > > Key: NIFI-3408 > URL: https://issues.apache.org/jira/browse/NIFI-3408 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Priority: Minor > > Originally brought up on the mailing list[1], the InvokeHTTP docs state: > ``` > The original FlowFile will be routed on any type of connection failure, > timeout or general exception. It will have new attributes detailing the > request. > ``` > Adding attributes currently only happens though when a response is received > from the server, so not attributes if it fails to connect or the socket times > out. > These attributes should be added. > [1] > http://apache-nifi-users-list.2361937.n4.nabble.com/InvokeHTTP-and-SocketTimeoutException-td743.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi issue #1467: NIFI-3408 Add exception class when InvokeHTTP fails
Github user gglanzani commented on the issue: https://github.com/apache/nifi/pull/1467 I see the tests are failing here, but seemingly due to the npm registry. --- 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 #1461: NIFI-3426: Add dynamic property support to DBCPConnectionP...
Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1461 Reviewing... --- 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-3426) Add ability to set JDBC properties via dynamic properties in DBCPConnectionPool
[ https://issues.apache.org/jira/browse/NIFI-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851799#comment-15851799 ] ASF GitHub Bot commented on NIFI-3426: -- Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1461 Reviewing... > Add ability to set JDBC properties via dynamic properties in > DBCPConnectionPool > --- > > Key: NIFI-3426 > URL: https://issues.apache.org/jira/browse/NIFI-3426 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Minor > > Although many JDBC drivers allow for the setting of connection-specific > properties via the JDBC URL, some JDBC drivers only accept specific > configuration properties for a connection via programmatic calls to add > properties to the Connection object; those same properties will not be parsed > from the URL. > In general, a proposed improvement is to add support for Dynamic Properties > to the DBCPConnectionPool controller service. Each dynamic property would be > set as a property on the DataSource when the controller service is enabled. > Note that Expression Language can be supported, but as no flow file will be > available at enable-time, flow file attributes cannot be used in EL > expressions. However the Variable Registry could be leveraged to provide > different values in different environments (dev, test, production, e.g.). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi-minifi-cpp pull request #41: MINIFI-184: Add Security Support
Github user benqiu2016 commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/41#discussion_r99379332 --- Diff: cmake/FindOpenSSL.cmake --- @@ -0,0 +1,28 @@ +# OPENSSL_ROOT_DIR - Set this variable to the root installation of OpenSSL --- End diff -- if i do not provide that, build failed. --- 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 #1417: NIFI-3339 Add getDataSource() to DBCPService.
Github user ToivoAdams closed the pull request at: https://github.com/apache/nifi/pull/1417 --- 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-3339) Add getDataSource() to DBCPService
[ https://issues.apache.org/jira/browse/NIFI-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851695#comment-15851695 ] ASF GitHub Bot commented on NIFI-3339: -- Github user ToivoAdams closed the pull request at: https://github.com/apache/nifi/pull/1417 > Add getDataSource() to DBCPService > -- > > Key: NIFI-3339 > URL: https://issues.apache.org/jira/browse/NIFI-3339 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Toivo Adams >Assignee: Toivo Adams >Priority: Minor > > Currently DBCPService returns only Connection. > Sometimes DataSource is needed, for example Spring JdbcTemplate, > SimpleJdbcCall need DataSource. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NIFI-2881) Allow Database Fetch processor(s) to accept incoming flow files and use Expression Language
[ https://issues.apache.org/jira/browse/NIFI-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-2881: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Allow Database Fetch processor(s) to accept incoming flow files and use > Expression Language > --- > > Key: NIFI-2881 > URL: https://issues.apache.org/jira/browse/NIFI-2881 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess > Fix For: 1.2.0 > > > The QueryDatabaseTable and GenerateTableFetch processors do not allow > Expression Language to be used in the properties, mainly because they also do > not allow incoming connections. This means if the user desires to fetch from > multiple tables, they currently need one instance of the processor for each > table, and those table names must be hard-coded. > To support the same capabilities for multiple tables and more flexible > configuration via Expression Language, these processors should have > properties that accept Expression Language, and GenerateTableFetch should > accept (optional) incoming connections. > Conversation about the behavior of the processors is welcomed and encouraged. > For example, if an incoming flow file is available, do we also still run the > incremental fetch logic for tables that aren't specified by this flow file, > or do we just do incremental fetching when the processor is scheduled but > there is no incoming flow file. The latter implies a denial-of-service could > take place, by flooding the processor with flow files and not letting it do > its original job of querying the table, keeping track of maximum values, etc. > This is likely a breaking change to the processors because of how state > management is implemented. Currently since the table name is hard coded, only > the column name comprises the key in the state. This would have to be > extended to have a compound key that represents table name, max-value column > name, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NIFI-2881) Allow Database Fetch processor(s) to accept incoming flow files and use Expression Language
[ https://issues.apache.org/jira/browse/NIFI-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-2881: --- Fix Version/s: 1.2.0 > Allow Database Fetch processor(s) to accept incoming flow files and use > Expression Language > --- > > Key: NIFI-2881 > URL: https://issues.apache.org/jira/browse/NIFI-2881 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess > Fix For: 1.2.0 > > > The QueryDatabaseTable and GenerateTableFetch processors do not allow > Expression Language to be used in the properties, mainly because they also do > not allow incoming connections. This means if the user desires to fetch from > multiple tables, they currently need one instance of the processor for each > table, and those table names must be hard-coded. > To support the same capabilities for multiple tables and more flexible > configuration via Expression Language, these processors should have > properties that accept Expression Language, and GenerateTableFetch should > accept (optional) incoming connections. > Conversation about the behavior of the processors is welcomed and encouraged. > For example, if an incoming flow file is available, do we also still run the > incremental fetch logic for tables that aren't specified by this flow file, > or do we just do incremental fetching when the processor is scheduled but > there is no incoming flow file. The latter implies a denial-of-service could > take place, by flooding the processor with flow files and not letting it do > its original job of querying the table, keeping track of maximum values, etc. > This is likely a breaking change to the processors because of how state > management is implemented. Currently since the table name is hard coded, only > the column name comprises the key in the state. This would have to be > extended to have a compound key that represents table name, max-value column > name, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3055) StandardRecordWriter can throw UTFDataFormatException
[ https://issues.apache.org/jira/browse/NIFI-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851659#comment-15851659 ] ASF GitHub Bot commented on NIFI-3055: -- Github user jskora commented on the issue: https://github.com/apache/nifi/pull/1469 @mosermw I have updated the log message in both PRs. Thanks! > StandardRecordWriter can throw UTFDataFormatException > - > > Key: NIFI-3055 > URL: https://issues.apache.org/jira/browse/NIFI-3055 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 0.7.1 >Reporter: Brandon DeVries >Assignee: Joe Skora > > StandardRecordWriter.writeRecord()\[1] uses DataOutputStream.writeUTF()\[2] > without checking the length of the value to be written. If this length is > greater than 65535 (2^16 - 1), you get a UTFDataFormatException "encoded > string too long..."\[3]. Ultimately, this can result in an > IllegalStateException\[4], -bringing a halt to the data flow- causing > PersistentProvenanceRepository "Unable to merge with other > Journal Files due to..." WARNings. > Several of the field values being written in this way are pre-defined, and > thus not likely an issue. However, the "details" field can be populated by a > processor, and can be of an arbitrary length. -Additionally, if the detail > filed is indexed (which I didn't investigate, but I'm sure is easy enough to > determine), then the length might be subject to the Lucene limit discussed in > NIFI-2787-. > \[1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/StandardRecordWriter.java#L163-L173 > \[2] > http://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html#writeUTF%28java.lang.String%29 > \[3] > http://stackoverflow.com/questions/22741556/dataoutputstream-purpose-of-the-encoded-string-too-long-restriction > \[4] > https://github.com/apache/nifi/blob/5fd4a55791da27fdba577636ac985a294618328a/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L754-L755 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi issue #1469: NIFI-3055 StandardRecordWriter Can Throw UTFDataFormatExce...
Github user jskora commented on the issue: https://github.com/apache/nifi/pull/1469 @mosermw I have updated the log message in both PRs. Thanks! --- 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-3408) Add an attribute for failure reason to InvokeHTTP in all cases to match docs
[ https://issues.apache.org/jira/browse/NIFI-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851647#comment-15851647 ] ASF GitHub Bot commented on NIFI-3408: -- Github user gglanzani commented on the issue: https://github.com/apache/nifi/pull/1467 Hi @trixpan thanks for pushing me to write the test. It was very informative :) I've pushed an update. Could you take a look it it's what you were looking for? > Add an attribute for failure reason to InvokeHTTP in all cases to match docs > > > Key: NIFI-3408 > URL: https://issues.apache.org/jira/browse/NIFI-3408 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Priority: Minor > > Originally brought up on the mailing list[1], the InvokeHTTP docs state: > ``` > The original FlowFile will be routed on any type of connection failure, > timeout or general exception. It will have new attributes detailing the > request. > ``` > Adding attributes currently only happens though when a response is received > from the server, so not attributes if it fails to connect or the socket times > out. > These attributes should be added. > [1] > http://apache-nifi-users-list.2361937.n4.nabble.com/InvokeHTTP-and-SocketTimeoutException-td743.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi issue #1467: NIFI-3408 Add exception class when InvokeHTTP fails
Github user gglanzani commented on the issue: https://github.com/apache/nifi/pull/1467 Hi @trixpan thanks for pushing me to write the test. It was very informative :) I've pushed an update. Could you take a look it it's what you were looking for? --- 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] [Created] (NIFI-3436) Occasionally NiFi will indicate that it is not running when trying to stop the process
Mark Payne created NIFI-3436: Summary: Occasionally NiFi will indicate that it is not running when trying to stop the process Key: NIFI-3436 URL: https://issues.apache.org/jira/browse/NIFI-3436 Project: Apache NiFi Issue Type: Bug Components: Core Framework Reporter: Mark Payne Assignee: Mark Payne When I run "bin/nifi.sh stop" or "bin/nifi.sh restart" I occasionally see an error indicating that NiFi is not currently running. I can then run "ps -ef | grep nifi" and see the PID that is in the run/nifi.pid file, so it is clear that the Process is in fact running, but NiFi thinks it is not. When I look in logs/nifi-bootstrap.log I see: 2017-02-03 14:05:04,796 WARN [main] org.apache.nifi.bootstrap.RunNiFi Apache NiFi appears to have died. Restarting... 2017-02-03 14:05:04,940 ERROR [NiFi logging handler] org.apache.nifi.StdErr ERROR: transport error 202: bind failed: Address already in use 2017-02-03 14:05:04,941 ERROR [NiFi logging handler] org.apache.nifi.StdErr ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) 2017-02-03 14:05:04,941 ERROR [NiFi logging handler] org.apache.nifi.StdErr JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750] This was on a restart, hence the JDWP Transport dt_socket failed to initialize. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NIFI-3435) Allow Expression Language for "Trusted Hostname" attribute in the InvokeHTTP processor
Massimiliano Nigrelli created NIFI-3435:
---
Summary: Allow Expression Language for "Trusted Hostname"
attribute in the InvokeHTTP processor
Key: NIFI-3435
URL: https://issues.apache.org/jira/browse/NIFI-3435
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.0.0
Environment: CentOS7 on Virtualised VMs (OpenStack)
Reporter: Massimiliano Nigrelli
Priority: Minor
Attachments: JiraIssueInvokeHttpTrustedHostname.png
To whom it may concern,
I have the following issue: I use Nifi to retrieve some values from different
REST endpoints (HTTPS).
Well, in order to have something easily configurable, I have placed the URL of
each REST Service I need to access in a configuration file (one file per
endpoint). When it comes to configure the InvokeHTTPProcessor there is no way
to have the TrustedHostname varying depending on the configuration file as I
cannot use expression language.
In such a way I should need to duplicate the InvokeHTTP processor for a number
of times that is equal to all the endpoints from which I would need to retrieve
data from (as in the following example):
endpoint 1- IP of URL1 1st InvokeHttp -
TrsustedHostname for IP of URL1
endpoint N- IP of URLN Nth InvokeHttp -
TrsustedHostname for IP of URLN
I would rather have only one single InvokeHTTP processor istantiated:
endpoint 1- IP of URL1 InvokeHttp -
TrustedHostname = ${property}
endpoint N- IP of URLN InvokeHttp -
TrustedHostname = ${property}
Hope I have been clear,
Regards,
Massimiliano
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] nifi-minifi-cpp pull request #46: MINIFI-188: Incorporate CATCH and example ...
GitHub user phrocker opened a pull request: https://github.com/apache/nifi-minifi-cpp/pull/46 MINIFI-188: Incorporate CATCH and example tests This PR introduces catch and a few example tests. Additional tests will follow, but they currently cause several segfaults without a large number of corresponding changes in the code. Therefore to minimize the bootstrapping I will include the cmake changes in addition to the dep. to run type make; make test You can also run ./tests in the build directory for more information CATCH is Boost license, let me know if this is a problem. Thanks! You can merge this pull request into a Git repository by running: $ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFI-188-A Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi-cpp/pull/46.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 #46 commit b5a0cec0e681a0f2ed13331a036cbfd105103b1f Author: Marc Parisi Date: 2017-02-03T14:43:25Z MINIFI-188: Incorporate CATCH and example tests This PR introduces catch and a few example tests. Additional tests will follow, but they currently cause several segfaults without a large number of corresponding changes in the code. Therefore to minimize the bootstrapping I will include the cmake changes in addition to the dep. to run type make; make test --- 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 #1467: NIFI-3408 Add exception class when InvokeHTTP fails
Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1467 @gglanzani - thank you for the contribution. Code looks great but would it be possible for you to extend the test harness to include a test that will trigger your code(i.e. failure)? --- 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-3408) Add an attribute for failure reason to InvokeHTTP in all cases to match docs
[ https://issues.apache.org/jira/browse/NIFI-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851416#comment-15851416 ] ASF GitHub Bot commented on NIFI-3408: -- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1467 @gglanzani - thank you for the contribution. Code looks great but would it be possible for you to extend the test harness to include a test that will trigger your code(i.e. failure)? > Add an attribute for failure reason to InvokeHTTP in all cases to match docs > > > Key: NIFI-3408 > URL: https://issues.apache.org/jira/browse/NIFI-3408 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Priority: Minor > > Originally brought up on the mailing list[1], the InvokeHTTP docs state: > ``` > The original FlowFile will be routed on any type of connection failure, > timeout or general exception. It will have new attributes detailing the > request. > ``` > Adding attributes currently only happens though when a response is received > from the server, so not attributes if it fails to connect or the socket times > out. > These attributes should be added. > [1] > http://apache-nifi-users-list.2361937.n4.nabble.com/InvokeHTTP-and-SocketTimeoutException-td743.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-3434) nifi-assembly dependencies should allow users to skip the creation of ZIP and TAR.GZ packages
[ https://issues.apache.org/jira/browse/NIFI-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851393#comment-15851393 ] ASF GitHub Bot commented on NIFI-3434: -- GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1472 NIFI-3434 - Introduce the ability to skip the packaging of zip and ta… …r.gz archive via maven profile (i.e. -Pdir-only) Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [x] ~~Have you written or updated unit tests to verify your changes?~~ - [x] ~~If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ~~ - [x] ~~If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?~~ - [x] ~~If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?~~ - [x] ~~If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?~~ ### For documentation related changes: - [x] ~~Have you ensured that format looks appropriate for the output in which it is rendered?~~ ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-3434 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1472.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 #1472 commit 3d38205d44b5bd34d6f17082facad8bd6dafeac7 Author: Andre F de Miranda Date: 2017-02-03T11:51:55Z NIFI-3434 - Introduce the ability to skip the packaging of zip and tar.gz archive via maven profile (i.e. -Pdir-only) > nifi-assembly dependencies should allow users to skip the creation of ZIP and > TAR.GZ packages > - > > Key: NIFI-3434 > URL: https://issues.apache.org/jira/browse/NIFI-3434 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Andre >Assignee: Andre > > devs, > Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a > directory containing the same code. This leads to wasted disk space and a > lot of wasted disk writes (something that a lot of folks using SSDs prefer > to avoid). > Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a > "release" profile (or whatever name we agree to). This way we could > maintain the directory "format" (which I suspect most of us use during > development), while still providing a convenient way of creating the ZIP > and TAR.GZ packages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] nifi pull request #1472: NIFI-3434 - Introduce the ability to skip the packa...
GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1472 NIFI-3434 - Introduce the ability to skip the packaging of zip and ta⦠â¦r.gz archive via maven profile (i.e. -Pdir-only) Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [x] ~~Have you written or updated unit tests to verify your changes?~~ - [x] ~~If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ~~ - [x] ~~If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?~~ - [x] ~~If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?~~ - [x] ~~If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?~~ ### For documentation related changes: - [x] ~~Have you ensured that format looks appropriate for the output in which it is rendered?~~ ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-3434 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1472.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 #1472 commit 3d38205d44b5bd34d6f17082facad8bd6dafeac7 Author: Andre F de Miranda Date: 2017-02-03T11:51:55Z NIFI-3434 - Introduce the ability to skip the packaging of zip and tar.gz archive via maven profile (i.e. -Pdir-only) --- 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-3434) nifi-assembly dependencies should allow users to skip the creation of ZIP and TAR.GZ packages
[ https://issues.apache.org/jira/browse/NIFI-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851203#comment-15851203 ] Andre commented on NIFI-3434: - from list: I think this could be useful. Only caveat is that I'm sure there are folks in the community that have automated processes that make use of these binaries. >From the dev standpoint, I could see a profile that disables the assembly from happening such that the build occurs as it does now unless folks explicitly want to avoid it. Regardless of implementation, can see why it would be helpful. > nifi-assembly dependencies should allow users to skip the creation of ZIP and > TAR.GZ packages > - > > Key: NIFI-3434 > URL: https://issues.apache.org/jira/browse/NIFI-3434 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Andre >Assignee: Andre > > devs, > Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a > directory containing the same code. This leads to wasted disk space and a > lot of wasted disk writes (something that a lot of folks using SSDs prefer > to avoid). > Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a > "release" profile (or whatever name we agree to). This way we could > maintain the directory "format" (which I suspect most of us use during > development), while still providing a convenient way of creating the ZIP > and TAR.GZ packages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NIFI-3434) nifi-assembly dependencies should allow users to skip the creation of ZIP and TAR.GZ packages
Andre created NIFI-3434: --- Summary: nifi-assembly dependencies should allow users to skip the creation of ZIP and TAR.GZ packages Key: NIFI-3434 URL: https://issues.apache.org/jira/browse/NIFI-3434 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.1.1 Reporter: Andre Assignee: Andre devs, Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a directory containing the same code. This leads to wasted disk space and a lot of wasted disk writes (something that a lot of folks using SSDs prefer to avoid). Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a "release" profile (or whatever name we agree to). This way we could maintain the directory "format" (which I suspect most of us use during development), while still providing a convenient way of creating the ZIP and TAR.GZ packages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
