[jira] [Updated] (NIFI-4111) NiFi does not shutdown gracefully

[Koji Kawamura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Koji Kawamura updated NIFI-4111:

   Resolution: Fixed
Fix Version/s: 1.4.0
   Status: Resolved  (was: Patch Available)

> NiFi does not shutdown gracefully
> -
>
> Key: NIFI-4111
> URL: https://issues.apache.org/jira/browse/NIFI-4111
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
> Fix For: 1.4.0
>
>
> I don't know exactly for how long we have this issue but NiFi is not able to 
> shutdown gracefully anymore (standalone and cluster setups). It happens even 
> if no processor/CS/RT is running in the instance:
> {noformat}
> 2017-06-22 23:47:40,448 INFO [main] org.apache.nifi.bootstrap.Command Apache 
> NiFi has accepted the Shutdown Command and is shutting down now
> 2017-06-22 23:47:40,527 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:42,540 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:44,553 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:46,569 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:48,585 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:50,601 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:52,614 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:54,626 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:56,640 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:58,655 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,672 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,681 WARN [main] org.apache.nifi.bootstrap.Command NiFi 
> has not finished shutting down after 20 seconds. Killing process.
> 2017-06-22 23:48:00,714 INFO [main] org.apache.nifi.bootstrap.Command NiFi 
> has finished shutting down.
> {noformat}
> Thanks to [~markap14], the problem seems to be with shutting down the 
> following thread:
> {noformat}
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut 
> "Site-to-Site Worker Thread-1" #87 prio=5 os_prio=31 tid=0x7f9ec968c000 
> nid=0xeb03 waiting on condition [0x000137b4e000]
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Native Method)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Thread.java:340)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.socket.SocketChannelInputStream.read(SocketChannelInputStream.java:120)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.stream.io.ByteCountingInputStream.read(ByteCountingInputStream.java:51)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   - locked <0x0007be373b78> (a 
> org.apache.nifi.stream.io.BufferedInputStream)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.InterruptableInputStream.read(InterruptableInputStream.java:39)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:337)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.DataInputStream.readUTF(DataInputStream.java:589)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] 

[jira] [Commented] (NIFI-4111) NiFi does not shutdown gracefully

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077611#comment-16077611
 ] 

ASF GitHub Bot commented on NIFI-4111:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1963


> NiFi does not shutdown gracefully
> -
>
> Key: NIFI-4111
> URL: https://issues.apache.org/jira/browse/NIFI-4111
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
> Fix For: 1.4.0
>
>
> I don't know exactly for how long we have this issue but NiFi is not able to 
> shutdown gracefully anymore (standalone and cluster setups). It happens even 
> if no processor/CS/RT is running in the instance:
> {noformat}
> 2017-06-22 23:47:40,448 INFO [main] org.apache.nifi.bootstrap.Command Apache 
> NiFi has accepted the Shutdown Command and is shutting down now
> 2017-06-22 23:47:40,527 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:42,540 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:44,553 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:46,569 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:48,585 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:50,601 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:52,614 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:54,626 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:56,640 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:58,655 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,672 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,681 WARN [main] org.apache.nifi.bootstrap.Command NiFi 
> has not finished shutting down after 20 seconds. Killing process.
> 2017-06-22 23:48:00,714 INFO [main] org.apache.nifi.bootstrap.Command NiFi 
> has finished shutting down.
> {noformat}
> Thanks to [~markap14], the problem seems to be with shutting down the 
> following thread:
> {noformat}
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut 
> "Site-to-Site Worker Thread-1" #87 prio=5 os_prio=31 tid=0x7f9ec968c000 
> nid=0xeb03 waiting on condition [0x000137b4e000]
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Native Method)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Thread.java:340)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.socket.SocketChannelInputStream.read(SocketChannelInputStream.java:120)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.stream.io.ByteCountingInputStream.read(ByteCountingInputStream.java:51)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   - locked <0x0007be373b78> (a 
> org.apache.nifi.stream.io.BufferedInputStream)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.InterruptableInputStream.read(InterruptableInputStream.java:39)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:337)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.DataInputStream.readUTF(DataInputStream.java:589)
> 2017-06-21 16:23:35,160 INFO 

[jira] [Commented] (NIFI-4111) NiFi does not shutdown gracefully

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077609#comment-16077609
 ] 

ASF subversion and git services commented on NIFI-4111:
---

Commit 45f82dc855177702a0c1a0e4c38af334b713c278 in nifi's branch 
refs/heads/master from [~pvillard]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=45f82dc ]

NIFI-4111 - NiFi shutdown

Fixed threads shutdown so that NiFi can shutdown gracefully

NIFI-4111 - Review - Handling SocketRemoteSiteListener (RAW S2S)

This closes #1963.

Signed-off-by: Koji Kawamura 


> NiFi does not shutdown gracefully
> -
>
> Key: NIFI-4111
> URL: https://issues.apache.org/jira/browse/NIFI-4111
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
>
> I don't know exactly for how long we have this issue but NiFi is not able to 
> shutdown gracefully anymore (standalone and cluster setups). It happens even 
> if no processor/CS/RT is running in the instance:
> {noformat}
> 2017-06-22 23:47:40,448 INFO [main] org.apache.nifi.bootstrap.Command Apache 
> NiFi has accepted the Shutdown Command and is shutting down now
> 2017-06-22 23:47:40,527 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:42,540 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:44,553 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:46,569 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:48,585 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:50,601 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:52,614 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:54,626 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:56,640 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:58,655 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,672 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,681 WARN [main] org.apache.nifi.bootstrap.Command NiFi 
> has not finished shutting down after 20 seconds. Killing process.
> 2017-06-22 23:48:00,714 INFO [main] org.apache.nifi.bootstrap.Command NiFi 
> has finished shutting down.
> {noformat}
> Thanks to [~markap14], the problem seems to be with shutting down the 
> following thread:
> {noformat}
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut 
> "Site-to-Site Worker Thread-1" #87 prio=5 os_prio=31 tid=0x7f9ec968c000 
> nid=0xeb03 waiting on condition [0x000137b4e000]
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Native Method)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Thread.java:340)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.socket.SocketChannelInputStream.read(SocketChannelInputStream.java:120)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.stream.io.ByteCountingInputStream.read(ByteCountingInputStream.java:51)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   - locked <0x0007be373b78> (a 
> org.apache.nifi.stream.io.BufferedInputStream)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.InterruptableInputStream.read(InterruptableInputStream.java:39)
> 2017-06-21 16:23:35,160 

[GitHub] nifi pull request #1963: NIFI-4111 - NiFi shutdown

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1963


---
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-4111) NiFi does not shutdown gracefully

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077610#comment-16077610
 ] 

ASF subversion and git services commented on NIFI-4111:
---

Commit 45f82dc855177702a0c1a0e4c38af334b713c278 in nifi's branch 
refs/heads/master from [~pvillard]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=45f82dc ]

NIFI-4111 - NiFi shutdown

Fixed threads shutdown so that NiFi can shutdown gracefully

NIFI-4111 - Review - Handling SocketRemoteSiteListener (RAW S2S)

This closes #1963.

Signed-off-by: Koji Kawamura 


> NiFi does not shutdown gracefully
> -
>
> Key: NIFI-4111
> URL: https://issues.apache.org/jira/browse/NIFI-4111
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
>
> I don't know exactly for how long we have this issue but NiFi is not able to 
> shutdown gracefully anymore (standalone and cluster setups). It happens even 
> if no processor/CS/RT is running in the instance:
> {noformat}
> 2017-06-22 23:47:40,448 INFO [main] org.apache.nifi.bootstrap.Command Apache 
> NiFi has accepted the Shutdown Command and is shutting down now
> 2017-06-22 23:47:40,527 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:42,540 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:44,553 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:46,569 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:48,585 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:50,601 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:52,614 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:54,626 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:56,640 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:58,655 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,672 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,681 WARN [main] org.apache.nifi.bootstrap.Command NiFi 
> has not finished shutting down after 20 seconds. Killing process.
> 2017-06-22 23:48:00,714 INFO [main] org.apache.nifi.bootstrap.Command NiFi 
> has finished shutting down.
> {noformat}
> Thanks to [~markap14], the problem seems to be with shutting down the 
> following thread:
> {noformat}
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut 
> "Site-to-Site Worker Thread-1" #87 prio=5 os_prio=31 tid=0x7f9ec968c000 
> nid=0xeb03 waiting on condition [0x000137b4e000]
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Native Method)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Thread.java:340)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.socket.SocketChannelInputStream.read(SocketChannelInputStream.java:120)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.stream.io.ByteCountingInputStream.read(ByteCountingInputStream.java:51)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   - locked <0x0007be373b78> (a 
> org.apache.nifi.stream.io.BufferedInputStream)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.InterruptableInputStream.read(InterruptableInputStream.java:39)
> 2017-06-21 16:23:35,160 

[jira] [Commented] (NIFI-4111) NiFi does not shutdown gracefully

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077607#comment-16077607
 ] 

ASF GitHub Bot commented on NIFI-4111:
--

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1963
  
@pvillard31 Confirmed that NiFi shutdowns immediately. LGTM  1, thanks 
@pvillard31 ! merging to master..


> NiFi does not shutdown gracefully
> -
>
> Key: NIFI-4111
> URL: https://issues.apache.org/jira/browse/NIFI-4111
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
>
> I don't know exactly for how long we have this issue but NiFi is not able to 
> shutdown gracefully anymore (standalone and cluster setups). It happens even 
> if no processor/CS/RT is running in the instance:
> {noformat}
> 2017-06-22 23:47:40,448 INFO [main] org.apache.nifi.bootstrap.Command Apache 
> NiFi has accepted the Shutdown Command and is shutting down now
> 2017-06-22 23:47:40,527 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:42,540 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:44,553 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:46,569 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:48,585 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:50,601 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:52,614 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:54,626 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:56,640 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:47:58,655 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,672 INFO [main] org.apache.nifi.bootstrap.Command Waiting 
> for Apache NiFi to finish shutting down...
> 2017-06-22 23:48:00,681 WARN [main] org.apache.nifi.bootstrap.Command NiFi 
> has not finished shutting down after 20 seconds. Killing process.
> 2017-06-22 23:48:00,714 INFO [main] org.apache.nifi.bootstrap.Command NiFi 
> has finished shutting down.
> {noformat}
> Thanks to [~markap14], the problem seems to be with shutting down the 
> following thread:
> {noformat}
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut 
> "Site-to-Site Worker Thread-1" #87 prio=5 os_prio=31 tid=0x7f9ec968c000 
> nid=0xeb03 waiting on condition [0x000137b4e000]
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Native Method)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.lang.Thread.sleep(Thread.java:340)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.socket.SocketChannelInputStream.read(SocketChannelInputStream.java:120)
> 2017-06-21 16:23:35,159 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.stream.io.ByteCountingInputStream.read(ByteCountingInputStream.java:51)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   - locked <0x0007be373b78> (a 
> org.apache.nifi.stream.io.BufferedInputStream)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 
> org.apache.nifi.remote.io.InterruptableInputStream.read(InterruptableInputStream.java:39)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:337)
> 2017-06-21 16:23:35,160 INFO [NiFi logging handler] org.apache.nifi.StdOut
>   at 

[GitHub] nifi issue #1963: NIFI-4111 - NiFi shutdown

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1963
  
@pvillard31 Confirmed that NiFi shutdowns immediately. LGTM +1, thanks 
@pvillard31 ! merging 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-4112) ConvertExceltoCSV removes missing cells

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077581#comment-16077581
 ] 

ASF GitHub Bot commented on NIFI-4112:
--

Github user ijokarumawak commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1973#discussion_r126069842
  
--- Diff: 
nifi-nar-bundles/nifi-poi-bundle/nifi-poi-processors/src/test/resources/with-blank-cells.csv
 ---
@@ -0,0  1,8 @@
 A,B,C,D
--- End diff --

@m-hogue Thanks for your comment! If a row only contains empty cells, then 
it will be ignored. Since we're processing an Excel sheet as an XML document, 
such row wouldn't be passed to our code. Excel XML only contains rows and cells 
those have values.


> ConvertExceltoCSV removes missing cells
> ---
>
> Key: NIFI-4112
> URL: https://issues.apache.org/jira/browse/NIFI-4112
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Michael Boulter
>Assignee: Koji Kawamura
>Priority: Minor
> Attachments: 4146786940134586_Sheet1.csv, test.xlsx
>
>
> The ConvertExceltoCSV will remove missing cells from the CSV output.
> An input of {{TEST,,,TEST}} will become {{TEST,TEST}}
> Please see input and output attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1973: NIFI-4112: Fix ConvertExcelToCSV to handle empty ce...

[ijokarumawak]

Github user ijokarumawak commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1973#discussion_r126069842
  
--- Diff: 
nifi-nar-bundles/nifi-poi-bundle/nifi-poi-processors/src/test/resources/with-blank-cells.csv
 ---
@@ -0,0 +1,8 @@
+A,B,C,D
--- End diff --

@m-hogue Thanks for your comment! If a row only contains empty cells, then 
it will be ignored. Since we're processing an Excel sheet as an XML document, 
such row wouldn't be passed to our code. Excel XML only contains rows and cells 
those have values.


---
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-4155) Expand EnforceOrder capability to cluster

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077577#comment-16077577
 ] 

ASF GitHub Bot commented on NIFI-4155:
--

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1984
  
@JPercivall Thanks for your comment. Yes, I concerned about it may hammer 
Zk, too. But now we have [Redis backed state 
manager](https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-redis-bundle/nifi-redis-extensions/src/main/java/org/apache/nifi/redis/state)
 too. That can perform well compared to Zk. Also I wrote [doc for Cluster 
scope](https://github.com/apache/nifi/pull/1984/files#diff-64bdb3d4f3927cdfb538dd95975af65aR189)
 to use it only if necessary, it wouldn't be enough, though..

I think 'being able to do something if they know what they're doing' is 
better than not providing that option.


> Expand EnforceOrder capability to cluster
> -
>
> Key: NIFI-4155
> URL: https://issues.apache.org/jira/browse/NIFI-4155
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> Currently, EnforceOrder is able to enforce FlowFile ordering within a NiFi 
> node, and it uses local managed state to track progress.
> If it is configurable which state management to use from Local and Cluster, 
> EnforceOrder would be also able to enforce ordering across cluster with 
> cluster scope state management. It would be useful for some use-cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1984: NIFI-4155: Expand EnforceOrder capability to cluster

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1984
  
@JPercivall Thanks for your comment. Yes, I concerned about it may hammer 
Zk, too. But now we have [Redis backed state 
manager](https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-redis-bundle/nifi-redis-extensions/src/main/java/org/apache/nifi/redis/state)
 too. That can perform well compared to Zk. Also I wrote [doc for Cluster 
scope](https://github.com/apache/nifi/pull/1984/files#diff-64bdb3d4f3927cdfb538dd95975af65aR189)
 to use it only if necessary, it wouldn't be enough, though..

I think 'being able to do something if they know what they're doing' is 
better than not providing that option.


---
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 issue #114: site2site port negotiation

[benqiu2016]

Github user benqiu2016 commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/114
  
@phrocker please 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-3590) FetchSFTP Move Completion Strategy Remote Host Properties

[Koji Kawamura (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077457#comment-16077457
 ] 

Koji Kawamura commented on NIFI-3590:
-

The cause of this issue is the same as NIFI-3281, that the incoming FlowFile is 
not passed to getClient or getChannel methods, then EL is not evaluated as 
expected.

> FetchSFTP Move Completion Strategy Remote Host Properties
> -
>
> Key: NIFI-3590
> URL: https://issues.apache.org/jira/browse/NIFI-3590
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.1
> Environment: Debian Wheezy, jdk1.8
>Reporter: Marek Kovar
>  Labels: newbie
> Attachments: BulletinBoard.png, FlowDefinition.png, InputFlowfile 
> Attributes.png, Processor Properties.png
>
>
> There is an problem to use Move Completion strategy with remote host defined 
> using Expression Language.
> Eg. Port number defined using Expression language (${sftp.remote.port}) is 
> fine for the fetch itself, but for the file renaming it's causing following 
> error:
> {quote}
> 2017-03-13 15:58:06,181 ERROR [Timer-Driven Process Thread-6] 
> o.a.nifi.processors.standard.FetchSFTP
> java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_111]
> at java.lang.Integer.parseInt(Integer.java:592) ~[na:1.8.0_111]
> at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_111]
> at 
> org.apache.nifi.attribute.expression.language.StandardPropertyValue.asInteger(StandardPropertyValue.java:78)
>  ~[nifi-expression-language-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.util.SFTPTransfer.getChannel(SFTPTransfer.java:400)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.util.SFTPTransfer.rename(SFTPTransfer.java:608)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.FetchFileTransfer.onTrigger(FetchFileTransfer.java:316)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1974: NIFI-3281 - fix for (S)FTP processors when using EL...

[ijokarumawak]

Github user ijokarumawak commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1974#discussion_r126053317
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/util/FileTransfer.java
 ---
@@ -39,6 +39,8 @@
 
 void flush() throws IOException;
 
+boolean flush(FlowFile flowFile) throws IOException;
--- End diff --

Similar to `flush()`, other methods those use `getClient` (in FTPTransfer) 
or `getChannel` (in SFTPTransfer) should pass incoming FlowFile in order to 
evaluate EL properly. 
[NIFI-3590](https://issues.apache.org/jira/browse/NIFI-3590) is essentially the 
same to NIFI-3281 which is caused by not passing FlowFile.

Do we want to address it, too? Ideally, the codes `getClient(null)` and 
`getChannel(null)` should be removed completely.


---
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-3281) Error on passing 'ftp.listing.user' from ListFTP to FetchSFTP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077456#comment-16077456
 ] 

ASF GitHub Bot commented on NIFI-3281:
--

Github user ijokarumawak commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1974#discussion_r126052545
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListFileTransfer.java
 ---
@@ -94,7  94,7 @@
 
 @Override
 protected String getPath(final ProcessContext context) {
-return context.getProperty(REMOTE_PATH).getValue();
 return 
context.getProperty(REMOTE_PATH).evaluateAttributeExpressions().getValue();
--- End diff --

I think we should pass FlowFile to evaluate EL for REMOTE_PATH, too.


> Error on passing 'ftp.listing.user' from ListFTP to FetchSFTP
> -
>
> Key: NIFI-3281
> URL: https://issues.apache.org/jira/browse/NIFI-3281
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Jakhongir Ashrapov
>Assignee: Pierre Villard
>Priority: Minor
>
> Cannot get `ftp.listing.user` as EL in FetchFTP when listing files with 
> ListFTP. Following exception is thrown:
> IOException: Could not login for user ''



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1974: NIFI-3281 - fix for (S)FTP processors when using EL...

[ijokarumawak]

Github user ijokarumawak commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1974#discussion_r126052545
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListFileTransfer.java
 ---
@@ -94,7 +94,7 @@
 
 @Override
 protected String getPath(final ProcessContext context) {
-return context.getProperty(REMOTE_PATH).getValue();
+return 
context.getProperty(REMOTE_PATH).evaluateAttributeExpressions().getValue();
--- End diff --

I think we should pass FlowFile to evaluate EL for REMOTE_PATH, 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.
---

[jira] [Updated] (NIFI-4160) SFTPTransfer should specify connection timeout

[Koji Kawamura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Koji Kawamura updated NIFI-4160:

Status: Patch Available  (was: Open)

> SFTPTransfer should specify connection timeout
> --
>
> Key: NIFI-4160
> URL: https://issues.apache.org/jira/browse/NIFI-4160
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> For FTP/SFTP, we use com.jcraft.jsch library. When XXXSFTP processor make use 
> of the library, there are two occasions to set connection timeout. One is 
> connecting a session (Socket), and the other is opening a SFTP channel.
> Currently we set a connection timeout which can be specified via processor 
> property for connecting a session, but not for opening an SFTP channel.
> Then the library uses default 10ms x 2000 retry to open the channel. With 
> slow SFTP servers it's possible that opening channel takes longer than 10ms, 
> which can cause following error:
> {code}
> java.io.IOException: Failed to obtain connection to remote host due to 
> com.jcraft.jsch.JSchException: channel is not opened
> {code}
> We should specify connection timeout for opening channel as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4160) SFTPTransfer should specify connection timeout

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077430#comment-16077430
 ] 

ASF GitHub Bot commented on NIFI-4160:
--

GitHub user ijokarumawak opened a pull request:

https://github.com/apache/nifi/pull/1991

NIFI-4160: SFTPTransfer connection timeout for opening channel.

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] 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/ijokarumawak/nifi nifi-4160

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1991.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 #1991


commit 9eb88e25cf8e324a946cdf909366b0db78c2ec57
Author: Koji Kawamura 
Date:   2017-07-07T00:52:53Z

NIFI-4160: SFTPTransfer connection timeout for opening channel.




> SFTPTransfer should specify connection timeout
> --
>
> Key: NIFI-4160
> URL: https://issues.apache.org/jira/browse/NIFI-4160
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> For FTP/SFTP, we use com.jcraft.jsch library. When XXXSFTP processor make use 
> of the library, there are two occasions to set connection timeout. One is 
> connecting a session (Socket), and the other is opening a SFTP channel.
> Currently we set a connection timeout which can be specified via processor 
> property for connecting a session, but not for opening an SFTP channel.
> Then the library uses default 10ms x 2000 retry to open the channel. With 
> slow SFTP servers it's possible that opening channel takes longer than 10ms, 
> which can cause following error:
> {code}
> java.io.IOException: Failed to obtain connection to remote host due to 
> com.jcraft.jsch.JSchException: channel is not opened
> {code}
> We should specify connection timeout for opening channel as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1991: NIFI-4160: SFTPTransfer connection timeout for open...

[ijokarumawak]

GitHub user ijokarumawak opened a pull request:

https://github.com/apache/nifi/pull/1991

NIFI-4160: SFTPTransfer connection timeout for opening channel.

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] 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/ijokarumawak/nifi nifi-4160

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1991.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 #1991


commit 9eb88e25cf8e324a946cdf909366b0db78c2ec57
Author: Koji Kawamura 
Date:   2017-07-07T00:52:53Z

NIFI-4160: SFTPTransfer connection timeout for opening channel.




---
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 #1990: NIFI-4161: Adding expression evaluation to AWS PROX...

[kwydler]

GitHub user kwydler opened a pull request:

https://github.com/apache/nifi/pull/1990

NIFI-4161: Adding expression evaluation to AWS PROXY_HOST and 
PROXY_HOST_PORT property usage

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x ] Does your PR title start with NIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x ] Is your initial contribution a single, squashed commit?

### For code changes:
- [x ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] 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/kwydler/nifi NIFI-4161

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1990.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 #1990


commit 927afd69c73a5634361b0e8279dfb6820baeb074
Author: kwydler 
Date:   2017-07-07T00:41:10Z

NIFI-4161: Adding expression evaluation to AWS PROXY_HOST and 
PROXY_HOST_PORT property 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-4161) AWS Processors PROXY_HOST and PROXY_HOST_PORT properties do not support expression language

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077422#comment-16077422
 ] 

ASF GitHub Bot commented on NIFI-4161:
--

GitHub user kwydler opened a pull request:

https://github.com/apache/nifi/pull/1990

NIFI-4161: Adding expression evaluation to AWS PROXY_HOST and 
PROXY_HOST_PORT property usage

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x ] Does your PR title start with NIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x ] Is your initial contribution a single, squashed commit?

### For code changes:
- [x ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] 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/kwydler/nifi NIFI-4161

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1990.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 #1990


commit 927afd69c73a5634361b0e8279dfb6820baeb074
Author: kwydler 
Date:   2017-07-07T00:41:10Z

NIFI-4161: Adding expression evaluation to AWS PROXY_HOST and 
PROXY_HOST_PORT property usage




> AWS Processors PROXY_HOST and PROXY_HOST_PORT properties do not support 
> expression language
> ---
>
> Key: NIFI-4161
> URL: https://issues.apache.org/jira/browse/NIFI-4161
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Kenneth Wydler
>Priority: Minor
>
> AbstractAWSProcessor marks PROXY_HOST and PROXY_HOST_PORT properties as 
> supporting Nifi's expression language. However, when accessing the properties 
> values evaluateAttributeExpressions() is not called.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NIFI-4161) AWS Processors PROXY_HOST and PROXY_HOST_PORT properties do not support expression language

[Kenneth Wydler (JIRA)]

Kenneth Wydler created NIFI-4161:


 Summary: AWS Processors PROXY_HOST and PROXY_HOST_PORT properties 
do not support expression language
 Key: NIFI-4161
 URL: https://issues.apache.org/jira/browse/NIFI-4161
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Kenneth Wydler
Priority: Minor


AbstractAWSProcessor marks PROXY_HOST and PROXY_HOST_PORT properties as 
supporting Nifi's expression language. However, when accessing the properties 
values evaluateAttributeExpressions() is not called.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NIFI-4160) SFTPTransfer should specify connection timeout

[Koji Kawamura (JIRA)]

Koji Kawamura created NIFI-4160:
---

 Summary: SFTPTransfer should specify connection timeout
 Key: NIFI-4160
 URL: https://issues.apache.org/jira/browse/NIFI-4160
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.0.0
Reporter: Koji Kawamura
Assignee: Koji Kawamura


For FTP/SFTP, we use com.jcraft.jsch library. When XXXSFTP processor make use 
of the library, there are two occasions to set connection timeout. One is 
connecting a session (Socket), and the other is opening a SFTP channel.

Currently we set a connection timeout which can be specified via processor 
property for connecting a session, but not for opening an SFTP channel.
Then the library uses default 10ms x 2000 retry to open the channel. With slow 
SFTP servers it's possible that opening channel takes longer than 10ms, which 
can cause following error:

{code}
java.io.IOException: Failed to obtain connection to remote host due to 
com.jcraft.jsch.JSchException: channel is not opened
{code}

We should specify connection timeout for opening channel as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4057) Docker Image is twice as large as necessary

[Aldrin Piri (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077376#comment-16077376
 ] 

Aldrin Piri commented on NIFI-4057:
---

[~taftster] certainly.  currently on vacation but will put it on my list of 
items when I return next week.

> Docker Image is twice as large as necessary
> ---
>
> Key: NIFI-4057
> URL: https://issues.apache.org/jira/browse/NIFI-4057
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Docker
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Jordan Moore
>Priority: Minor
>
> By calling {{chown}} as a secondary {{RUN}} command, you effectively double 
> the size of image by creating a Docker layer of the same size as the 
> extracted binary. 
> See GitHub discussion: 
> https://github.com/apache/nifi/pull/1372#issuecomment-307592287
> *Expectation*
> The resultant Docker image should be no larger than the Base image + the size 
> required by extracting the Nifi binaries. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NIFI-4159) Changes to ReportingTask schedule are not audited

[Michael Hopton (JIRA)]

Michael Hopton created NIFI-4159:


 Summary: Changes to ReportingTask schedule are not audited
 Key: NIFI-4159
 URL: https://issues.apache.org/jira/browse/NIFI-4159
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Michael Hopton


Changing the Scheduling Strategy, Run Schedule or Comment of a reporting task 
does not generate an audit record in Flow Configuration History.

Equivalent changes on Processors do generate audit records.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4158) getFlowChanges operation does not match documentation

[Michael Hopton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Hopton updated NIFI-4158:
-
Component/s: (was: Documentation & Website)
 (was: Core Framework)

> getFlowChanges operation does not match documentation
> -
>
> Key: NIFI-4158
> URL: https://issues.apache.org/jira/browse/NIFI-4158
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Michael Hopton
>Priority: Minor
> Attachments: action.groovy
>
>
> getFlowChanges javadoc says:
> _Obtains flow changes starting with (and including) the given action ID. If 
> no action exists with that ID, the first action to be returned will have an 
> ID greater than firstActionId._
> However, it does not include the change with the firstActionId. Run attached 
> Groovy script in ScriptedReportingTask to demonstrate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NIFI-4158) getFlowChanges operation does not match documentation

[Michael Hopton (JIRA)]

Michael Hopton created NIFI-4158:


 Summary: getFlowChanges operation does not match documentation
 Key: NIFI-4158
 URL: https://issues.apache.org/jira/browse/NIFI-4158
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework, Documentation & Website
Affects Versions: 1.3.0
Reporter: Michael Hopton
Priority: Minor
 Attachments: action.groovy

getFlowChanges javadoc says:

_Obtains flow changes starting with (and including) the given action ID. If no 
action exists with that ID, the first action to be returned will have an ID 
greater than firstActionId._

However, it does not include the change with the firstActionId. Run attached 
Groovy script in ScriptedReportingTask to demonstrate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4157) Improve PutTCP

[Bryan Bende (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077132#comment-16077132
 ] 

Bryan Bende commented on NIFI-4157:
---

This ticket relates to the ListenTCPRecord processor in that these improvements 
allow PutTCP to stream large flow files of records to ListenTCPRecord.

> Improve PutTCP
> --
>
> Key: NIFI-4157
> URL: https://issues.apache.org/jira/browse/NIFI-4157
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>
> Currently PutTCP reads the entire content of a flow file into memory in a 
> ByteArrayOutputStream and then sends the bytes of the BAOS over the 
> connection. We should stream the flow file's InputStream to the socket's 
> OutputStream.
> We also should make the Outgoing Message Delimiter optional for cases where 
> the data is already in the desired format.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4157) Improve PutTCP

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4157:
--
Status: Patch Available  (was: Open)

> Improve PutTCP
> --
>
> Key: NIFI-4157
> URL: https://issues.apache.org/jira/browse/NIFI-4157
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>
> Currently PutTCP reads the entire content of a flow file into memory in a 
> ByteArrayOutputStream and then sends the bytes of the BAOS over the 
> connection. We should stream the flow file's InputStream to the socket's 
> OutputStream.
> We also should make the Outgoing Message Delimiter optional for cases where 
> the data is already in the desired format.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4157) Improve PutTCP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077129#comment-16077129
 ] 

ASF GitHub Bot commented on NIFI-4157:
--

GitHub user bbende opened a pull request:

https://github.com/apache/nifi/pull/1989

NIFI-4157 Improvements to PutTCP

- Expose the ChannelSender's OutputStream
- Use IOUtils to copy the flow file InputStream to the OutputStream
- Make Outgoing Message Delimiter optional and remove default value so it 
can be blank

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi NIFI-4157

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1989.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 #1989


commit f4a59559b1e22e96ba82b9992d3d770a24d242d9
Author: Bryan Bende 
Date:   2017-07-06T19:40:50Z

NIFI-4157 Improvements to PutTCP

Signed-off-by: Bryan Bende 




> Improve PutTCP
> --
>
> Key: NIFI-4157
> URL: https://issues.apache.org/jira/browse/NIFI-4157
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>
> Currently PutTCP reads the entire content of a flow file into memory in a 
> ByteArrayOutputStream and then sends the bytes of the BAOS over the 
> connection. We should stream the flow file's InputStream to the socket's 
> OutputStream.
> We also should make the Outgoing Message Delimiter optional for cases where 
> the data is already in the desired format.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1989: NIFI-4157 Improvements to PutTCP

[bbende]

GitHub user bbende opened a pull request:

https://github.com/apache/nifi/pull/1989

NIFI-4157 Improvements to PutTCP

- Expose the ChannelSender's OutputStream
- Use IOUtils to copy the flow file InputStream to the OutputStream
- Make Outgoing Message Delimiter optional and remove default value so it 
can be blank

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi NIFI-4157

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1989.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 #1989


commit f4a59559b1e22e96ba82b9992d3d770a24d242d9
Author: Bryan Bende 
Date:   2017-07-06T19:40:50Z

NIFI-4157 Improvements to PutTCP

Signed-off-by: Bryan Bende 




---
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-1763) Provide an integration with 'Schema registry for Kafka'

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077127#comment-16077127
 ] 

ASF GitHub Bot commented on NIFI-1763:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1938


> Provide an integration with 'Schema registry for Kafka'
> ---
>
> Key: NIFI-1763
> URL: https://issues.apache.org/jira/browse/NIFI-1763
> Project: Apache NiFi
>  Issue Type: Wish
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Mark Payne
>Priority: Minor
>
> Reported on a mailing list question on 13 April 2016
> https://github.com/confluentinc/schema-registry
> The registry itself is an ASLv2 licensed codebase.  It offers a REST-based 
> Web API for interaction.  It would be good to support integration with it for 
> users of Kafka so it would register schemas if needed when writing to Kafka 
> and understand how to parse data based on the indicated schema when reading 
> from Kafka.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1938: NIFI-1763: Initial implementation of ConfluentSchem...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1938


---
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-1763) Provide an integration with 'Schema registry for Kafka'

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077126#comment-16077126
 ] 

ASF subversion and git services commented on NIFI-1763:
---

Commit 3906d4e1d215f41cdf075ac23a63e9e740391b33 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=3906d4e ]

NIFI-1763: Initial implementation of ConfluentSchemaRegistry.
NIFI-1763: Fixed bug where the Confluent Schema Registry Schema Access Writer 
was not being created

Signed-off-by: Yolanda M. Davis 

This closes #1938


> Provide an integration with 'Schema registry for Kafka'
> ---
>
> Key: NIFI-1763
> URL: https://issues.apache.org/jira/browse/NIFI-1763
> Project: Apache NiFi
>  Issue Type: Wish
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Mark Payne
>Priority: Minor
>
> Reported on a mailing list question on 13 April 2016
> https://github.com/confluentinc/schema-registry
> The registry itself is an ASLv2 licensed codebase.  It offers a REST-based 
> Web API for interaction.  It would be good to support integration with it for 
> users of Kafka so it would register schemas if needed when writing to Kafka 
> and understand how to parse data based on the indicated schema when reading 
> from Kafka.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-1763) Provide an integration with 'Schema registry for Kafka'

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077125#comment-16077125
 ] 

ASF subversion and git services commented on NIFI-1763:
---

Commit 3906d4e1d215f41cdf075ac23a63e9e740391b33 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=3906d4e ]

NIFI-1763: Initial implementation of ConfluentSchemaRegistry.
NIFI-1763: Fixed bug where the Confluent Schema Registry Schema Access Writer 
was not being created

Signed-off-by: Yolanda M. Davis 

This closes #1938


> Provide an integration with 'Schema registry for Kafka'
> ---
>
> Key: NIFI-1763
> URL: https://issues.apache.org/jira/browse/NIFI-1763
> Project: Apache NiFi
>  Issue Type: Wish
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Mark Payne
>Priority: Minor
>
> Reported on a mailing list question on 13 April 2016
> https://github.com/confluentinc/schema-registry
> The registry itself is an ASLv2 licensed codebase.  It offers a REST-based 
> Web API for interaction.  It would be good to support integration with it for 
> users of Kafka so it would register schemas if needed when writing to Kafka 
> and understand how to parse data based on the indicated schema when reading 
> from Kafka.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4143) Make configurable maximum number of concurrent requests

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman updated NIFI-4143:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   Status: Resolved  (was: Patch Available)

> Make configurable maximum number of concurrent requests
> ---
>
> Key: NIFI-4143
> URL: https://issues.apache.org/jira/browse/NIFI-4143
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>  Labels: documentation
> Fix For: 1.4.0
>
>
> At the moment, the maximum number of concurrent requests is hard coded in 
> {{ThreadPoolRequestReplicator}}
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/http/replication/ThreadPoolRequestReplicator.java
> The value is equal to 100.
> In some situations where multiple factors are combined (large cluster, S2S to 
> load balance data in the cluster, multiple users accessing the UI), the limit 
> can be reached and the UI may become intermittently unavailable with the 
> message: "There are too many outstanding HTTP requests with a total 100 
> outstanding requests".
> This value should be configurable in nifi.properties allowing users to 
> increase the value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4143) Make configurable maximum number of concurrent requests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077117#comment-16077117
 ] 

ASF GitHub Bot commented on NIFI-4143:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1962
  
Thanks @pvillard31! Most recent update looks great. This has been merged to 
master.


> Make configurable maximum number of concurrent requests
> ---
>
> Key: NIFI-4143
> URL: https://issues.apache.org/jira/browse/NIFI-4143
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>  Labels: documentation
> Fix For: 1.4.0
>
>
> At the moment, the maximum number of concurrent requests is hard coded in 
> {{ThreadPoolRequestReplicator}}
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/http/replication/ThreadPoolRequestReplicator.java
> The value is equal to 100.
> In some situations where multiple factors are combined (large cluster, S2S to 
> load balance data in the cluster, multiple users accessing the UI), the limit 
> can be reached and the UI may become intermittently unavailable with the 
> message: "There are too many outstanding HTTP requests with a total 100 
> outstanding requests".
> This value should be configurable in nifi.properties allowing users to 
> increase the value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4143) Make configurable maximum number of concurrent requests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077116#comment-16077116
 ] 

ASF GitHub Bot commented on NIFI-4143:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1962


> Make configurable maximum number of concurrent requests
> ---
>
> Key: NIFI-4143
> URL: https://issues.apache.org/jira/browse/NIFI-4143
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>  Labels: documentation
>
> At the moment, the maximum number of concurrent requests is hard coded in 
> {{ThreadPoolRequestReplicator}}
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/http/replication/ThreadPoolRequestReplicator.java
> The value is equal to 100.
> In some situations where multiple factors are combined (large cluster, S2S to 
> load balance data in the cluster, multiple users accessing the UI), the limit 
> can be reached and the UI may become intermittently unavailable with the 
> message: "There are too many outstanding HTTP requests with a total 100 
> outstanding requests".
> This value should be configurable in nifi.properties allowing users to 
> increase the value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1962: NIFI-4143 - externalize MAX_CONCURRENT_REQUESTS

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1962


---
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 #1962: NIFI-4143 - externalize MAX_CONCURRENT_REQUESTS

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1962
  
Thanks @pvillard31! Most recent update looks great. 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-4143) Make configurable maximum number of concurrent requests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077114#comment-16077114
 ] 

ASF subversion and git services commented on NIFI-4143:
---

Commit a3b72f1bb7435f987a618eda85008d187332ad21 in nifi's branch 
refs/heads/master from [~pvillard]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=a3b72f1 ]

NIFI-4143 - externalize MAX_CONCURRENT_REQUESTS. This closes #1962


> Make configurable maximum number of concurrent requests
> ---
>
> Key: NIFI-4143
> URL: https://issues.apache.org/jira/browse/NIFI-4143
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>  Labels: documentation
>
> At the moment, the maximum number of concurrent requests is hard coded in 
> {{ThreadPoolRequestReplicator}}
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/http/replication/ThreadPoolRequestReplicator.java
> The value is equal to 100.
> In some situations where multiple factors are combined (large cluster, S2S to 
> load balance data in the cluster, multiple users accessing the UI), the limit 
> can be reached and the UI may become intermittently unavailable with the 
> message: "There are too many outstanding HTTP requests with a total 100 
> outstanding requests".
> This value should be configurable in nifi.properties allowing users to 
> increase the value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-1763) Provide an integration with 'Schema registry for Kafka'

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077111#comment-16077111
 ] 

ASF GitHub Bot commented on NIFI-1763:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/1938
  
@markap14 that now looks fixed.  I was able to use the Confluence schema 
write strategy without issue. All is working as expected.

 1 

will merge in shortly


> Provide an integration with 'Schema registry for Kafka'
> ---
>
> Key: NIFI-1763
> URL: https://issues.apache.org/jira/browse/NIFI-1763
> Project: Apache NiFi
>  Issue Type: Wish
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Mark Payne
>Priority: Minor
>
> Reported on a mailing list question on 13 April 2016
> https://github.com/confluentinc/schema-registry
> The registry itself is an ASLv2 licensed codebase.  It offers a REST-based 
> Web API for interaction.  It would be good to support integration with it for 
> users of Kafka so it would register schemas if needed when writing to Kafka 
> and understand how to parse data based on the indicated schema when reading 
> from Kafka.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1938: NIFI-1763: Initial implementation of ConfluentSchemaRegist...

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/1938
  
@markap14 that now looks fixed.  I was able to use the Confluence schema 
write strategy without issue. All is working as expected.

+1 

will merge in shortly


---
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-4157) Improve PutTCP

[Bryan Bende (JIRA)]

Bryan Bende created NIFI-4157:
-

 Summary: Improve PutTCP
 Key: NIFI-4157
 URL: https://issues.apache.org/jira/browse/NIFI-4157
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Bryan Bende
Assignee: Bryan Bende


Currently PutTCP reads the entire content of a flow file into memory in a 
ByteArrayOutputStream and then sends the bytes of the BAOS over the connection. 
We should stream the flow file's InputStream to the socket's OutputStream.

We also should make the Outgoing Message Delimiter optional for cases where the 
data is already in the desired format.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1978: NIFI-4127: Composite User Group Providers

[mcgilman]

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125994624
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
+
+The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

Ah. Sorry your totally right. I forgot about those checks. They have been 
in place for awhile. So that constraint shouldn't be unique to the composite 
providers. Regardless, I will update the documentation accordingly. I suppose I 
could remove those tests I referenced since they will never hit when running in 
the app. However, they still ensure the order the providers are invoked so I'll 
probably leave them in place. Anyways, thanks for confirming.


---
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-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077109#comment-16077109
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125994624
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
 
 The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

Ah. Sorry your totally right. I forgot about those checks. They have been 
in place for awhile. So that constraint shouldn't be unique to the composite 
providers. Regardless, I will update the documentation accordingly. I suppose I 
could remove those tests I referenced since they will never hit when running in 
the app. However, they still ensure the order the providers are invoked so I'll 
probably leave them in place. Anyways, thanks for confirming.


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077097#comment-16077097
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125993273
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
 
 The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

Hmm you're right but here is what I did: a first test with the configurable 
provider and two LDAP servers, no collision, everything starting as expected. 
Then, I stopped nifi, manually modified the file of the configurable provider 
to add a user already existing in one of the LDAP providers. In that case, NiFi 
failed to start with the following stack trace:


2017-07-06 21:19:53,484 WARN [main] org.apache.nifi.web.server.JettyServer 
Failed to start web server... shutting down.
org.springframework.beans.factory.BeanCreationException: Error creating 
bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired 
dependencies failed; nested exception is 
org.springframework.beans.factory.BeanCreationException: Could not autowire 
method: public void 
org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setJwtAuthenticationProvider(org.apache.nifi.web.security.jwt.JwtAuthenticationProvider);
 nested exception is org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'jwtAuthenticationProvider' defined in class path 
resource [nifi-web-security-context.xml]: Cannot resolve reference to bean 
'authorizer' while setting constructor argument; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'authorizer': FactoryBean threw exception on object creation; nested 
exception is 
org.apache.nifi.authorization.exception.AuthorizerCreationException: Found 
multiple users/user groups with identity 'test'.
at 
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:334)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:772)
at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:839)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:538)
at 
org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:446)
at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:328)
at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:107)
at 

[GitHub] nifi pull request #1978: NIFI-4127: Composite User Group Providers

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125993273
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
+
+The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

Hmm you're right but here is what I did: a first test with the configurable 
provider and two LDAP servers, no collision, everything starting as expected. 
Then, I stopped nifi, manually modified the file of the configurable provider 
to add a user already existing in one of the LDAP providers. In that case, NiFi 
failed to start with the following stack trace:


2017-07-06 21:19:53,484 WARN [main] org.apache.nifi.web.server.JettyServer 
Failed to start web server... shutting down.
org.springframework.beans.factory.BeanCreationException: Error creating 
bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired 
dependencies failed; nested exception is 
org.springframework.beans.factory.BeanCreationException: Could not autowire 
method: public void 
org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setJwtAuthenticationProvider(org.apache.nifi.web.security.jwt.JwtAuthenticationProvider);
 nested exception is org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'jwtAuthenticationProvider' defined in class path 
resource [nifi-web-security-context.xml]: Cannot resolve reference to bean 
'authorizer' while setting constructor argument; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'authorizer': FactoryBean threw exception on object creation; nested 
exception is 
org.apache.nifi.authorization.exception.AuthorizerCreationException: Found 
multiple users/user group
 s with identity 'test'.
at 
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:334)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:772)
at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:839)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:538)
at 
org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:446)
at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:328)
at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:107)
at 
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:876)
at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532)
at 
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:839)

[jira] [Commented] (NIFI-4155) Expand EnforceOrder capability to cluster

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077082#comment-16077082
 ] 

ASF GitHub Bot commented on NIFI-4155:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1984
  
@ijokarumawak while we are still using ZooKeeper as the only cluster state 
provider and using it for  the cluster coordinator, are we sure we want to add 
this option? This goes hand-in-hand with the work to add state to 
UpdateAttribute, specifically this comment[1]. 

@markap14 do you have opinions on this? 

[1] https://issues.apache.org/jira/browse/NIFI-1582


> Expand EnforceOrder capability to cluster
> -
>
> Key: NIFI-4155
> URL: https://issues.apache.org/jira/browse/NIFI-4155
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> Currently, EnforceOrder is able to enforce FlowFile ordering within a NiFi 
> node, and it uses local managed state to track progress.
> If it is configurable which state management to use from Local and Cluster, 
> EnforceOrder would be also able to enforce ordering across cluster with 
> cluster scope state management. It would be useful for some use-cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1984: NIFI-4155: Expand EnforceOrder capability to cluster

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1984
  
@ijokarumawak while we are still using ZooKeeper as the only cluster state 
provider and using it for  the cluster coordinator, are we sure we want to add 
this option? This goes hand-in-hand with the work to add state to 
UpdateAttribute, specifically this comment[1]. 

@markap14 do you have opinions on this? 

[1] https://issues.apache.org/jira/browse/NIFI-1582


---
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-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077070#comment-16077070
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125987445
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
 
 The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

Multiple users should be supported in this PR. Did you see otherwise? There 
are a couple test cases that verify this [1] [2]. Order does matter and I can 
update the docs to describe this fact. UserGroupProviders are invoked in the 
order they appear in the authorizers.xml.

[1] 
https://github.com/mcgilman/nifi/blob/0e679007e59bfea050f73b046f52b2a772a281ae/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-authorization/src/test/java/org/apache/nifi/authorization/CompositeUserGroupProviderTest.java#L139
[2] 
https://github.com/mcgilman/nifi/blob/0e679007e59bfea050f73b046f52b2a772a281ae/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-authorization/src/test/java/org/apache/nifi/authorization/CompositeConfigurableUserGroupProviderTest.java#L93


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1978: NIFI-4127: Composite User Group Providers

[mcgilman]

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125987445
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
+
+The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

Multiple users should be supported in this PR. Did you see otherwise? There 
are a couple test cases that verify this [1] [2]. Order does matter and I can 
update the docs to describe this fact. UserGroupProviders are invoked in the 
order they appear in the authorizers.xml.

[1] 
https://github.com/mcgilman/nifi/blob/0e679007e59bfea050f73b046f52b2a772a281ae/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-authorization/src/test/java/org/apache/nifi/authorization/CompositeUserGroupProviderTest.java#L139
[2] 
https://github.com/mcgilman/nifi/blob/0e679007e59bfea050f73b046f52b2a772a281ae/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-authorization/src/test/java/org/apache/nifi/authorization/CompositeConfigurableUserGroupProviderTest.java#L93


---
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-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077057#comment-16077057
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125983064
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
 
 The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

I think we should indicate that if we have users/groups collisions between 
the sources, NiFi won't start successfully.


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077055#comment-16077055
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125984210
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
 
 The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
 
 * User Group Provider - The identifier of user group providers to load 
from. The name of each property must be unique, for example: "User Group 
Provider A", "User Group Provider B", "User Group Provider C" or "User Group 
Provider 1", "User Group Provider 2", "User Group Provider 3"
 
 The CompositeConfigurableUserGroupProvider will provide support for 
retrieving users and groups from multiple sources. Additionally, a single 
configurable user group provider is required. Users from the configurable user 
group provider are configurable, however users loaded from one of the User 
Group Provider [unique key] will not be.
 
 * Configurable User Group Provider - A configurable user group provider.
--- End diff --

I would add an example or update the example below in the documentation to 
show the configuration of the CompositeConfigurableUserGroupProvider as I 
believe it'll be largely used.


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077058#comment-16077058
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125982809
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
--- End diff --

typo: and a directory server


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077056#comment-16077056
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125983712
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6  464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
 Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
 
 The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
 
 * User Group Provider - The identifier of user group providers to load 
from. The name of each property must be unique, for example: "User Group 
Provider A", "User Group Provider B", "User Group Provider C" or "User Group 
Provider 1", "User Group Provider 2", "User Group Provider 3"
 
 The CompositeConfigurableUserGroupProvider will provide support for 
retrieving users and groups from multiple sources. Additionally, a single 
configurable user group provider is required. Users from the configurable user 
group provider are configurable, however users loaded from one of the User 
Group Provider [unique key] will not be.
--- End diff --

It's really a detail, but for uniformity, could you add "The X has the 
following properties:"?


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1978: NIFI-4127: Composite User Group Providers

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125983064
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
+
+The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
--- End diff --

I think we should indicate that if we have users/groups collisions between 
the sources, NiFi won't start successfully.


---
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 #1978: NIFI-4127: Composite User Group Providers

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125982809
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
--- End diff --

typo: and a directory server


---
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 #1978: NIFI-4127: Composite User Group Providers

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125983712
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
+
+The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
+
+* User Group Provider - The identifier of user group providers to load 
from. The name of each property must be unique, for example: "User Group 
Provider A", "User Group Provider B", "User Group Provider C" or "User Group 
Provider 1", "User Group Provider 2", "User Group Provider 3"
+
+The CompositeConfigurableUserGroupProvider will provide support for 
retrieving users and groups from multiple sources. Additionally, a single 
configurable user group provider is required. Users from the configurable user 
group provider are configurable, however users loaded from one of the User 
Group Provider [unique key] will not be.
--- End diff --

It's really a detail, but for uniformity, could you add "The X has the 
following properties:"?


---
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 #1978: NIFI-4127: Composite User Group Providers

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1978#discussion_r125984210
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -464,6 +464,17 @@ Another option for the UserGroupProvider is the 
LdapUserGroupProvider. By defaul
 * Group Name Attribute - Attribute to use to extract group name (i.e. cn). 
Optional. If not set, the entire DN is used.
 * Group Member Attribute - Attribute to use to define group membership 
(i.e. member). Optional. If not set group membership will not be calculated 
through the groups. Will rely on group member being defined through 'User Group 
Name Attribute' if set.
 
+Another option for the UserGroupProvider are composite implementations. 
This means that multiple sources/implementations can be configured and 
composed. For instance, an admin can configure users/groups to be loaded from a 
file and an directory server. There are two composite implementations, one that 
supports multiple UserGroupProviders and one that supports multiple 
UserGroupProviders and a single configurable UserGroupProvider.
+
+The CompositeUserGroupProvider will provide support for retrieving users 
and groups from multiple sources.
+
+* User Group Provider - The identifier of user group providers to load 
from. The name of each property must be unique, for example: "User Group 
Provider A", "User Group Provider B", "User Group Provider C" or "User Group 
Provider 1", "User Group Provider 2", "User Group Provider 3"
+
+The CompositeConfigurableUserGroupProvider will provide support for 
retrieving users and groups from multiple sources. Additionally, a single 
configurable user group provider is required. Users from the configurable user 
group provider are configurable, however users loaded from one of the User 
Group Provider [unique key] will not be.
+
+* Configurable User Group Provider - A configurable user group provider.
--- End diff --

I would add an example or update the example below in the documentation to 
show the configuration of the CompositeConfigurableUserGroupProvider as I 
believe it'll be largely 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.
---

[jira] [Commented] (NIFI-3218) MockProcessSession should prevent transferring new FlowFile to input queue

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077046#comment-16077046
 ] 

ASF GitHub Bot commented on NIFI-3218:
--

Github user jskora commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1988#discussion_r125982805
  
--- Diff: 
nifi-mock/src/main/java/org/apache/nifi/util/MockProcessSession.java ---
@@ -756,6  756,13 @@ public void transfer(FlowFile flowFile) {
 throw new IllegalArgumentException("I only accept 
MockFlowFile");
 }
 
 // if the flowfile provided was created in this session (i.e. it's 
in currentVersions),
 // then throw an exception indicating that you can't transfer 
flowfiles back to self.
 // this mimics the behavior of StandardProcessSession
 if(currentVersions.get(flowFile.getId()) != null) {
--- End diff --

This should only fire the exception if the `flowFile.getId()` is in 
`currentVersions` but not in `originalVersions` since those are the newly 
created FlowFiles.  If it's in both it's a queued file being transferred back 
to the queue.  You can see the problem if you run the `TestUpdateAttribute` 
tests.


> 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 pull request #1988: NIFI-3218: throw exception in MockProcessSession wh...

[jskora]

Github user jskora commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1988#discussion_r125982805
  
--- Diff: 
nifi-mock/src/main/java/org/apache/nifi/util/MockProcessSession.java ---
@@ -756,6 +756,13 @@ public void transfer(FlowFile flowFile) {
 throw new IllegalArgumentException("I only accept 
MockFlowFile");
 }
 
+// if the flowfile provided was created in this session (i.e. it's 
in currentVersions),
+// then throw an exception indicating that you can't transfer 
flowfiles back to self.
+// this mimics the behavior of StandardProcessSession
+if(currentVersions.get(flowFile.getId()) != null) {
--- End diff --

This should only fire the exception if the `flowFile.getId()` is in 
`currentVersions` but not in `originalVersions` since those are the newly 
created FlowFiles.  If it's in both it's a queued file being transferred back 
to the queue.  You can see the problem if you run the `TestUpdateAttribute` 
tests.


---
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-4143) Make configurable maximum number of concurrent requests

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman updated NIFI-4143:
--
Labels: documentation  (was: )

> Make configurable maximum number of concurrent requests
> ---
>
> Key: NIFI-4143
> URL: https://issues.apache.org/jira/browse/NIFI-4143
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>  Labels: documentation
>
> At the moment, the maximum number of concurrent requests is hard coded in 
> {{ThreadPoolRequestReplicator}}
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/http/replication/ThreadPoolRequestReplicator.java
> The value is equal to 100.
> In some situations where multiple factors are combined (large cluster, S2S to 
> load balance data in the cluster, multiple users accessing the UI), the limit 
> can be reached and the UI may become intermittently unavailable with the 
> message: "There are too many outstanding HTTP requests with a total 100 
> outstanding requests".
> This value should be configurable in nifi.properties allowing users to 
> increase the value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4151) Slow response times when requesting Process Group Status

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman updated NIFI-4151:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   Status: Resolved  (was: Patch Available)

> Slow response times when requesting Process Group Status
> 
>
> Key: NIFI-4151
> URL: https://issues.apache.org/jira/browse/NIFI-4151
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.4.0
>
>
> I have a flow with > 1,000 Process Groups and 2500 Processors. A few thousand 
> connections and input/output ports as well. When I refresh stats it is taking 
> 3-4 seconds to pull back the status. And when I go to the Summary table, it's 
> taking about 8 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4151) Slow response times when requesting Process Group Status

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076964#comment-16076964
 ] 

ASF GitHub Bot commented on NIFI-4151:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1979


> Slow response times when requesting Process Group Status
> 
>
> Key: NIFI-4151
> URL: https://issues.apache.org/jira/browse/NIFI-4151
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Assignee: Mark Payne
>
> I have a flow with > 1,000 Process Groups and 2500 Processors. A few thousand 
> connections and input/output ports as well. When I refresh stats it is taking 
> 3-4 seconds to pull back the status. And when I go to the Summary table, it's 
> taking about 8 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4151) Slow response times when requesting Process Group Status

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076965#comment-16076965
 ] 

ASF GitHub Bot commented on NIFI-4151:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1979
  
Thanks @markap14! The update has addressed the test failures and this has 
been merged to master.


> Slow response times when requesting Process Group Status
> 
>
> Key: NIFI-4151
> URL: https://issues.apache.org/jira/browse/NIFI-4151
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Assignee: Mark Payne
>
> I have a flow with > 1,000 Process Groups and 2500 Processors. A few thousand 
> connections and input/output ports as well. When I refresh stats it is taking 
> 3-4 seconds to pull back the status. And when I go to the Summary table, it's 
> taking about 8 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1979: NIFI-4151: Updated UpdateAttribute to only create JAXB Con...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1979
  
Thanks @markap14! The update has addressed the test failures and 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 #1979: NIFI-4151: Updated UpdateAttribute to only create J...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1979


---
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-4151) Slow response times when requesting Process Group Status

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076963#comment-16076963
 ] 

ASF subversion and git services commented on NIFI-4151:
---

Commit ba56774fa1c16d935f592df482e74bfa1564b5a3 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=ba56774 ]

NIFI-4151: Updated UpdateAttribute to only create JAXB Context once; Minor 
performance tweaks to standard validators and StatusMerge.prettyPrint; updated 
AbstractConfiguredComponent to not create a new ValidationContext each time 
that validate is called but only when needed; updated FlowController, 
StandardControllerServiceProvider, and StandardProcessGroup so that component 
lookups can be performed using a ConcurrentMap at FlowController level instead 
of having to perform a depth-first search through all ProcessGroups when 
calling findProcessor(), findProcessGroup(), findXYZ()
This closes #1979


> Slow response times when requesting Process Group Status
> 
>
> Key: NIFI-4151
> URL: https://issues.apache.org/jira/browse/NIFI-4151
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Assignee: Mark Payne
>
> I have a flow with > 1,000 Process Groups and 2500 Processors. A few thousand 
> connections and input/output ports as well. When I refresh stats it is taking 
> 3-4 seconds to pull back the status. And when I go to the Summary table, it's 
> taking about 8 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4127) Create a CompositeUserGroupProvider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076957#comment-16076957
 ] 

ASF GitHub Bot commented on NIFI-4127:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/1978
  
Reviewing...


> Create a CompositeUserGroupProvider
> ---
>
> Key: NIFI-4127
> URL: https://issues.apache.org/jira/browse/NIFI-4127
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> Create a CompositeUserGroupProvider to support loading users/groups from 
> multiple sources. This composite implementation should support
> {noformat}
> 0-1 ConfigurableUserGroupProvider
> 0-n UserGroupProviders
> {noformat}
> Only a single ConfigurableUserGroupProvider can be supplied to keep these 
> sources/implementation details hidden from the end users. The 
> CompositeUserGroupProvider must be configured with at least 1 underlying 
> provider.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1978: NIFI-4127: Composite User Group Providers

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/1978
  
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-1763) Provide an integration with 'Schema registry for Kafka'

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076924#comment-16076924
 ] 

ASF GitHub Bot commented on NIFI-1763:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/1938
  
@markap14 thanks will check it out


> Provide an integration with 'Schema registry for Kafka'
> ---
>
> Key: NIFI-1763
> URL: https://issues.apache.org/jira/browse/NIFI-1763
> Project: Apache NiFi
>  Issue Type: Wish
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Mark Payne
>Priority: Minor
>
> Reported on a mailing list question on 13 April 2016
> https://github.com/confluentinc/schema-registry
> The registry itself is an ASLv2 licensed codebase.  It offers a REST-based 
> Web API for interaction.  It would be good to support integration with it for 
> users of Kafka so it would register schemas if needed when writing to Kafka 
> and understand how to parse data based on the indicated schema when reading 
> from Kafka.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1938: NIFI-1763: Initial implementation of ConfluentSchemaRegist...

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/1938
  
@markap14 thanks will check it out


---
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-3931) putSftp process port property should support for expression language

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076918#comment-16076918
 ] 

ASF GitHub Bot commented on NIFI-3931:
--

Github user m-hogue commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1968#discussion_r125960083
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/SFTPIT.java
 ---
@@ -0,0  1,51 @@
 /*
  * Licensed to the Apache Software Foundation (ASF) under one or more
  * contributor license agreements.  See the NOTICE file distributed with
  * this work for additional information regarding copyright ownership.
  * The ASF licenses this file to You under the Apache License, Version 2.0
  * (the "License"); you may not use this file except in compliance with
  * the License.  You may obtain a copy of the License at
  *
  * http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 package org.apache.nifi.processors.standard;
 
 import org.apache.nifi.processors.standard.util.SFTPTransfer;
 import org.apache.nifi.util.TestRunner;
 import org.apache.nifi.util.TestRunners;
 import org.junit.Test;
 
 public class SFTPIT {
 
--- End diff --

Indeed. Thanks for the clarification. LGTM!


> putSftp process port property should support for expression language
> 
>
> Key: NIFI-3931
> URL: https://issues.apache.org/jira/browse/NIFI-3931
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Cheng Chin Tat
>Assignee: Pierre Villard
>Priority: Minor
>  Labels: easyfix
> Attachments: TestFTP.xml
>
>
> PutSftp Processor port property should support for expression language so 
> that dynamic port number can be pass to the processor during run time. 
> Rather than preset the port on design time.
> This changes involve changing the PropertyDescriptor SFTP_PORT validator 
> StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR to 
> StandardValidators.NON_EMPTY_VALIDATOR and other codes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1968: NIFI-3931 - Added EL to properties in SFTP transfer

[m-hogue]

Github user m-hogue commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1968#discussion_r125960083
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/SFTPIT.java
 ---
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.processors.standard.util.SFTPTransfer;
+import org.apache.nifi.util.TestRunner;
+import org.apache.nifi.util.TestRunners;
+import org.junit.Test;
+
+public class SFTPIT {
+
--- End diff --

Indeed. Thanks for the clarification. LGTM!


---
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-3931) putSftp process port property should support for expression language

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076909#comment-16076909
 ] 

ASF GitHub Bot commented on NIFI-3931:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1968#discussion_r125958747
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/SFTPIT.java
 ---
@@ -0,0  1,51 @@
 /*
  * Licensed to the Apache Software Foundation (ASF) under one or more
  * contributor license agreements.  See the NOTICE file distributed with
  * this work for additional information regarding copyright ownership.
  * The ASF licenses this file to You under the Apache License, Version 2.0
  * (the "License"); you may not use this file except in compliance with
  * the License.  You may obtain a copy of the License at
  *
  * http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 package org.apache.nifi.processors.standard;
 
 import org.apache.nifi.processors.standard.util.SFTPTransfer;
 import org.apache.nifi.util.TestRunner;
 import org.apache.nifi.util.TestRunners;
 import org.junit.Test;
 
 public class SFTPIT {
 
--- End diff --

The tests executed during the builds are controlled by the surefire plugin 
definition in the top level pom file:

xml

**/*Test.class
**/Test*.class
**/*Spec.class



It should not be necessary to add ``@Ignore`` in this class. I believe the 
convention is to use IT (and to not use Test) in the class name when 
implementing integration tests.


> putSftp process port property should support for expression language
> 
>
> Key: NIFI-3931
> URL: https://issues.apache.org/jira/browse/NIFI-3931
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Cheng Chin Tat
>Assignee: Pierre Villard
>Priority: Minor
>  Labels: easyfix
> Attachments: TestFTP.xml
>
>
> PutSftp Processor port property should support for expression language so 
> that dynamic port number can be pass to the processor during run time. 
> Rather than preset the port on design time.
> This changes involve changing the PropertyDescriptor SFTP_PORT validator 
> StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR to 
> StandardValidators.NON_EMPTY_VALIDATOR and other codes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1968: NIFI-3931 - Added EL to properties in SFTP transfer

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1968#discussion_r125958747
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/SFTPIT.java
 ---
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.processors.standard.util.SFTPTransfer;
+import org.apache.nifi.util.TestRunner;
+import org.apache.nifi.util.TestRunners;
+import org.junit.Test;
+
+public class SFTPIT {
+
--- End diff --

The tests executed during the builds are controlled by the surefire plugin 
definition in the top level pom file:

xml

**/*Test.class
**/Test*.class
**/*Spec.class



It should not be necessary to add ``@Ignore`` in this class. I believe the 
convention is to use IT (and to not use Test) in the class name when 
implementing integration tests.


---
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-3281) Error on passing 'ftp.listing.user' from ListFTP to FetchSFTP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076896#comment-16076896
 ] 

ASF GitHub Bot commented on NIFI-3281:
--

Github user m-hogue commented on the issue:

https://github.com/apache/nifi/pull/1974
  
LGTM. Thanks!


> Error on passing 'ftp.listing.user' from ListFTP to FetchSFTP
> -
>
> Key: NIFI-3281
> URL: https://issues.apache.org/jira/browse/NIFI-3281
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Jakhongir Ashrapov
>Assignee: Pierre Villard
>Priority: Minor
>
> Cannot get `ftp.listing.user` as EL in FetchFTP when listing files with 
> ListFTP. Following exception is thrown:
> IOException: Could not login for user ''



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1974: NIFI-3281 - fix for (S)FTP processors when using EL agains...

[m-hogue]

Github user m-hogue commented on the issue:

https://github.com/apache/nifi/pull/1974
  
LGTM. 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-3931) putSftp process port property should support for expression language

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076886#comment-16076886
 ] 

ASF GitHub Bot commented on NIFI-3931:
--

Github user m-hogue commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1968#discussion_r125955333
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/SFTPIT.java
 ---
@@ -0,0  1,51 @@
 /*
  * Licensed to the Apache Software Foundation (ASF) under one or more
  * contributor license agreements.  See the NOTICE file distributed with
  * this work for additional information regarding copyright ownership.
  * The ASF licenses this file to You under the Apache License, Version 2.0
  * (the "License"); you may not use this file except in compliance with
  * the License.  You may obtain a copy of the License at
  *
  * http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 package org.apache.nifi.processors.standard;
 
 import org.apache.nifi.processors.standard.util.SFTPTransfer;
 import org.apache.nifi.util.TestRunner;
 import org.apache.nifi.util.TestRunners;
 import org.junit.Test;
 
 public class SFTPIT {
 
--- End diff --

Should this be `@Ignore`d if it's not supposed to be run with the normal 
build?


> putSftp process port property should support for expression language
> 
>
> Key: NIFI-3931
> URL: https://issues.apache.org/jira/browse/NIFI-3931
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Cheng Chin Tat
>Assignee: Pierre Villard
>Priority: Minor
>  Labels: easyfix
> Attachments: TestFTP.xml
>
>
> PutSftp Processor port property should support for expression language so 
> that dynamic port number can be pass to the processor during run time. 
> Rather than preset the port on design time.
> This changes involve changing the PropertyDescriptor SFTP_PORT validator 
> StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR to 
> StandardValidators.NON_EMPTY_VALIDATOR and other codes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1968: NIFI-3931 - Added EL to properties in SFTP transfer

[m-hogue]

Github user m-hogue commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1968#discussion_r125955333
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/SFTPIT.java
 ---
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.processors.standard.util.SFTPTransfer;
+import org.apache.nifi.util.TestRunner;
+import org.apache.nifi.util.TestRunners;
+import org.junit.Test;
+
+public class SFTPIT {
+
--- End diff --

Should this be `@Ignore`d if it's not supposed to be run with the normal 
build?


---
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-3281) Error on passing 'ftp.listing.user' from ListFTP to FetchSFTP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076869#comment-16076869
 ] 

ASF GitHub Bot commented on NIFI-3281:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/1974
  
Thanks @m-hogue and @joewitt for your feedback, I just pushed a commit that 
should address your comments: retrieve the boolean returned by 
``completePendingCommand()`` and, if false, send the FF to 
``REL_COMMS_FAILURE`` relationship. Also added a unit test for ``ListFTP`` to 
check attributes being written on flow files.


> Error on passing 'ftp.listing.user' from ListFTP to FetchSFTP
> -
>
> Key: NIFI-3281
> URL: https://issues.apache.org/jira/browse/NIFI-3281
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Jakhongir Ashrapov
>Assignee: Pierre Villard
>Priority: Minor
>
> Cannot get `ftp.listing.user` as EL in FetchFTP when listing files with 
> ListFTP. Following exception is thrown:
> IOException: Could not login for user ''



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1974: NIFI-3281 - fix for (S)FTP processors when using EL agains...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/1974
  
Thanks @m-hogue and @joewitt for your feedback, I just pushed a commit that 
should address your comments: retrieve the boolean returned by 
``completePendingCommand()`` and, if false, send the FF to 
``REL_COMMS_FAILURE`` relationship. Also added a unit test for ``ListFTP`` to 
check attributes being written on flow files.


---
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-4112) ConvertExceltoCSV removes missing cells

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076854#comment-16076854
 ] 

ASF GitHub Bot commented on NIFI-4112:
--

Github user m-hogue commented on the issue:

https://github.com/apache/nifi/pull/1973
  
Hey @ijokarumawak : LGTM. Just had a single comment.


> ConvertExceltoCSV removes missing cells
> ---
>
> Key: NIFI-4112
> URL: https://issues.apache.org/jira/browse/NIFI-4112
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Michael Boulter
>Assignee: Koji Kawamura
>Priority: Minor
> Attachments: 4146786940134586_Sheet1.csv, test.xlsx
>
>
> The ConvertExceltoCSV will remove missing cells from the CSV output.
> An input of {{TEST,,,TEST}} will become {{TEST,TEST}}
> Please see input and output attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1973: NIFI-4112: Fix ConvertExcelToCSV to handle empty cells.

[m-hogue]

Github user m-hogue commented on the issue:

https://github.com/apache/nifi/pull/1973
  
Hey @ijokarumawak : LGTM. Just had a single comment.


---
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-4112) ConvertExceltoCSV removes missing cells

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076849#comment-16076849
 ] 

ASF GitHub Bot commented on NIFI-4112:
--

Github user m-hogue commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1973#discussion_r125950247
  
--- Diff: 
nifi-nar-bundles/nifi-poi-bundle/nifi-poi-processors/src/test/resources/with-blank-cells.csv
 ---
@@ -0,0  1,8 @@
 A,B,C,D
--- End diff --

Would a test case with all empty cells be useful as well? Thinking edge 
cases.


> ConvertExceltoCSV removes missing cells
> ---
>
> Key: NIFI-4112
> URL: https://issues.apache.org/jira/browse/NIFI-4112
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Michael Boulter
>Assignee: Koji Kawamura
>Priority: Minor
> Attachments: 4146786940134586_Sheet1.csv, test.xlsx
>
>
> The ConvertExceltoCSV will remove missing cells from the CSV output.
> An input of {{TEST,,,TEST}} will become {{TEST,TEST}}
> Please see input and output attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1973: NIFI-4112: Fix ConvertExcelToCSV to handle empty ce...

[m-hogue]

Github user m-hogue commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1973#discussion_r125950247
  
--- Diff: 
nifi-nar-bundles/nifi-poi-bundle/nifi-poi-processors/src/test/resources/with-blank-cells.csv
 ---
@@ -0,0 +1,8 @@
+A,B,C,D
--- End diff --

Would a test case with all empty cells be useful as well? Thinking edge 
cases.


---
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] [Comment Edited] (NIFI-3218) MockProcessSession should prevent transferring new FlowFile to input queue

[Michael Hogue (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076815#comment-16076815
 ] 

Michael Hogue edited comment on NIFI-3218 at 7/6/17 4:28 PM:
-

I made an assumption that `currentVersions` in `MockProcessSession` would hold 
files created in "this session" since that's the data structure files are 
placed in on `create()`

[~jskora] : Please let me know if this meets the need.


was (Author: m-hogue):
Made an assumption that `currentVersions` in `MockProcessSession` would hold 
files created in "this session" since that's the data structure files are 
placed in on `create()`

> 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)

[jira] [Comment Edited] (NIFI-3218) MockProcessSession should prevent transferring new FlowFile to input queue

[Michael Hogue (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076815#comment-16076815
 ] 

Michael Hogue edited comment on NIFI-3218 at 7/6/17 4:28 PM:
-

I made an assumption that `currentVersions` in `MockProcessSession` would hold 
files created in "this session" since that's the data structure that FlowFiles 
are placed in on `create()`

[~jskora] : Please let me know if this meets the need.


was (Author: m-hogue):
I made an assumption that `currentVersions` in `MockProcessSession` would hold 
files created in "this session" since that's the data structure files are 
placed in on `create()`

[~jskora] : Please let me know if this meets the need.

> 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 pull request #1988: NIFI-3218: throw exception in MockProcessSession wh...

[m-hogue]

GitHub user m-hogue opened a pull request:

https://github.com/apache/nifi/pull/1988

NIFI-3218: throw exception in MockProcessSession when transferring fi…

…le to self

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-3218

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1988.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 #1988


commit 017658e5c15cecb6c647652dc3f9e4734bac51ae
Author: m-hogue 
Date:   2017-07-06T16:10:09Z

NIFI-3218: throw exception in MockProcessSession when transferring file to 
self




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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076829#comment-16076829
 ] 

ASF GitHub Bot commented on NIFI-3218:
--

GitHub user m-hogue opened a pull request:

https://github.com/apache/nifi/pull/1988

NIFI-3218: throw exception in MockProcessSession when transferring fi…

…le to self

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-3218

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1988.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 #1988


commit 017658e5c15cecb6c647652dc3f9e4734bac51ae
Author: m-hogue 
Date:   2017-07-06T16:10:09Z

NIFI-3218: throw exception in MockProcessSession when transferring file to 
self




> 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)

[jira] [Commented] (NIFI-3218) MockProcessSession should prevent transferring new FlowFile to input queue

[Michael Hogue (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076815#comment-16076815
 ] 

Michael Hogue commented on NIFI-3218:
-

Made an assumption that `currentVersions` in `MockProcessSession` would hold 
files created in "this session" since that's the data structure files are 
placed in on `create()`

> 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)

[jira] [Commented] (NIFI-3218) MockProcessSession should prevent transferring new FlowFile to input queue

[Michael Hogue (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076800#comment-16076800
 ] 

Michael Hogue commented on NIFI-3218:
-

I'll take a whack at this. Work here: 
https://github.com/m-hogue/nifi/tree/NIFI-3218

> 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)

[jira] [Assigned] (NIFI-3218) MockProcessSession should prevent transferring new FlowFile to input queue

[Michael Hogue (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Hogue reassigned NIFI-3218:
---

Assignee: Michael Hogue

> 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)

[jira] [Updated] (NIFI-4152) Create ListenTCPRecord Processor

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4152:
--
Status: Patch Available  (was: In Progress)

> Create ListenTCPRecord Processor
> 
>
> Key: NIFI-4152
> URL: https://issues.apache.org/jira/browse/NIFI-4152
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Attachments: ListenTCPRecordWithGrok.xml
>
>
> We should implement a ListenTCPRecord that can pass the underlying 
> InputStream from a TCP connection to a record reader.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4152) Create ListenTCPRecord Processor

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4152:
--
Attachment: ListenTCPRecordWithGrok.xml

Attaching template.

> Create ListenTCPRecord Processor
> 
>
> Key: NIFI-4152
> URL: https://issues.apache.org/jira/browse/NIFI-4152
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Attachments: ListenTCPRecordWithGrok.xml
>
>
> We should implement a ListenTCPRecord that can pass the underlying 
> InputStream from a TCP connection to a record reader.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4152) Create ListenTCPRecord Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076773#comment-16076773
 ] 

ASF GitHub Bot commented on NIFI-4152:
--

GitHub user bbende opened a pull request:

https://github.com/apache/nifi/pull/1987

NIFI-4152 Initial commit of ListenTCPRecord

Adds a ListenTCPRecord processor which can read records from the 
InputStream of a TCP connection. 



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi NIFI-4152

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1987.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 #1987






> Create ListenTCPRecord Processor
> 
>
> Key: NIFI-4152
> URL: https://issues.apache.org/jira/browse/NIFI-4152
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
>
> We should implement a ListenTCPRecord that can pass the underlying 
> InputStream from a TCP connection to a record reader.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #1987: NIFI-4152 Initial commit of ListenTCPRecord

[bbende]

GitHub user bbende opened a pull request:

https://github.com/apache/nifi/pull/1987

NIFI-4152 Initial commit of ListenTCPRecord

Adds a ListenTCPRecord processor which can read records from the 
InputStream of a TCP connection. 



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi NIFI-4152

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1987.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 #1987






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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076772#comment-16076772
 ] 

ASF GitHub Bot commented on NIFI-2528:
--

GitHub user m-hogue opened a pull request:

https://github.com/apache/nifi/pull/1986

NIFI-2528: added support for SSLContextService protocols in ListenHTTP

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-2528

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1986.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 #1986


commit 399d34af8725330d5d8b947ca69e643623fe908c
Author: m-hogue 
Date:   2017-07-06T15:42:46Z

NIFI-2528: added support for SSLContextService protocols in ListenHTTP




> 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 pull request #1986: NIFI-2528: added support for SSLContextService prot...

[m-hogue]

GitHub user m-hogue opened a pull request:

https://github.com/apache/nifi/pull/1986

NIFI-2528: added support for SSLContextService protocols in ListenHTTP

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-2528

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1986.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 #1986


commit 399d34af8725330d5d8b947ca69e643623fe908c
Author: m-hogue 
Date:   2017-07-06T15:42:46Z

NIFI-2528: added support for SSLContextService protocols in ListenHTTP




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