[jira] [Commented] (NIFI-4145) RouteOnAttribute doesn't document the attribute it writes

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread James Wing (JIRA)

 [ 
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

2017-07-10 Thread ASF subversion and git services (JIRA)

[ 
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 Wing 

This 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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread jvwing
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

2017-07-10 Thread asfgit
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread jvwing
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

2017-07-10 Thread Y Wikander (JIRA)

[ 
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

2017-07-10 Thread Y Wikander (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread jfrazee
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

2017-07-10 Thread Jeff Storck (JIRA)

 [ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread mcgilman
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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 Storck 
Date:   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...

2017-07-10 Thread jtstorck
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 Storck 
Date:   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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF subversion and git services (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF subversion and git services (JIRA)

[ 
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...

2017-07-10 Thread mcgilman
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...

2017-07-10 Thread asfgit
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread mcgilman
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread Matt Gilman (JIRA)

 [ 
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 ...

2017-07-10 Thread asfgit
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...

2017-07-10 Thread mcgilman
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread mcgilman
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread Matt Gilman (JIRA)

[ 
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...

2017-07-10 Thread trkurc
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

2017-07-10 Thread Matt Gilman (JIRA)

 [ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread mcgilman
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread mcgilman
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

2017-07-10 Thread Michael Hogue (JIRA)

 [ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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-hogue 
Date:   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

2017-07-10 Thread Joseph Percivall (JIRA)

[ 
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

2017-07-10 Thread Joseph Percivall (JIRA)

 [ 
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...

2017-07-10 Thread m-hogue
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-hogue 
Date:   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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread kevdoran
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

2017-07-10 Thread kevdoran
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread phrocker
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

2017-07-10 Thread phrocker
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

2017-07-10 Thread phrocker
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread MikeThomsen
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

2017-07-10 Thread Michael Hogue (JIRA)
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

2017-07-10 Thread Michael Hogue (JIRA)

 [ 
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

2017-07-10 Thread Michael Hogue (JIRA)

 [ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread bbende
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...

2017-07-10 Thread bbende
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...

2017-07-10 Thread bbende
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread m-hogue
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread jskora
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...

2017-07-10 Thread ijokarumawak
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...

2017-07-10 Thread ijokarumawak
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...

2017-07-10 Thread ijokarumawak
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...

2017-07-10 Thread ijokarumawak
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread trkurc
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

2017-07-10 Thread Shreya Bhat (JIRA)
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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...

2017-07-10 Thread ijokarumawak
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

2017-07-10 Thread Koji Kawamura (JIRA)

[ 
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.Entry entry : 
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

2017-07-10 Thread ASF GitHub Bot (JIRA)

[ 
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

2017-07-10 Thread trixpan
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.
---