[jira] [Commented] (NIFI-4145) RouteOnAttribute doesn't document the attribute it writes
[ https://issues.apache.org/jira/browse/NIFI-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081636#comment-16081636 ] ASF GitHub Bot commented on NIFI-4145: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1998 > RouteOnAttribute doesn't document the attribute it writes > - > > Key: NIFI-4145 > URL: https://issues.apache.org/jira/browse/NIFI-4145 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Reporter: Joseph Percivall >Assignee: Mans Singh >Priority: Trivial > > RouteOnAttribute writes "RouteOnAttribute.Route" for the relationship it > routes the flowfile to[1]. This is not listed as an annotation[2] and it > should be. > [1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L263 > [2] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L70 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (NIFI-4145) RouteOnAttribute doesn't document the attribute it writes
[ https://issues.apache.org/jira/browse/NIFI-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Wing resolved NIFI-4145. -- Resolution: Fixed Fix Version/s: 1.4.0 > RouteOnAttribute doesn't document the attribute it writes > - > > Key: NIFI-4145 > URL: https://issues.apache.org/jira/browse/NIFI-4145 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Reporter: Joseph Percivall >Assignee: Mans Singh >Priority: Trivial > Fix For: 1.4.0 > > > RouteOnAttribute writes "RouteOnAttribute.Route" for the relationship it > routes the flowfile to[1]. This is not listed as an annotation[2] and it > should be. > [1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L263 > [2] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L70 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4145) RouteOnAttribute doesn't document the attribute it writes
[ https://issues.apache.org/jira/browse/NIFI-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081635#comment-16081635 ] ASF subversion and git services commented on NIFI-4145: --- Commit 0fd51b4d12d65abbaad02c88c42c30d015b5d653 in nifi's branch refs/heads/master from [~mans2singh] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=0fd51b4 ] NIFI-4145 Added writes attributes annotation Signed-off-by: James WingThis closes #1998. > RouteOnAttribute doesn't document the attribute it writes > - > > Key: NIFI-4145 > URL: https://issues.apache.org/jira/browse/NIFI-4145 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Reporter: Joseph Percivall >Assignee: Mans Singh >Priority: Trivial > > RouteOnAttribute writes "RouteOnAttribute.Route" for the relationship it > routes the flowfile to[1]. This is not listed as an annotation[2] and it > should be. > [1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L263 > [2] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L70 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4145) RouteOnAttribute doesn't document the attribute it writes
[ https://issues.apache.org/jira/browse/NIFI-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081638#comment-16081638 ] ASF GitHub Bot commented on NIFI-4145: -- Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1998 @mans2singh Looks good, thanks for taking the time to fix this. > RouteOnAttribute doesn't document the attribute it writes > - > > Key: NIFI-4145 > URL: https://issues.apache.org/jira/browse/NIFI-4145 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Reporter: Joseph Percivall >Assignee: Mans Singh >Priority: Trivial > Fix For: 1.4.0 > > > RouteOnAttribute writes "RouteOnAttribute.Route" for the relationship it > routes the flowfile to[1]. This is not listed as an annotation[2] and it > should be. > [1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L263 > [2] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L70 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1998: NIFI-4145 Added missing write attribute annotation
Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1998 @mans2singh Looks good, thanks for taking the time to fix this. --- 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 #1998: NIFI-4145 Added missing write attribute annotation
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1998 --- 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-4145) RouteOnAttribute doesn't document the attribute it writes
[ https://issues.apache.org/jira/browse/NIFI-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081626#comment-16081626 ] ASF GitHub Bot commented on NIFI-4145: -- Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1998 Reviewing... > RouteOnAttribute doesn't document the attribute it writes > - > > Key: NIFI-4145 > URL: https://issues.apache.org/jira/browse/NIFI-4145 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Reporter: Joseph Percivall >Assignee: Mans Singh >Priority: Trivial > > RouteOnAttribute writes "RouteOnAttribute.Route" for the relationship it > routes the flowfile to[1]. This is not listed as an annotation[2] and it > should be. > [1] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L263 > [2] > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RouteOnAttribute.java#L70 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1998: NIFI-4145 Added missing write attribute annotation
Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/1998 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-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081601#comment-16081601 ] Y Wikander commented on NIFI-4170: -- I'm challenged to agree to just 'yield' under the single condition set you requested. >From what I can tell, the other reasons for failure are related to bad >configuration of the PutWebSocket processor; related to Broadcast support. And >that they won't go away until a human fixes it. > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings > > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings. > I'm assuming that calling content.yield() will also cover 'Penalty duration'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081570#comment-16081570 ] Y Wikander commented on NIFI-4169: -- I think that it might be a bit more than I planned on chewing. Looking at PutFTP, PutSFTP, PublishAMQP, PublishMQTT they all use 'failure' as a "can't send to the destination". And it's what the non-broadcasting section of the processor does. What makes broadcasting different? In practice, would one really be broadcasting to a list that contained more than one? As this part I'm hazy on. When does a list come into play? Re the code comments: 1. From testing; the list becomes empty for a while, before it's added to again. I presumed that the ConnectWebSocket closed the session after it's timeout interval, then opened it up again. Such that some flowfiles routed to 'success' even though they never were sent (because the for loop had nothing to do). 2. I could imagine trying to send to as many WebSocketSession entries that it could, and cache up different Exceptions. But then you have to pick which single Exception is more exceptional to report back. And, back to my question, would one really be broadcasting to a list under normal circumstances? > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-1655) create .gitattributes
[ https://issues.apache.org/jira/browse/NIFI-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081562#comment-16081562 ] ASF GitHub Bot commented on NIFI-1655: -- Github user jfrazee commented on the issue: https://github.com/apache/nifi/pull/1696 @trixpan I think there's a mistake in the last line of .gitattributes. It is missing the 'text' qualifier and just is the file pattern and then eol. Let me know if I've misunderstood; otherwise I'll +1 and I can fix it during the merge. > create .gitattributes > - > > Key: NIFI-1655 > URL: https://issues.apache.org/jira/browse/NIFI-1655 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Tony Kurc >Assignee: Andre F de Miranda >Priority: Minor > Labels: cross-platform, environment, git, line-endings > > Create a .gitattributes file for the repository for consistent build > environment, less dependent on individual environment settings > https://help.github.com/articles/dealing-with-line-endings/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1696: NIFI-1655 - Add .gitattributes to specifically define
Github user jfrazee commented on the issue: https://github.com/apache/nifi/pull/1696 @trixpan I think there's a mistake in the last line of .gitattributes. It is missing the 'text' qualifier and just is the file pattern and then eol. Let me know if I've misunderstood; otherwise I'll +1 and I can fix it during the 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] [Updated] (NIFI-1586) embedded zookeeper disk utilization grows unbounded
[ https://issues.apache.org/jira/browse/NIFI-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-1586: -- Status: Patch Available (was: Reopened) > embedded zookeeper disk utilization grows unbounded > --- > > Key: NIFI-1586 > URL: https://issues.apache.org/jira/browse/NIFI-1586 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0 > Environment: latest 0.5.1 release >Reporter: Matthew Clarke >Assignee: Jeff Storck > Fix For: 1.4.0 > > Attachments: ZK_Autopurge_Test.xml > > > Observed that embedded NiFi zookeeper disk utilization will grow unbounded. > Zookeeper will occasional create snapshots but at no time will it ever purge > any of those snapshots it creates. This behavior is documented here: > https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_administering > It is the operators responsibility to purge old snapshot files. NiFi needs to > provide a configuration that will automate this pruge. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-1586) embedded zookeeper disk utilization grows unbounded
[ https://issues.apache.org/jira/browse/NIFI-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081098#comment-16081098 ] ASF GitHub Bot commented on NIFI-1586: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2001 Will review... > embedded zookeeper disk utilization grows unbounded > --- > > Key: NIFI-1586 > URL: https://issues.apache.org/jira/browse/NIFI-1586 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0 > Environment: latest 0.5.1 release >Reporter: Matthew Clarke >Assignee: Jeff Storck > Fix For: 1.4.0 > > Attachments: ZK_Autopurge_Test.xml > > > Observed that embedded NiFi zookeeper disk utilization will grow unbounded. > Zookeeper will occasional create snapshots but at no time will it ever purge > any of those snapshots it creates. This behavior is documented here: > https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_administering > It is the operators responsibility to purge old snapshot files. NiFi needs to > provide a configuration that will automate this pruge. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #2001: NIFI-1586 Removed check for distributed ZK quorum before s...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2001 Will review... --- 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-2528) Update ListenHTTP to honor SSLContextService Protocols
[ https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080962#comment-16080962 ] ASF GitHub Bot commented on NIFI-2528: -- Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1986 @trkurc and @jskora : After working through a few test cases, I have a proposal i'd like your thoughts on. What if we allow the user to select any SSL protocol available through the UI, but throw an exception with a message explaining why if the processor doesn't support that protocol. In the ListenHTTP case, Jetty has some SSL protocols and ciphers disabled by default that may be available to the JVM. There are two reasons i wouldn't want to tweak ListenHTTP to allow any configured protocol. 1) It changes the processor behavior since those Jetty-disabled protocols wouldn't have worked previously anyway and 2) it possibly opens another can of worms with cipher suite configuration since Jetty has a set of ciphers disabled by default as well. Thoughts? > Update ListenHTTP to honor SSLContextService Protocols > -- > > Key: NIFI-2528 > URL: https://issues.apache.org/jira/browse/NIFI-2528 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.8.0, 0.7.1 >Reporter: Joe Skora >Assignee: Michael Hogue > > Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for > PostHTTP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1986 @trkurc and @jskora : After working through a few test cases, I have a proposal i'd like your thoughts on. What if we allow the user to select any SSL protocol available through the UI, but throw an exception with a message explaining why if the processor doesn't support that protocol. In the ListenHTTP case, Jetty has some SSL protocols and ciphers disabled by default that may be available to the JVM. There are two reasons i wouldn't want to tweak ListenHTTP to allow any configured protocol. 1) It changes the processor behavior since those Jetty-disabled protocols wouldn't have worked previously anyway and 2) it possibly opens another can of worms with cipher suite configuration since Jetty has a set of ciphers disabled by default as well. Thoughts? --- 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-1586) embedded zookeeper disk utilization grows unbounded
[ https://issues.apache.org/jira/browse/NIFI-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080924#comment-16080924 ] ASF GitHub Bot commented on NIFI-1586: -- GitHub user jtstorck opened a pull request: https://github.com/apache/nifi/pull/2001 NIFI-1586 Removed check for distributed ZK quorum before starting the… … DatadirCleanupMananger to enable autopurge during standalone ZK server usage You can merge this pull request into a Git repository by running: $ git pull https://github.com/jtstorck/nifi NIFI-1586 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2001.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 #2001 commit 942e6cf1dbff42c00525ece24e89d450405f8ca7 Author: Jeff StorckDate: 2017-07-07T22:49:59Z NIFI-1586 Removed check for distributed ZK quorum before starting the DatadirCleanupMananger to enable autopurge during standalone ZK server usage > embedded zookeeper disk utilization grows unbounded > --- > > Key: NIFI-1586 > URL: https://issues.apache.org/jira/browse/NIFI-1586 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0 > Environment: latest 0.5.1 release >Reporter: Matthew Clarke >Assignee: Jeff Storck > Fix For: 1.4.0 > > Attachments: ZK_Autopurge_Test.xml > > > Observed that embedded NiFi zookeeper disk utilization will grow unbounded. > Zookeeper will occasional create snapshots but at no time will it ever purge > any of those snapshots it creates. This behavior is documented here: > https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_administering > It is the operators responsibility to purge old snapshot files. NiFi needs to > provide a configuration that will automate this pruge. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #2001: NIFI-1586 Removed check for distributed ZK quorum b...
GitHub user jtstorck opened a pull request: https://github.com/apache/nifi/pull/2001 NIFI-1586 Removed check for distributed ZK quorum before starting the⦠⦠DatadirCleanupMananger to enable autopurge during standalone ZK server usage You can merge this pull request into a Git repository by running: $ git pull https://github.com/jtstorck/nifi NIFI-1586 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2001.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 #2001 commit 942e6cf1dbff42c00525ece24e89d450405f8ca7 Author: Jeff StorckDate: 2017-07-07T22:49:59Z NIFI-1586 Removed check for distributed ZK quorum before starting the DatadirCleanupMananger to enable autopurge during standalone ZK server usage --- 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-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080843#comment-16080843 ] ASF GitHub Bot commented on NIFI-3939: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1999 Thanks @m-hogue! This has been merged to master. > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080844#comment-16080844 ] ASF GitHub Bot commented on NIFI-3939: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1999 > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080841#comment-16080841 ] ASF subversion and git services commented on NIFI-3939: --- Commit 78fbb8f2ee70d264787856e4a6337217bcfeba79 in nifi's branch refs/heads/master from m-hogue [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=78fbb8f ] NIFI-3939: Reviewed and corrected all incorrect nifi-web-api resource response types. This closes #1999 > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4167) Occasional deadlock when trying to clean up old Content Claims
[ https://issues.apache.org/jira/browse/NIFI-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080825#comment-16080825 ] ASF GitHub Bot commented on NIFI-4167: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1996 Thanks @markap14! This has been merged to master. > Occasional deadlock when trying to clean up old Content Claims > -- > > Key: NIFI-4167 > URL: https://issues.apache.org/jira/browse/NIFI-4167 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.4.0 > > > Occasionally we'll see the Content Repository stop cleaning up old claims. A > thread dump shows: > {code} > "FileSystemRepository Workers Thread-3" Id=97 BLOCKED on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.getClaimantCount(StandardResourceClaimManager.java:73) > > at > org.apache.nifi.controller.repository.claim.StandardResourceClaim.isInUse(StandardResourceClaim.java:120) > > at > org.apache.nifi.controller.repository.FileSystemRepository.remove(FileSystemRepository.java:612) > > at > org.apache.nifi.controller.repository.FileSystemRepository.access$1200(FileSystemRepository.java:83) > > at > org.apache.nifi.controller.repository.FileSystemRepository$ArchiveOrDestroyDestructableClaims.run(FileSystemRepository.java:1442) > > {code} > While another thread shows that it's being marked as Destructable: > {code} > "pool-10-thread-1" Id=132 TIMED_WAITING on > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@38063d7e > > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > > at > java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:385) > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.markDestructable(StandardResourceClaimManager.java:152) > > - waiting on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.markDestructable(WriteAheadFlowFileRepository.java:186) > > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.onGlobalSync(WriteAheadFlowFileRepository.java:287) > > at > org.wali.MinimalLockingWriteAheadLog.checkpoint(MinimalLockingWriteAheadLog.java:565) > > - waiting on org.wali.MinimalLockingWriteAheadLog@65ab87e4 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.checkpoint(WriteAheadFlowFileRepository.java:416) > > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4167) Occasional deadlock when trying to clean up old Content Claims
[ https://issues.apache.org/jira/browse/NIFI-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080822#comment-16080822 ] ASF subversion and git services commented on NIFI-4167: --- Commit 87e062ff557d18aa3f1f7e2906357c81236f0328 in nifi's branch refs/heads/master from [~markap14] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=87e062f ] NIFI-4167: StandardResourceClaimManager should not synchronize on a ResourceClaim in order to determine the claim count. This closes #1996 > Occasional deadlock when trying to clean up old Content Claims > -- > > Key: NIFI-4167 > URL: https://issues.apache.org/jira/browse/NIFI-4167 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.4.0 > > > Occasionally we'll see the Content Repository stop cleaning up old claims. A > thread dump shows: > {code} > "FileSystemRepository Workers Thread-3" Id=97 BLOCKED on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.getClaimantCount(StandardResourceClaimManager.java:73) > > at > org.apache.nifi.controller.repository.claim.StandardResourceClaim.isInUse(StandardResourceClaim.java:120) > > at > org.apache.nifi.controller.repository.FileSystemRepository.remove(FileSystemRepository.java:612) > > at > org.apache.nifi.controller.repository.FileSystemRepository.access$1200(FileSystemRepository.java:83) > > at > org.apache.nifi.controller.repository.FileSystemRepository$ArchiveOrDestroyDestructableClaims.run(FileSystemRepository.java:1442) > > {code} > While another thread shows that it's being marked as Destructable: > {code} > "pool-10-thread-1" Id=132 TIMED_WAITING on > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@38063d7e > > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > > at > java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:385) > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.markDestructable(StandardResourceClaimManager.java:152) > > - waiting on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.markDestructable(WriteAheadFlowFileRepository.java:186) > > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.onGlobalSync(WriteAheadFlowFileRepository.java:287) > > at > org.wali.MinimalLockingWriteAheadLog.checkpoint(MinimalLockingWriteAheadLog.java:565) > > - waiting on org.wali.MinimalLockingWriteAheadLog@65ab87e4 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.checkpoint(WriteAheadFlowFileRepository.java:416) > > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1999: NIFI-3939: Reviewed and corrected all incorrect nifi-web-a...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1999 Thanks @m-hogue! This has been 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. ---
[GitHub] nifi pull request #1999: NIFI-3939: Reviewed and corrected all incorrect nif...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1999 --- 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-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080838#comment-16080838 ] ASF GitHub Bot commented on NIFI-3939: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1999 Will review... > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1999: NIFI-3939: Reviewed and corrected all incorrect nifi-web-a...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1999 Will review... --- 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-4167) Occasional deadlock when trying to clean up old Content Claims
[ https://issues.apache.org/jira/browse/NIFI-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080824#comment-16080824 ] ASF GitHub Bot commented on NIFI-4167: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1996 > Occasional deadlock when trying to clean up old Content Claims > -- > > Key: NIFI-4167 > URL: https://issues.apache.org/jira/browse/NIFI-4167 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.4.0 > > > Occasionally we'll see the Content Repository stop cleaning up old claims. A > thread dump shows: > {code} > "FileSystemRepository Workers Thread-3" Id=97 BLOCKED on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.getClaimantCount(StandardResourceClaimManager.java:73) > > at > org.apache.nifi.controller.repository.claim.StandardResourceClaim.isInUse(StandardResourceClaim.java:120) > > at > org.apache.nifi.controller.repository.FileSystemRepository.remove(FileSystemRepository.java:612) > > at > org.apache.nifi.controller.repository.FileSystemRepository.access$1200(FileSystemRepository.java:83) > > at > org.apache.nifi.controller.repository.FileSystemRepository$ArchiveOrDestroyDestructableClaims.run(FileSystemRepository.java:1442) > > {code} > While another thread shows that it's being marked as Destructable: > {code} > "pool-10-thread-1" Id=132 TIMED_WAITING on > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@38063d7e > > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > > at > java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:385) > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.markDestructable(StandardResourceClaimManager.java:152) > > - waiting on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.markDestructable(WriteAheadFlowFileRepository.java:186) > > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.onGlobalSync(WriteAheadFlowFileRepository.java:287) > > at > org.wali.MinimalLockingWriteAheadLog.checkpoint(MinimalLockingWriteAheadLog.java:565) > > - waiting on org.wali.MinimalLockingWriteAheadLog@65ab87e4 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.checkpoint(WriteAheadFlowFileRepository.java:416) > > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4167) Occasional deadlock when trying to clean up old Content Claims
[ https://issues.apache.org/jira/browse/NIFI-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-4167: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Occasional deadlock when trying to clean up old Content Claims > -- > > Key: NIFI-4167 > URL: https://issues.apache.org/jira/browse/NIFI-4167 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.4.0 > > > Occasionally we'll see the Content Repository stop cleaning up old claims. A > thread dump shows: > {code} > "FileSystemRepository Workers Thread-3" Id=97 BLOCKED on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.getClaimantCount(StandardResourceClaimManager.java:73) > > at > org.apache.nifi.controller.repository.claim.StandardResourceClaim.isInUse(StandardResourceClaim.java:120) > > at > org.apache.nifi.controller.repository.FileSystemRepository.remove(FileSystemRepository.java:612) > > at > org.apache.nifi.controller.repository.FileSystemRepository.access$1200(FileSystemRepository.java:83) > > at > org.apache.nifi.controller.repository.FileSystemRepository$ArchiveOrDestroyDestructableClaims.run(FileSystemRepository.java:1442) > > {code} > While another thread shows that it's being marked as Destructable: > {code} > "pool-10-thread-1" Id=132 TIMED_WAITING on > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@38063d7e > > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > > at > java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:385) > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.markDestructable(StandardResourceClaimManager.java:152) > > - waiting on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.markDestructable(WriteAheadFlowFileRepository.java:186) > > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.onGlobalSync(WriteAheadFlowFileRepository.java:287) > > at > org.wali.MinimalLockingWriteAheadLog.checkpoint(MinimalLockingWriteAheadLog.java:565) > > - waiting on org.wali.MinimalLockingWriteAheadLog@65ab87e4 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.checkpoint(WriteAheadFlowFileRepository.java:416) > > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1996: NIFI-4167: StandardResourceClaimManager should not ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1996 --- 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 #1996: NIFI-4167: StandardResourceClaimManager should not synchro...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1996 Thanks @markap14! This has been 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] [Commented] (NIFI-4167) Occasional deadlock when trying to clean up old Content Claims
[ https://issues.apache.org/jira/browse/NIFI-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080729#comment-16080729 ] ASF GitHub Bot commented on NIFI-4167: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1996 Will review... > Occasional deadlock when trying to clean up old Content Claims > -- > > Key: NIFI-4167 > URL: https://issues.apache.org/jira/browse/NIFI-4167 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Critical > Fix For: 1.4.0 > > > Occasionally we'll see the Content Repository stop cleaning up old claims. A > thread dump shows: > {code} > "FileSystemRepository Workers Thread-3" Id=97 BLOCKED on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.getClaimantCount(StandardResourceClaimManager.java:73) > > at > org.apache.nifi.controller.repository.claim.StandardResourceClaim.isInUse(StandardResourceClaim.java:120) > > at > org.apache.nifi.controller.repository.FileSystemRepository.remove(FileSystemRepository.java:612) > > at > org.apache.nifi.controller.repository.FileSystemRepository.access$1200(FileSystemRepository.java:83) > > at > org.apache.nifi.controller.repository.FileSystemRepository$ArchiveOrDestroyDestructableClaims.run(FileSystemRepository.java:1442) > > {code} > While another thread shows that it's being marked as Destructable: > {code} > "pool-10-thread-1" Id=132 TIMED_WAITING on > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@38063d7e > > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > > at > java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:385) > at > org.apache.nifi.controller.repository.claim.StandardResourceClaimManager.markDestructable(StandardResourceClaimManager.java:152) > > - waiting on > org.apache.nifi.controller.repository.claim.StandardResourceClaim@6b5aa020 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.markDestructable(WriteAheadFlowFileRepository.java:186) > > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.onGlobalSync(WriteAheadFlowFileRepository.java:287) > > at > org.wali.MinimalLockingWriteAheadLog.checkpoint(MinimalLockingWriteAheadLog.java:565) > > - waiting on org.wali.MinimalLockingWriteAheadLog@65ab87e4 > at > org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.checkpoint(WriteAheadFlowFileRepository.java:416) > > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1996: NIFI-4167: StandardResourceClaimManager should not synchro...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1996 Will review... --- 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-2528) Update ListenHTTP to honor SSLContextService Protocols
[ https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080684#comment-16080684 ] ASF GitHub Bot commented on NIFI-2528: -- Github user trkurc commented on the issue: https://github.com/apache/nifi/pull/1986 Joe and Mike, sort of to my point, and both of your comments reinforced it, it was counter intuitive that I could select a protocol, and have it not work or give an error message that was substantive. > Update ListenHTTP to honor SSLContextService Protocols > -- > > Key: NIFI-2528 > URL: https://issues.apache.org/jira/browse/NIFI-2528 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.8.0, 0.7.1 >Reporter: Joe Skora >Assignee: Michael Hogue > > Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for > PostHTTP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols
[ https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080696#comment-16080696 ] ASF GitHub Bot commented on NIFI-2528: -- Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1986 I'll track down error reporting. > Update ListenHTTP to honor SSLContextService Protocols > -- > > Key: NIFI-2528 > URL: https://issues.apache.org/jira/browse/NIFI-2528 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.8.0, 0.7.1 >Reporter: Joe Skora >Assignee: Michael Hogue > > Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for > PostHTTP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1986 I'll track down error reporting. --- 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-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080652#comment-16080652 ] Matt Gilman commented on NIFI-4172: --- Updating the fix version to 2.0.0 since the change will break backward compatibility. > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > Fix For: 2.0.0 > > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
Github user trkurc commented on the issue: https://github.com/apache/nifi/pull/1986 Joe and Mike, sort of to my point, and both of your comments reinforced it, it was counter intuitive that I could select a protocol, and have it not work or give an error message that was substantive. --- 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-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-4172: -- Fix Version/s: 2.0.0 > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > Fix For: 2.0.0 > > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080663#comment-16080663 ] ASF GitHub Bot commented on NIFI-4172: -- Github user m-hogue closed the pull request at: https://github.com/apache/nifi/pull/2000 > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > Fix For: 2.0.0 > > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080662#comment-16080662 ] ASF GitHub Bot commented on NIFI-4172: -- Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/2000 Closing, to be merged for 2.0.0. > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > Fix For: 2.0.0 > > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #2000: NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEn...
Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/2000 Closing, to be merged for 2.0.0. --- 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 #2000: NIFI-4172: renamed ClusteSummaryEntity to ClusterSu...
Github user m-hogue closed the pull request at: https://github.com/apache/nifi/pull/2000 --- 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-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080655#comment-16080655 ] ASF GitHub Bot commented on NIFI-4172: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2000 I've updated the fix version on the JIRA so we'll catch it for 2.0.0. Unfortunately, I cannot close the PR without a commit. Only the person that created the PR can do so. Do you mind closing? Thanks! > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > Fix For: 2.0.0 > > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #2000: NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEn...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2000 I've updated the fix version on the JIRA so we'll catch it for 2.0.0. Unfortunately, I cannot close the PR without a commit. Only the person that created the PR can do so. Do you mind closing? 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-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080626#comment-16080626 ] ASF GitHub Bot commented on NIFI-4172: -- Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/2000 Ah, okay. I'd thought the potential for this to be a breaking API change prior to making the fix, but I was thinking from a REST API perspective since the response type isn't part of a json response. Feel free to close this. It's fairly trivial, so it's easy to do again prior to a major release. Thanks! > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #2000: NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEn...
Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/2000 Ah, okay. I'd thought the potential for this to be a breaking API change prior to making the fix, but I was thinking from a REST API perspective since the response type isn't part of a json response. Feel free to close this. It's fairly trivial, so it's easy to do again prior to a major release. 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-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080618#comment-16080618 ] ASF GitHub Bot commented on NIFI-4172: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2000 Thanks for the PR @m-hogue. I almost made this fix myself awhile back and held off. Technically, this class is part of a domain model for the REST API. Folks should be able to use this model in conjunction with frameworks like Jersey or RestEasy to interact with the REST API. Because of this, we treat this as another public API and we don't introduce breaking changes outside of major releases. Fortunately, the typo is not visible to folks consuming the REST API without our DTO domain model (through curl for instance). > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #2000: NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEn...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2000 Thanks for the PR @m-hogue. I almost made this fix myself awhile back and held off. Technically, this class is part of a domain model for the REST API. Folks should be able to use this model in conjunction with frameworks like Jersey or RestEasy to interact with the REST API. Because of this, we treat this as another public API and we don't introduce breaking changes outside of major releases. Fortunately, the typo is not visible to folks consuming the REST API without our DTO domain model (through curl for instance). --- 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-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hogue reassigned NIFI-4172: --- Assignee: Michael Hogue > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4172) Typo in nifi-web-api Entity class name
[ https://issues.apache.org/jira/browse/NIFI-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080544#comment-16080544 ] ASF GitHub Bot commented on NIFI-4172: -- GitHub user m-hogue opened a pull request: https://github.com/apache/nifi/pull/2000 NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEntity Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/m-hogue/nifi NIFI-4172 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2000.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 #2000 commit e475e7175923bb03cde40076ce64a2648e5b62d6 Author: m-hogueDate: 2017-07-10T15:53:22Z NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEntity > Typo in nifi-web-api Entity class name > -- > > Key: NIFI-4172 > URL: https://issues.apache.org/jira/browse/NIFI-4172 > Project: Apache NiFi > Issue Type: Bug >Reporter: Michael Hogue >Assignee: Michael Hogue >Priority: Trivial > > There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This > should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-2162) InvokeHttp's underlying library for Digest Auth uses the Android logger
[ https://issues.apache.org/jira/browse/NIFI-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080557#comment-16080557 ] Joseph Percivall commented on NIFI-2162: Hello [~wpoates1], yeah we should have fixed this already. I'll have a PR submitted by next Monday > InvokeHttp's underlying library for Digest Auth uses the Android logger > --- > > Key: NIFI-2162 > URL: https://issues.apache.org/jira/browse/NIFI-2162 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall > > A user emailed the User mailing list with an issue that InvokeHttp was > failing due to not being able to find "android/util/Log"[1]. InvokeHttp uses > OkHttp and the library they recommend for digest authentication is > okhttp-digest[2]. Currently okhttp-digest assumes it's running on an Android > device and has access to the Android logger (OkHttp does not assume it's on > an Android device). > I raised an issue about it on the project's github page[3] and the creator > said he "Will change this soonish." > Once that is addressed, InvokeHttp will need to update the versions of OkHttp > and okhttp-digest. > [1] http://mail-archives.apache.org/mod_mbox/nifi-users/201606.mbox/browser > [2] https://github.com/square/okhttp/issues/205 > [3] https://github.com/rburgst/okhttp-digest/issues/13 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (NIFI-2162) InvokeHttp's underlying library for Digest Auth uses the Android logger
[ https://issues.apache.org/jira/browse/NIFI-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned NIFI-2162: -- Assignee: Joseph Percivall > InvokeHttp's underlying library for Digest Auth uses the Android logger > --- > > Key: NIFI-2162 > URL: https://issues.apache.org/jira/browse/NIFI-2162 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Joseph Percivall > > A user emailed the User mailing list with an issue that InvokeHttp was > failing due to not being able to find "android/util/Log"[1]. InvokeHttp uses > OkHttp and the library they recommend for digest authentication is > okhttp-digest[2]. Currently okhttp-digest assumes it's running on an Android > device and has access to the Android logger (OkHttp does not assume it's on > an Android device). > I raised an issue about it on the project's github page[3] and the creator > said he "Will change this soonish." > Once that is addressed, InvokeHttp will need to update the versions of OkHttp > and okhttp-digest. > [1] http://mail-archives.apache.org/mod_mbox/nifi-users/201606.mbox/browser > [2] https://github.com/square/okhttp/issues/205 > [3] https://github.com/rburgst/okhttp-digest/issues/13 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #2000: NIFI-4172: renamed ClusteSummaryEntity to ClusterSu...
GitHub user m-hogue opened a pull request: https://github.com/apache/nifi/pull/2000 NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEntity Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/m-hogue/nifi NIFI-4172 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2000.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 #2000 commit e475e7175923bb03cde40076ce64a2648e5b62d6 Author: m-hogueDate: 2017-07-10T15:53:22Z NIFI-4172: renamed ClusteSummaryEntity to ClusterSummaryEntity --- 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-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080523#comment-16080523 ] ASF GitHub Bot commented on NIFI-3939: -- GitHub user m-hogue opened a pull request: https://github.com/apache/nifi/pull/1999 NIFI-3939: Reviewed and corrected all incorrect nifi-web-api resource… … response types Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/m-hogue/nifi NIFI-3939 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1999.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 #1999 > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1999: NIFI-3939: Reviewed and corrected all incorrect nif...
GitHub user m-hogue opened a pull request: https://github.com/apache/nifi/pull/1999 NIFI-3939: Reviewed and corrected all incorrect nifi-web-api resource⦠⦠response types Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/m-hogue/nifi NIFI-3939 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1999.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 #1999 --- 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-minifi-cpp pull request #114: site2site port negotiation
Github user kevdoran commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/114#discussion_r126458724 --- Diff: libminifi/src/RemoteProcessorGroupPort.cpp --- @@ -150,6 +194,87 @@ void RemoteProcessorGroupPort::onTrigger(core::ProcessContext *context, core::Pr return; } +void RemoteProcessorGroupPort::refreshRemoteSite2SiteInfo() { + if (this->host_.empty() || this->port_ == -1 || this->protocol_.empty()) + return; + + std::string fullUrl = this->protocol_ + this->host_ + ":" + std::to_string(this->port_) + "/nifi-api/controller/"; --- End diff -- Thanks for posting that @benqiu2016. I learned something new about the NiFI REST API :). Are you planning to add support for default protocol ports? --- 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-minifi-cpp pull request #114: site2site port negotiation
Github user kevdoran commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/114#discussion_r126457339 --- Diff: libminifi/include/utils/HTTPUtils.h --- @@ -88,6 +90,40 @@ struct HTTPRequestResponse { }; +static void parse_url(std::string , std::string , int , std::string ) { --- End diff -- Sure, I think documentation of the YAML format is a good thing to have, and probably also a method comment on the interface for HTTPUtils for future developers to know what format the method expects to be passed. --- 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-4024) Create EvaluateRecordPath processor
[ https://issues.apache.org/jira/browse/NIFI-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080510#comment-16080510 ] ASF GitHub Bot commented on NIFI-4024: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/1961 @MikeThomsen thanks Mike... I added a couple of comments this morning, not sure if you saw those yet, but I think we're close. > Create EvaluateRecordPath processor > --- > > Key: NIFI-4024 > URL: https://issues.apache.org/jira/browse/NIFI-4024 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Steve Champagne >Priority: Minor > > With the new RecordPath DSL, it would be nice if there was a processor that > could pull fields into attributes of the flowfile based on a RecordPath. This > would be similar to the EvaluateJsonPath processor that currently exists, > except it could be used to pull fields from arbitrary record formats. My > current use case for it would be pulling fields out of Avro records while > skipping the steps of having to convert Avro to JSON, evaluate JsonPath, and > then converting back to Avro. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi-minifi-cpp issue #114: site2site port negotiation
Github user phrocker commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/114 Looks good, but am curious about the use of lock vs a stack based lock guard. What was the reason for 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-minifi-cpp pull request #114: site2site port negotiation
Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/114#discussion_r126455887 --- Diff: libminifi/src/RemoteProcessorGroupPort.cpp --- @@ -84,19 +107,41 @@ void RemoteProcessorGroupPort::initialize() { std::set relationships; relationships.insert(relation); setSupportedRelationships(relationships); + curl_global_init(CURL_GLOBAL_DEFAULT); + site2site_peer_mutex_.lock(); --- End diff -- why did you choose to use lock over a lock guard? --- 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-minifi-cpp pull request #114: site2site port negotiation
Github user phrocker commented on a diff in the pull request: https://github.com/apache/nifi-minifi-cpp/pull/114#discussion_r126455434 --- Diff: libminifi/src/RemoteProcessorGroupPort.cpp --- @@ -20,6 +20,9 @@ #include "../include/RemoteProcessorGroupPort.h" +#include +#include +#include --- End diff -- InvokeHTTP's sole responsibility is HTTP communications. I don't think the same translates to RemoteProcessGroupPort. --- 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-4024) Create EvaluateRecordPath processor
[ https://issues.apache.org/jira/browse/NIFI-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080490#comment-16080490 ] ASF GitHub Bot commented on NIFI-4024: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/1961 @bbende Updated. Let me know what you think when you get a chance. Thanks. > Create EvaluateRecordPath processor > --- > > Key: NIFI-4024 > URL: https://issues.apache.org/jira/browse/NIFI-4024 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Steve Champagne >Priority: Minor > > With the new RecordPath DSL, it would be nice if there was a processor that > could pull fields into attributes of the flowfile based on a RecordPath. This > would be similar to the EvaluateJsonPath processor that currently exists, > except it could be used to pull fields from arbitrary record formats. My > current use case for it would be pulling fields out of Avro records while > skipping the steps of having to convert Avro to JSON, evaluate JsonPath, and > then converting back to Avro. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1961: NIFI-4024 Added org.apache.nifi.hbase.PutHBaseRecord
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/1961 @bbende Updated. Let me know what you think when you get a chance. 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] [Created] (NIFI-4172) Typo in nifi-web-api Entity class name
Michael Hogue created NIFI-4172: --- Summary: Typo in nifi-web-api Entity class name Key: NIFI-4172 URL: https://issues.apache.org/jira/browse/NIFI-4172 Project: Apache NiFi Issue Type: Bug Reporter: Michael Hogue Priority: Trivial There's an Entity in {{nifi-web-api}} named {{ClusteSummaryEntity}}. This should be {{ClusterSummaryEntity}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hogue updated NIFI-3939: Description: In {{ProcessGroupResource.java}} annotations on the {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies the response as a {{ProcessorsEntity}} when it should be a {{ProcessGroupsEntity}}. Similar mismatches may exist in {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. (was: In {{ProcessGroupResource.java}} annotations on the {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies the response as a {{ProcessorsEntity}} when it should be a {{ProcessGroupsEntity}}. Similar mismatches may exist in {{FlowFileQueueResponse}}, {{FlowResource}}, and possibly other classes.) > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResource}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (NIFI-3939) Fix entity type mismatches in web API resource response types
[ https://issues.apache.org/jira/browse/NIFI-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hogue reassigned NIFI-3939: --- Assignee: Michael Hogue > Fix entity type mismatches in web API resource response types > -- > > Key: NIFI-3939 > URL: https://issues.apache.org/jira/browse/NIFI-3939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > In {{ProcessGroupResource.java}} annotations on the > {{/process-groups/\{id}/getProcessGroups}} endpoint incorrectly identifies > the response as a {{ProcessorsEntity}} when it should be a > {{ProcessGroupsEntity}}. Similar mismatches may exist in > {{FlowFileQueueResponse}}, {{FlowResource}}, and possibly other classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols
[ https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080411#comment-16080411 ] ASF GitHub Bot commented on NIFI-2528: -- Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1986 Jetty explicitly disables it as well. The default set of protocols disallowed by Jetty are {"SSL", "SSLv2", "SSLv2Hello", "SSLv3"} I'm happy to alter Jetty's default config, but should we encourage use of SSLv3? > Update ListenHTTP to honor SSLContextService Protocols > -- > > Key: NIFI-2528 > URL: https://issues.apache.org/jira/browse/NIFI-2528 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.8.0, 0.7.1 >Reporter: Joe Skora >Assignee: Michael Hogue > > Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for > PostHTTP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1986 Jetty explicitly disables it as well. The default set of protocols disallowed by Jetty are {"SSL", "SSLv2", "SSLv2Hello", "SSLv3"} I'm happy to alter Jetty's default config, but should we encourage use of SSLv3? --- 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-4024) Create EvaluateRecordPath processor
[ https://issues.apache.org/jira/browse/NIFI-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080369#comment-16080369 ] ASF GitHub Bot commented on NIFI-4024: -- Github user bbende commented on a diff in the pull request: https://github.com/apache/nifi/pull/1961#discussion_r126431845 --- Diff: nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/PutHBaseRecord.java --- @@ -207,6 +211,7 @@ public void onTrigger(final ProcessContext context, final ProcessSession session final String details = String.format("Put %d cells to HBase.", columns); session.getProvenanceReporter().send(flowFile, urls.get(0), details, sendMillis); session.getProvenanceReporter().send(flowFile, urls.get(1), details, sendMillis); --- End diff -- We still have two calls to send a provenance event, I think we can get rid of the second one, and then we still need to send an event before transferring to failure. > Create EvaluateRecordPath processor > --- > > Key: NIFI-4024 > URL: https://issues.apache.org/jira/browse/NIFI-4024 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Steve Champagne >Priority: Minor > > With the new RecordPath DSL, it would be nice if there was a processor that > could pull fields into attributes of the flowfile based on a RecordPath. This > would be similar to the EvaluateJsonPath processor that currently exists, > except it could be used to pull fields from arbitrary record formats. My > current use case for it would be pulling fields out of Avro records while > skipping the steps of having to convert Avro to JSON, evaluate JsonPath, and > then converting back to Avro. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4024) Create EvaluateRecordPath processor
[ https://issues.apache.org/jira/browse/NIFI-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080370#comment-16080370 ] ASF GitHub Bot commented on NIFI-4024: -- Github user bbende commented on a diff in the pull request: https://github.com/apache/nifi/pull/1961#discussion_r126431547 --- Diff: nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/PutHBaseRecord.java --- @@ -49,10 +51,12 @@ @InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED) @Tags({"hadoop", "hbase", "put", "record"}) @CapabilityDescription("Adds rows to HBase based on the contents of a flowfile using a configured record reader.") +@ReadsAttribute(attribute = "restart.index", description = "Reads restart.index when it needs to replay part of a record set that did not get into HBase.") +@WritesAttribute(attribute = "restart.index", description = "Writes restart.index when a batch fails to be insert into HBase") public class PutHBaseRecord extends AbstractPutHBase { protected static final PropertyDescriptor ROW_FIELD_NAME = new PropertyDescriptor.Builder() -.name("Row Identifier Field Name") +.name("Row Identifier Record Path") --- End diff -- I think I confused things here with my previous comment... If we made this property a record path then it requires more code later on to evaluate the record path against the record, which we aren't doing right now, so lets put this back to "Row Identifier Field Name". Sorry for the confusion. > Create EvaluateRecordPath processor > --- > > Key: NIFI-4024 > URL: https://issues.apache.org/jira/browse/NIFI-4024 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Steve Champagne >Priority: Minor > > With the new RecordPath DSL, it would be nice if there was a processor that > could pull fields into attributes of the flowfile based on a RecordPath. This > would be similar to the EvaluateJsonPath processor that currently exists, > except it could be used to pull fields from arbitrary record formats. My > current use case for it would be pulling fields out of Avro records while > skipping the steps of having to convert Avro to JSON, evaluate JsonPath, and > then converting back to Avro. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4024) Create EvaluateRecordPath processor
[ https://issues.apache.org/jira/browse/NIFI-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080371#comment-16080371 ] ASF GitHub Bot commented on NIFI-4024: -- Github user bbende commented on a diff in the pull request: https://github.com/apache/nifi/pull/1961#discussion_r126430219 --- Diff: nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/PutHBaseRecord.java --- @@ -295,13 +302,21 @@ protected PutFlowFile createPut(ProcessContext context, Record record, RecordSch if (name.equals(rowFieldName)) { continue; } -columns.add(new PutColumn(fam, clientService.toBytes(name), asBytes(name, schema.getField(name).get().getDataType().getFieldType(), record, asString))); +columns.add(new PutColumn(fam, clientService.toBytes(name), asBytes(name, + schema.getField(name).get().getDataType().getFieldType(), record, asString, complexFieldStrategy))); +} +String rowIdValue = record.getAsString(rowFieldName); +if (rowIdValue == null) { +throw new Exception(String.format("Row ID was null for flowfile with ID %s", flowFile.getAttribute("uuid"))); } -retVal = new PutFlowFile(tableName, clientService.toBytes(record.getAsString(rowFieldName)), columns, flowFile); +byte[] rowId = getRow(rowIdValue, fieldEncodingStrategy); --- End diff -- Should this be the "row encoding strategy" rather than the "field encoding strategy"? There's actually separate properties for these (FIELD_ENCODING_STRATEGY vs. ROW_ID_ENCODING_STRATEGY). > Create EvaluateRecordPath processor > --- > > Key: NIFI-4024 > URL: https://issues.apache.org/jira/browse/NIFI-4024 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Steve Champagne >Priority: Minor > > With the new RecordPath DSL, it would be nice if there was a processor that > could pull fields into attributes of the flowfile based on a RecordPath. This > would be similar to the EvaluateJsonPath processor that currently exists, > except it could be used to pull fields from arbitrary record formats. My > current use case for it would be pulling fields out of Avro records while > skipping the steps of having to convert Avro to JSON, evaluate JsonPath, and > then converting back to Avro. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1961: NIFI-4024 Added org.apache.nifi.hbase.PutHBaseRecor...
Github user bbende commented on a diff in the pull request: https://github.com/apache/nifi/pull/1961#discussion_r126431845 --- Diff: nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/PutHBaseRecord.java --- @@ -207,6 +211,7 @@ public void onTrigger(final ProcessContext context, final ProcessSession session final String details = String.format("Put %d cells to HBase.", columns); session.getProvenanceReporter().send(flowFile, urls.get(0), details, sendMillis); session.getProvenanceReporter().send(flowFile, urls.get(1), details, sendMillis); --- End diff -- We still have two calls to send a provenance event, I think we can get rid of the second one, and then we still need to send an event before transferring to 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. ---
[GitHub] nifi pull request #1961: NIFI-4024 Added org.apache.nifi.hbase.PutHBaseRecor...
Github user bbende commented on a diff in the pull request: https://github.com/apache/nifi/pull/1961#discussion_r126431547 --- Diff: nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/PutHBaseRecord.java --- @@ -49,10 +51,12 @@ @InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED) @Tags({"hadoop", "hbase", "put", "record"}) @CapabilityDescription("Adds rows to HBase based on the contents of a flowfile using a configured record reader.") +@ReadsAttribute(attribute = "restart.index", description = "Reads restart.index when it needs to replay part of a record set that did not get into HBase.") +@WritesAttribute(attribute = "restart.index", description = "Writes restart.index when a batch fails to be insert into HBase") public class PutHBaseRecord extends AbstractPutHBase { protected static final PropertyDescriptor ROW_FIELD_NAME = new PropertyDescriptor.Builder() -.name("Row Identifier Field Name") +.name("Row Identifier Record Path") --- End diff -- I think I confused things here with my previous comment... If we made this property a record path then it requires more code later on to evaluate the record path against the record, which we aren't doing right now, so lets put this back to "Row Identifier Field Name". Sorry for 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. ---
[GitHub] nifi pull request #1961: NIFI-4024 Added org.apache.nifi.hbase.PutHBaseRecor...
Github user bbende commented on a diff in the pull request: https://github.com/apache/nifi/pull/1961#discussion_r126430219 --- Diff: nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/PutHBaseRecord.java --- @@ -295,13 +302,21 @@ protected PutFlowFile createPut(ProcessContext context, Record record, RecordSch if (name.equals(rowFieldName)) { continue; } -columns.add(new PutColumn(fam, clientService.toBytes(name), asBytes(name, schema.getField(name).get().getDataType().getFieldType(), record, asString))); +columns.add(new PutColumn(fam, clientService.toBytes(name), asBytes(name, + schema.getField(name).get().getDataType().getFieldType(), record, asString, complexFieldStrategy))); +} +String rowIdValue = record.getAsString(rowFieldName); +if (rowIdValue == null) { +throw new Exception(String.format("Row ID was null for flowfile with ID %s", flowFile.getAttribute("uuid"))); } -retVal = new PutFlowFile(tableName, clientService.toBytes(record.getAsString(rowFieldName)), columns, flowFile); +byte[] rowId = getRow(rowIdValue, fieldEncodingStrategy); --- End diff -- Should this be the "row encoding strategy" rather than the "field encoding strategy"? There's actually separate properties for these (FIELD_ENCODING_STRATEGY vs. ROW_ID_ENCODING_STRATEGY). --- 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-3218) MockProcessSession should prevent transferring new FlowFile to input queue
[ https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080362#comment-16080362 ] ASF GitHub Bot commented on NIFI-3218: -- Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1988 I pushed the corrected assertion. Please let me know if there should be any additional changes. Thanks! > MockProcessSession should prevent transferring new FlowFile to input queue > -- > > Key: NIFI-3218 > URL: https://issues.apache.org/jira/browse/NIFI-3218 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.1.0, 0.8.0 >Reporter: Joe Skora >Assignee: Michael Hogue > > StandardProcessSession.transfer() throws an exception if called with a newly > created FlowFile and no relationship. MockProcessionSession should behave > similarly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1988: NIFI-3218: throw exception in MockProcessSession when tran...
Github user m-hogue commented on the issue: https://github.com/apache/nifi/pull/1988 I pushed the corrected assertion. Please let me know if there should be any additional changes. 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-2528) Update ListenHTTP to honor SSLContextService Protocols
[ https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080229#comment-16080229 ] ASF GitHub Bot commented on NIFI-2528: -- Github user jskora commented on the issue: https://github.com/apache/nifi/pull/1986 @trkurc Have you [enabled SSLv3](https://stackoverflow.com/questions/28236091/how-to-enable-ssl-3-in-java) in the JVM? It is disabled by default starting with [Java 8 Update 31](http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html) and [Java 7 Update 75](http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html)? > Update ListenHTTP to honor SSLContextService Protocols > -- > > Key: NIFI-2528 > URL: https://issues.apache.org/jira/browse/NIFI-2528 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.8.0, 0.7.1 >Reporter: Joe Skora >Assignee: Michael Hogue > > Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for > PostHTTP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
Github user jskora commented on the issue: https://github.com/apache/nifi/pull/1986 @trkurc Have you [enabled SSLv3](https://stackoverflow.com/questions/28236091/how-to-enable-ssl-3-in-java) in the JVM? It is disabled by default starting with [Java 8 Update 31](http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html) and [Java 7 Update 75](http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html)? --- 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 #1983: NiFi-2829: Add Date and Time Format Support for Put...
Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/1983#discussion_r126362972 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutSQL.java --- @@ -828,10 +833,50 @@ private void setParameter(final PreparedStatement stmt, final String attrName, f stmt.setBigDecimal(parameterIndex, new BigDecimal(parameterValue)); break; case Types.DATE: -stmt.setDate(parameterIndex, new Date(Long.parseLong(parameterValue))); +Date date; + +if (valueFormat.equals("")) { +if(LONG_PATTERN.matcher(parameterValue).matches()){ +date = new Date(Long.parseLong(parameterValue)); +}else { --- End diff -- We prefer to have a space here, like `} else {`. The existing code for TIMESTAMP has the similar code, too. --- 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 #1983: NiFi-2829: Add Date and Time Format Support for Put...
Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/1983#discussion_r126362595 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutSQL.java --- @@ -110,11 +113,13 @@ + "sql.args.1.value, sql.args.2.value, sql.args.3.value, and so on. The type of the sql.args.1.value Parameter is specified by the sql.args.1.type attribute."), @ReadsAttribute(attribute = "sql.args.N.format", description = "This attribute is always optional, but default options may not always work for your data. " + "Incoming FlowFiles are expected to be parametrized SQL statements. In some cases " -+ "a format option needs to be specified, currently this is only applicable for binary data types and timestamps. For binary data types " -+ "available options are 'ascii', 'base64' and 'hex'. In 'ascii' format each string character in your attribute value represents a single byte, this is the default format " -+ "and the format provided by Avro Processors. In 'base64' format your string is a Base64 encoded string. In 'hex' format the string is hex encoded with all " -+ "letters in upper case and no '0x' at the beginning. For timestamps, the format can be specified according to java.time.format.DateTimeFormatter." -+ "Customer and named patterns are accepted i.e. ('-MM-dd','ISO_OFFSET_DATE_TIME')") ++ "a format option needs to be specified, currently this is only applicable for binary data types, dates, times and timestamps. Binary Data Types (defaults to 'ascii') - " ++ "ascii: each string character in your attribute value represents a single byte. This is the format provided by Avro Processors. " ++ "base64: the string is a Base64 encoded string that can be decoded to bytes. " ++ "hex: the string is hex encoded with all letters in upper case and no '0x' at the beginning. " ++ "Dates/Times/Timestamps - " ++ "Date, Time and Timestamp formats all support both custom formats or named format ('-MM-dd','ISO_OFFSET_DATE_TIME') " ++ "as specified according to java.time.format.DateTimeFormatter.") --- End diff -- Nice documentation! How about adding default behavior as well? Such as "If not specified, a long value input is expected to be an unix epoch (milli seconds from 1970/1/1) or '-MM-dd' format is used." --- 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 #1983: NiFi-2829: Add Date and Time Format Support for Put...
Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/1983#discussion_r126360491 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutSQL.java --- @@ -828,10 +833,50 @@ private void setParameter(final PreparedStatement stmt, final String attrName, f stmt.setBigDecimal(parameterIndex, new BigDecimal(parameterValue)); break; case Types.DATE: -stmt.setDate(parameterIndex, new Date(Long.parseLong(parameterValue))); +Date date; + +if (valueFormat.equals("")) { +if(LONG_PATTERN.matcher(parameterValue).matches()){ +date = new Date(Long.parseLong(parameterValue)); +}else { +String dateFormatString = "-MM-dd"; +if (!valueFormat.isEmpty()) { --- End diff -- This condition won't be true as it already checks `valueFormat.equals("")` above. BTW, I personally prefer `isEmpty()` than `equals("")`. Existing code for TIMESTAMP uses `equals("")` though. --- 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 #1983: NiFi-2829: Add Date and Time Format Support for Put...
Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/1983#discussion_r126361121 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutSQL.java --- @@ -828,10 +833,50 @@ private void setParameter(final PreparedStatement stmt, final String attrName, f stmt.setBigDecimal(parameterIndex, new BigDecimal(parameterValue)); break; case Types.DATE: -stmt.setDate(parameterIndex, new Date(Long.parseLong(parameterValue))); +Date date; + +if (valueFormat.equals("")) { +if(LONG_PATTERN.matcher(parameterValue).matches()){ +date = new Date(Long.parseLong(parameterValue)); +}else { +String dateFormatString = "-MM-dd"; +if (!valueFormat.isEmpty()) { +dateFormatString = valueFormat; +} +SimpleDateFormat dateFormat = new SimpleDateFormat(dateFormatString); +java.util.Date parsedDate = dateFormat.parse(parameterValue); +date = new Date(parsedDate.getTime()); +} +} else { +final DateTimeFormatter dtFormatter = getDateTimeFormatter(valueFormat); +LocalDate parsedDate = LocalDate.parse(parameterValue, dtFormatter); +date = new Date(Date.from(parsedDate.atStartOfDay().atZone(ZoneId.systemDefault()).toInstant()).getTime()); +} + +stmt.setDate(parameterIndex, date); break; case Types.TIME: -stmt.setTime(parameterIndex, new Time(Long.parseLong(parameterValue))); +Time time; + +if (valueFormat.equals("")) { +if (LONG_PATTERN.matcher(parameterValue).matches()) { +time = new Time(Long.parseLong(parameterValue)); +} else { +String timeFormatString = "HH:mm:ss.SSS"; +if (!valueFormat.isEmpty()) { --- End diff -- Same as DATE, this won't be true. --- 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-2528) Update ListenHTTP to honor SSLContextService Protocols
[ https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080030#comment-16080030 ] ASF GitHub Bot commented on NIFI-2528: -- Github user trkurc commented on the issue: https://github.com/apache/nifi/pull/1986 It seems as though if I change to SSLv3, for example, that I am unable to POST. > Update ListenHTTP to honor SSLContextService Protocols > -- > > Key: NIFI-2528 > URL: https://issues.apache.org/jira/browse/NIFI-2528 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.8.0, 0.7.1 >Reporter: Joe Skora >Assignee: Michael Hogue > > Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for > PostHTTP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...
Github user trkurc commented on the issue: https://github.com/apache/nifi/pull/1986 It seems as though if I change to SSLv3, for example, that I am unable to POST. --- 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-4171) NIFI service wont start on secure cluster
Shreya Bhat created NIFI-4171: - Summary: NIFI service wont start on secure cluster Key: NIFI-4171 URL: https://issues.apache.org/jira/browse/NIFI-4171 Project: Apache NiFi Issue Type: Bug Reporter: Shreya Bhat Nifi service failed to start on a secure cluster after install of the service. The stderr shows : {code} Traceback (most recent call last): File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 313, in Master().execute() File "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py", line 329, in execute method(env) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 181, in start self.configure(env, is_starting = True) File "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py", line 119, in locking_configure original_configure(obj, *args, **kw) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 105, in configure params.nifi_properties = self.setup_keystore_truststore(is_starting, params, config_version_file) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 236, in setup_keystore_truststore updated_properties = self.run_toolkit_client(ca_client_dict, params.nifi_config_dir, params.jdk64_home, params.nifi_user, params.nifi_group, params.toolkit_tmp_dir, params.stack_support_toolkit_update) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 256, in run_toolkit_client raise Fail("Call to tls-toolkit encountered error: {0}".format(out)) resource_management.core.exceptions.Fail: Call to tls-toolkit encountered error: 2017/07/10 00:02:10 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from nat-r7-taws-hdfdeploy-1.openstacklocal:10443 2017/07/10 00:02:11 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=nat-r7-taws-hdfdeploy-4.openstacklocal,OU=NIFI from nat-r7-taws-hdfdeploy-1.openstacklocal:10443 Service client error: Connect to nat-r7-taws-hdfdeploy-1.openstacklocal:10443 [nat-r7-taws-hdfdeploy-1.openstacklocal/172.22.81.93] failed: Connection refused (Connection refused) Usage: tls-toolkit service [-h] [args] Services: standalone: Creates certificates and config files for nifi cluster. server: Acts as a Certificate Authority that can be used by clients to get Certificates client: Generates a private key and gets it signed by the certificate authority. Traceback (most recent call last): File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 313, in Master().execute() File "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py", line 329, in execute method(env) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 181, in start self.configure(env, is_starting = True) File "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py", line 119, in locking_configure original_configure(obj, *args, **kw) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 105, in configure params.nifi_properties = self.setup_keystore_truststore(is_starting, params, config_version_file) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 236, in setup_keystore_truststore updated_properties = self.run_toolkit_client(ca_client_dict, params.nifi_config_dir, params.jdk64_home, params.nifi_user, params.nifi_group, params.toolkit_tmp_dir, params.stack_support_toolkit_update) File "/var/lib/ambari-agent/cache/common-services/NIFI/1.0.0/package/scripts/nifi.py", line 256, in run_toolkit_client raise Fail("Call to tls-toolkit encountered error: {0}".format(out)) resource_management.core.exceptions.Fail: Call to tls-toolkit encountered error: 2017/07/10 00:02:18 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: Requesting new certificate from nat-r7-taws-hdfdeploy-1.openstacklocal:10443 2017/07/10 00:02:19 INFO [main] org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer: Requesting certificate with dn CN=nat-r7-taws-hdfdeploy-4.openstacklocal,OU=NIFI from nat-r7-taws-hdfdeploy-1.openstacklocal:10443 Service client error: Connect to nat-r7-taws-hdfdeploy-1.openstacklocal:10443 [nat-r7-taws-hdfdeploy-1.openstacklocal/172.22.81.93] failed: Connection refused (Connection refused) Usage: tls-toolkit service [-h] [args] Services: standalone: Creates certificates and config files for nifi cluster. server: Acts as a
[jira] [Commented] (NIFI-1613) ConvertJSONToSQL Drops Type Information
[ https://issues.apache.org/jira/browse/NIFI-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080009#comment-16080009 ] ASF GitHub Bot commented on NIFI-1613: -- Github user ijokarumawak commented on the issue: https://github.com/apache/nifi/pull/1976 @mattyb149 Thanks for your feedback. I added a conversion for numeric columns if the input JSON field is a boolean (true -> 0, false -> 1). Now boolean JSON value can be mapped to Oracle smoothly, this should make most users happier. Also, made automatic data truncation more defensive. When I looked at the data types, I sensed only string data types should be truncated and it's safer than specifying every types not to truncate. > ConvertJSONToSQL Drops Type Information > --- > > Key: NIFI-1613 > URL: https://issues.apache.org/jira/browse/NIFI-1613 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.4.1, 0.5.1 > Environment: Ubuntu 14.04 LTS >Reporter: Aaron Stephens >Assignee: Toivo Adams > Labels: ConvertJSONToSQL, Phoenix, SQL > > It appears that the ConvertJSONToSQL processor is turning Boolean (and > possibly Integer and Float) values into Strings. This is okay for some > drivers (like PostgreSQL) which can coerce a String back into a Boolean, but > it causes issues for others (specifically Phoenix in my case). > {noformat} > org.apache.phoenix.schema.ConstraintViolationException: > org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type > mismatch. VARCHAR cannot be coerced to BOOLEAN > at > org.apache.phoenix.schema.types.PDataType.throwConstraintViolationException(PDataType.java:282) > ~[na:na] > at > org.apache.phoenix.schema.types.PBoolean.toObject(PBoolean.java:136) ~[na:na] > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.setObject(PhoenixPreparedStatement.java:442) > ~[na:na] > at > org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166) > ~[na:na] > at > org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166) > ~[na:na] > at > org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:728) > ~[na:na] > at > org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:606) > ~[na:na] > at > org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:223) ~[na:na] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27) > ~[nifi-api-0.4.1.jar:0.4.1] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1146) > ~[nifi-framework-core-0.4.1.jar:0.4.1] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:139) > [nifi-framework-core-0.4.1.jar:0.4.1] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49) > [nifi-framework-core-0.4.1.jar:0.4.1] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119) > [nifi-framework-core-0.4.1.jar:0.4.1] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > [na:1.7.0_79] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) > [na:1.7.0_79] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > [na:1.7.0_79] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > [na:1.7.0_79] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [na:1.7.0_79] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [na:1.7.0_79] > at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79] > Caused by: org.apache.phoenix.schema.TypeMismatchException: ERROR 203 > (22005): Type mismatch. VARCHAR cannot be coerced to BOOLEAN > at > org.apache.phoenix.exception.SQLExceptionCode$1.newException(SQLExceptionCode.java:71) > ~[na:na] > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145) > ~[na:na] > ... 20 common frames omitted > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1976: NIFI-1613: Make use of column type correctly at ConvertJSO...
Github user ijokarumawak commented on the issue: https://github.com/apache/nifi/pull/1976 @mattyb149 Thanks for your feedback. I added a conversion for numeric columns if the input JSON field is a boolean (true -> 0, false -> 1). Now boolean JSON value can be mapped to Oracle smoothly, this should make most users happier. Also, made automatic data truncation more defensive. When I looked at the data types, I sensed only string data types should be truncated and it's safer than specifying every types not to truncate. --- 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-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079901#comment-16079901 ] Koji Kawamura commented on NIFI-4169: - Hi [~ywik] thanks for reporting and sharing your patch. I agree with the idea to improve PutWebSocket broadcasting behavior in failure scenarios. In order to do so, if we emit FlowFiles to 'failure' relationship with the failed session id as an FlowFile attribute, user would be able to construct a better error handling route. Also if we can provide a new processor property to specify whether emit such 'failure' FlowFiles or not would be better, for example 'Broadcast message error handling', options would be 'ignore failed' and 'emit FlowFiles to failure' and defaults to 'ignore failed'. How do you think? Let me post a few comments on your patch here as well: {code} --- a/nifi-nar-bundles/nifi-websocket-bundle/nifi-websocket-services-api/src/main/java/org/apache/nifi/websocket/WebSocketMessageRouter.java +++ b/nifi-nar-bundles/nifi-websocket-bundle/nifi-websocket-services-api/src/main/java/org/apache/nifi/websocket/WebSocketMessageRouter.java @@ -107,14 +107,13 @@ public class WebSocketMessageRouter { sendMessage.send(session); } else { //The sessionID is not specified so broadcast the message to all connected client sessions. -sessions.keySet().forEach(itrSessionId -> { -try { -final WebSocketSession session = getSessionOrFail(itrSessionId); -sendMessage.send(session); -} catch (IOException e) { -logger.warn("Failed to send message to session {} due to {}", itrSessionId, e, e); -} -}); // I'm not perfectly sure if this is a good idea for every use-cases to throw an Exception when there's no connected client. // For example, If it's just used to periodically share the latest status of something, it wouldn't be important if there's any connected client or not. +if (sessions.isEmpty()) { +throw new IOException("There are no connected client sessions"); +} +for (Map.Entryentry : sessions.entrySet()) { // I'd prefer catching the exception and let user to choose how they would like to handle. +final WebSocketSession session = getSessionOrFail(entry.getKey()); +sendMessage.send(session); +} } } {code} > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-1655) create .gitattributes
[ https://issues.apache.org/jira/browse/NIFI-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079927#comment-16079927 ] ASF GitHub Bot commented on NIFI-1655: -- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1696 @jfrazee? > create .gitattributes > - > > Key: NIFI-1655 > URL: https://issues.apache.org/jira/browse/NIFI-1655 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Tony Kurc >Assignee: Andre F de Miranda >Priority: Minor > Labels: cross-platform, environment, git, line-endings > > Create a .gitattributes file for the repository for consistent build > environment, less dependent on individual environment settings > https://help.github.com/articles/dealing-with-line-endings/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1696: NIFI-1655 - Add .gitattributes to specifically define
Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1696 @jfrazee? --- 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. ---