[jira] [Commented] (NIFI-3231) PutTCP and PutUDP should support EL for host and port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3231:
--

Github user ddewaele commented on the issue:

https://github.com/apache/nifi/pull/1361
  
@pvillard31 : a bit offtopic perhaps, but can we do the same for ListenHTTP 
? Having the base path and port EL supported would allow us to externalize some 
config in a variable registry instead of hardcoding it.

I'd be happy to do the PR for this.


> PutTCP and PutUDP should support EL for host and port
> -
>
> Key: NIFI-3231
> URL: https://issues.apache.org/jira/browse/NIFI-3231
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.1.1
>Reporter: Bryan Bende
>Assignee: Pierre Villard
>
> PutTCP and PutUDP should support expression language (without a flow file) 
> for host and port in order to make use of the variable registry and reference 
> different hosts and ports per environment.
> Relevant code:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutTCP.java#L110
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutUDP.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1361: NIFI-3231 Added EL support to hostname and port in PutTCP/...

[ddewaele]

Github user ddewaele commented on the issue:

https://github.com/apache/nifi/pull/1361
  
@pvillard31 : a bit offtopic perhaps, but can we do the same for ListenHTTP 
? Having the base path and port EL supported would allow us to externalize some 
config in a variable registry instead of hardcoding it.

I'd be happy to do the PR for this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3164) Add log to startup stating loading nars

[James Wing (JIRA)]

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

James Wing commented on NIFI-3164:
--

I have merged the initial log message code to master and 0.x.  I'll wait here 
for a bit to see if are continuing.

> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3164) Add log to startup stating loading nars

[ASF subversion and git services (JIRA)]

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

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

Commit 9fe8ea0c62dafd9c28a1cdd0d0e994919899afb4 in nifi's branch refs/heads/0.x 
from [~pvillard]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=9fe8ea0 ]

NIFI-3164 Added message at startup to log NAR loading

This closes #1365.

Signed-off-by: James Wing 


> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3164) Add log to startup stating loading nars

[Michael Moser (JIRA)]

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

Michael Moser commented on NIFI-3164:
-

It would be nice if it logged a message when it started, then logged another 
message when it ended to report how long it took.  Similar to the message:

INFO [main] org.apache.nifi.NiFi Controller initialization took 15955626743 
nanoseconds.

> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi-minifi pull request #70: MINIFI-178 Updating README and Admin guide to ...

[apiri]

GitHub user apiri opened a pull request:

https://github.com/apache/nifi-minifi/pull/70

MINIFI-178 Updating README and Admin guide to use HTTPS links.

MINIFI-178 Updating README and Admin guide to use HTTPS links.

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

$ git pull https://github.com/apiri/nifi-minifi MINIFI-178

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

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


commit dc154eabb33aad09394df08ca4a4c0a3fffd9ba7
Author: Aldrin Piri 
Date:   2016-12-28T22:14:29Z

MINIFI-178 Updating README and Admin guide to use HTTPS links.




---
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-3164) Add log to startup stating loading nars

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3164:
--

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1365
  
Thanks, @pvillard31 , this looks like a useful addition.  I ran the full 
build with checks and verified the app log output.


> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1365: NIFI-3164 Added message at startup to log NAR loading

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1365
  
Thanks, @pvillard31 , this looks like a useful addition.  I ran the full 
build with checks and verified the app log output.


---
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-3164) Add log to startup stating loading nars

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-3164 Added message at startup to log NAR loading

This closes #1365.

Signed-off-by: James Wing 


> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3164) Add log to startup stating loading nars

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3164:
--

Github user asfgit closed the pull request at:

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


> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1365: NIFI-3164 Added message at startup to log NAR loadi...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3265) tls-toolkit client can fail when tls-toolkit server has multiple cn attributes

[Bryan Rosander (JIRA)]

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

Bryan Rosander updated NIFI-3265:
-
Summary: tls-toolkit client can fail when tls-toolkit server has multiple 
cn attributes  (was: tls-toolkit client fails when tls-toolkit server has 
multiple cn attributes)

> tls-toolkit client can fail when tls-toolkit server has multiple cn attributes
> --
>
> Key: NIFI-3265
> URL: https://issues.apache.org/jira/browse/NIFI-3265
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.1, 1.0.1
>Reporter: Bryan Rosander
>Priority: Minor
>  Labels: tls-toolkit
>
> Ldap hierarchies can have multiple cn attributes. 
> tls-toolkit in client mode validates the first CN attribute parsed from the 
> distinguished name against the hostname name of the tls-toolkit server to 
> help avoid man-in-the-middle attacks.  
> This check fails when multiple CN attributes are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3265) tls-toolkit client can fail when tls-toolkit server has multiple cn attributes

[Bryan Rosander (JIRA)]

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

Bryan Rosander updated NIFI-3265:
-
Description: 
Ldap hierarchies can have multiple cn attributes. 

tls-toolkit in client mode validates the first CN attribute parsed from the 
distinguished name against the hostname name of the tls-toolkit server to help 
avoid man-in-the-middle attacks.  

This check can fail when multiple CN attributes are present.

  was:
Ldap hierarchies can have multiple cn attributes. 

tls-toolkit in client mode validates the first CN attribute parsed from the 
distinguished name against the hostname name of the tls-toolkit server to help 
avoid man-in-the-middle attacks.  

This check fails when multiple CN attributes are present.


> tls-toolkit client can fail when tls-toolkit server has multiple cn attributes
> --
>
> Key: NIFI-3265
> URL: https://issues.apache.org/jira/browse/NIFI-3265
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.1, 1.0.1
>Reporter: Bryan Rosander
>Priority: Minor
>  Labels: tls-toolkit
>
> Ldap hierarchies can have multiple cn attributes. 
> tls-toolkit in client mode validates the first CN attribute parsed from the 
> distinguished name against the hostname name of the tls-toolkit server to 
> help avoid man-in-the-middle attacks.  
> This check can fail when multiple CN attributes are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (NIFI-1582) New processor to update attributes with state

[Joseph Percivall (JIRA)]

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

Joseph Percivall reopened NIFI-1582:


Re-opening as the logic to update the state should use "replaceState" and not 
"setState"[1]

[1] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java#L673

> New processor to update attributes with state
> -
>
> Key: NIFI-1582
> URL: https://issues.apache.org/jira/browse/NIFI-1582
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
> Fix For: 1.2.0
>
>
> This idea was sparked by a thread on the user list and should allow basic 
> data science:
> I expect that in the future I’ll need something a little more sophisticated 
> but for now my problem is very simple:
> I want to be able to trigger an alert (only once) when an attribute in an 
> incoming stream, for instance, goes over a predefined threshold. The 
> Processor should then trigger (only once again) another trigger when the 
> signal goes back to normal (below threshold). Basically a RouteByAttribute 
> but with memory.
> Thanks 
> Claudio
> 
> Hello Claudio,
> Your use-case actually could leverage a couple of recently added features to 
> create a really cool open-source processor. The two key features that were 
> added are State Management and the ability to reference processor specific 
> variables in expression language. You can take a look at RouteText to see 
> both in action. 
> By utilizing both you can create a processor that is configured with multiple 
> Expression language expressions. There would be dynamic properties which 
> would accept expression language and then store the evaluated value via state 
> management. Then there would be a routing property (that supports expression 
> language) that could simply add an attribute to the flowfile with the 
> evaluated value which would allow it to be used by flowing processors for 
> routing.
> This would allow you to do your use-case where you store the value for the 
> incoming stream and route differently once you go over a threshold. It could 
> even allow more complex use-cases. One instance, I believe, would be possible 
> is to have a running average and standard deviation and route data to 
> different locations based on it's standard deviation.
> You can think of this like an UpdateAttribute with the ability to store and 
> calculate variables using expression language.
> Joe



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NIFI-3265) tls-toolkit client fails when tls-toolkit server has multiple cn attributes

[Bryan Rosander (JIRA)]

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

Bryan Rosander edited comment on NIFI-3265 at 12/28/16 8:51 PM:


Server:
{code}
bin/tls-toolkit.sh server -D 'CN=localhost,CN=host,CN=account' -t test
tls-toolkit.sh: JAVA_HOME not set; results may vary
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.util.log: Logging initialized 
@1284ms
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.Server: 
jetty-9.3.9.v20160517
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.AbstractConnector: 
Started ServerConnector@be34f20{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.Server: Started @1460ms
Server Started
{code}

Client:
{code}
bin/tls-toolkit.sh client -t test -D 'CN=client'
tls-toolkit.sh: JAVA_HOME not set; results may vary
2016/12/28 15:51:25 INFO [main] 
org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: 
Requesting new certificate from localhost:8443
2016/12/28 15:51:25 INFO [main] 
org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer:
 Requesting certificate with dn CN=client from localhost:8443
2016/12/28 15:51:26 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:51:26 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
2016/12/28 15:51:26 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:51:26 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
2016/12/28 15:51:26 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:51:26 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
Service client error: Expected cn of localhost but got account

Usage: tls-toolkit service [-h] [args]

Services:
   standalone: Creates certificates and config files for nifi cluster.
   server: Acts as a Certificate Authority that can be used by clients to get 
Certificates
   client: Generates a private key and gets it signed by the certificate 
authority.
{code}


was (Author: bryanrosan...@gmail.com):
Server:
{code}
bin/tls-toolkit.sh server -D 'CN=localhost,CN=host,CN=account' -t test
tls-toolkit.sh: JAVA_HOME not set; results may vary
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.util.log: Logging initialized 
@1284ms
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.Server: 
jetty-9.3.9.v20160517
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.AbstractConnector: 
Started ServerConnector@be34f20{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.Server: Started @1460ms
Server Started
{code}

Client:
{code}
bin/tls-toolkit.sh client -t test
tls-toolkit.sh: JAVA_HOME not set; results may vary
2016/12/28 15:46:05 INFO [main] 
org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: 
Requesting new certificate from localhost:8443
2016/12/28 15:46:06 INFO [main] 
org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer:
 Requesting certificate with dn CN=HW13384.lan,OU=NIFI from localhost:8443
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
Service client error: Expected cn of localhost but got account

Usage: tls-toolkit service [-h] [args]

Services:
   standalone: Creates certificates and config files for nifi cluster.
   server: Acts as a Certificate Authority that can be used by 

[jira] [Commented] (NIFI-3265) tls-toolkit client fails when tls-toolkit server has multiple cn attributes

[Bryan Rosander (JIRA)]

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

Bryan Rosander commented on NIFI-3265:
--

Server:
{code}
bin/tls-toolkit.sh server -D 'CN=localhost,CN=host,CN=account' -t test
tls-toolkit.sh: JAVA_HOME not set; results may vary
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.util.log: Logging initialized 
@1284ms
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.Server: 
jetty-9.3.9.v20160517
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.AbstractConnector: 
Started ServerConnector@be34f20{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
2016/12/28 15:45:52 INFO [main] org.eclipse.jetty.server.Server: Started @1460ms
Server Started
{code}

Client:
{code}
bin/tls-toolkit.sh client -t test
tls-toolkit.sh: JAVA_HOME not set; results may vary
2016/12/28 15:46:05 INFO [main] 
org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: 
Requesting new certificate from localhost:8443
2016/12/28 15:46:06 INFO [main] 
org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer:
 Requesting certificate with dn CN=HW13384.lan,OU=NIFI from localhost:8443
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: I/O 
exception (java.io.IOException) caught when processing request to 
{s}->https://localhost:8443: Expected cn of localhost but got account
2016/12/28 15:46:06 INFO [main] org.apache.http.impl.execchain.RetryExec: 
Retrying request to {s}->https://localhost:8443
Service client error: Expected cn of localhost but got account

Usage: tls-toolkit service [-h] [args]

Services:
   standalone: Creates certificates and config files for nifi cluster.
   server: Acts as a Certificate Authority that can be used by clients to get 
Certificates
   client: Generates a private key and gets it signed by the certificate 
authority.
{code}

> tls-toolkit client fails when tls-toolkit server has multiple cn attributes
> ---
>
> Key: NIFI-3265
> URL: https://issues.apache.org/jira/browse/NIFI-3265
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.1, 1.0.1
>Reporter: Bryan Rosander
>Priority: Minor
>  Labels: tls-toolkit
>
> Ldap hierarchies can have multiple cn attributes. 
> tls-toolkit in client mode validates the first CN attribute parsed from the 
> distinguished name against the hostname name of the tls-toolkit server to 
> help avoid man-in-the-middle attacks.  
> This check fails when multiple CN attributes are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3265) tls-toolkit client fails when tls-toolkit server has multiple cn attributes

[Bryan Rosander (JIRA)]

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

Bryan Rosander updated NIFI-3265:
-
Description: 
Ldap hierarchies can have multiple cn attributes. 

tls-toolkit in client mode validates the first CN attribute parsed from the 
distinguished name against the hostname name of the tls-toolkit server to help 
avoid man-in-the-middle attacks.  

This check fails when multiple CN attributes are present.

  was:Ldap hierarchies can have multiple cn attributes. tls-toolkit in client 
mode validates the first CN attribute parsed from the distinguished name 
against the hostname name of the tls-toolkit server to help avoid 
man-in-the-middle attacks.  This check fails when multiple CN attributes are 
present.


> tls-toolkit client fails when tls-toolkit server has multiple cn attributes
> ---
>
> Key: NIFI-3265
> URL: https://issues.apache.org/jira/browse/NIFI-3265
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.1, 1.0.1
>Reporter: Bryan Rosander
>Priority: Minor
>  Labels: tls-toolkit
>
> Ldap hierarchies can have multiple cn attributes. 
> tls-toolkit in client mode validates the first CN attribute parsed from the 
> distinguished name against the hostname name of the tls-toolkit server to 
> help avoid man-in-the-middle attacks.  
> This check fails when multiple CN attributes are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3265) tls-toolkit client fails when tls-toolkit server has multiple cn attributes

[Bryan Rosander (JIRA)]

Bryan Rosander created NIFI-3265:


 Summary: tls-toolkit client fails when tls-toolkit server has 
multiple cn attributes
 Key: NIFI-3265
 URL: https://issues.apache.org/jira/browse/NIFI-3265
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.0.1, 1.1.1
Reporter: Bryan Rosander
Priority: Minor


Ldap hierarchies can have multiple cn attributes. tls-toolkit in client mode 
validates the first CN attribute parsed from the distinguished name against the 
hostname name of the tls-toolkit server to help avoid man-in-the-middle 
attacks.  This check fails when multiple CN attributes are present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3249) UpdateAttribute performance improvements

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFI-3249:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> UpdateAttribute performance improvements
> 
>
> Key: NIFI-3249
> URL: https://issues.apache.org/jira/browse/NIFI-3249
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>Priority: Minor
> Attachments: after.png, before.png
>
>
> UpdateAttribute does a lot of work in every onTrigger() that it doesn't need 
> to.
> The default actions map can be built at schedule time so that it doesn't need 
> to be done on every trigger.
> getPropertyValue() can be implemented using ConcurrentMap.computeIfAbsent()
> Update actions can be ignored if there is a delete action for the same 
> attribute.
> Only need to call processSession.updateAttributes() and 
> processSession.deleteAttributes() if there are attributes to update and 
> delete respectively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3249) UpdateAttribute performance improvements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3249:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1356
  
+1

Visually verified code and did a contrib-check build. In standalone tested 
many different updateAttribute configurations hitting: regular update, delete, 
stateful update, and stateful update with advanced rule. All worked as 
expected. Thanks @brosander I will merge it in.


> UpdateAttribute performance improvements
> 
>
> Key: NIFI-3249
> URL: https://issues.apache.org/jira/browse/NIFI-3249
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>Priority: Minor
> Attachments: after.png, before.png
>
>
> UpdateAttribute does a lot of work in every onTrigger() that it doesn't need 
> to.
> The default actions map can be built at schedule time so that it doesn't need 
> to be done on every trigger.
> getPropertyValue() can be implemented using ConcurrentMap.computeIfAbsent()
> Update actions can be ignored if there is a delete action for the same 
> attribute.
> Only need to call processSession.updateAttributes() and 
> processSession.deleteAttributes() if there are attributes to update and 
> delete respectively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3249) UpdateAttribute performance improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 35e8bedcc878ceb67638a50ff6c2506a7bb92c75 in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=35e8bed ]

NIFI-3249 - UpdateAttribute performance improvements

This closes #1356

Signed-off-by: jpercivall 


> UpdateAttribute performance improvements
> 
>
> Key: NIFI-3249
> URL: https://issues.apache.org/jira/browse/NIFI-3249
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>Priority: Minor
> Attachments: after.png, before.png
>
>
> UpdateAttribute does a lot of work in every onTrigger() that it doesn't need 
> to.
> The default actions map can be built at schedule time so that it doesn't need 
> to be done on every trigger.
> getPropertyValue() can be implemented using ConcurrentMap.computeIfAbsent()
> Update actions can be ignored if there is a delete action for the same 
> attribute.
> Only need to call processSession.updateAttributes() and 
> processSession.deleteAttributes() if there are attributes to update and 
> delete respectively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3249) UpdateAttribute performance improvements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3249:
--

Github user asfgit closed the pull request at:

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


> UpdateAttribute performance improvements
> 
>
> Key: NIFI-3249
> URL: https://issues.apache.org/jira/browse/NIFI-3249
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>Priority: Minor
> Attachments: after.png, before.png
>
>
> UpdateAttribute does a lot of work in every onTrigger() that it doesn't need 
> to.
> The default actions map can be built at schedule time so that it doesn't need 
> to be done on every trigger.
> getPropertyValue() can be implemented using ConcurrentMap.computeIfAbsent()
> Update actions can be ignored if there is a delete action for the same 
> attribute.
> Only need to call processSession.updateAttributes() and 
> processSession.deleteAttributes() if there are attributes to update and 
> delete respectively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1356: NIFI-3249 - UpdateAttribute performance improvement...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1356: NIFI-3249 - UpdateAttribute performance improvements

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1356
  
+1

Visually verified code and did a contrib-check build. In standalone tested 
many different updateAttribute configurations hitting: regular update, delete, 
stateful update, and stateful update with advanced rule. All worked as 
expected. Thanks @brosander I will merge it in.


---
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-3228) PutS3Object Does Not Write s3.contenttype Attribute

[James Wing (JIRA)]

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

James Wing updated NIFI-3228:
-
Fix Version/s: 1.2.0

> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
> Fix For: 1.2.0
>
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3228) PutS3Object Does Not Write s3.contenttype Attribute

[James Wing (JIRA)]

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

James Wing updated NIFI-3228:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
> Fix For: 1.2.0
>
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3249) UpdateAttribute performance improvements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3249:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1356
  
Sorry @brosander but I was a bit wrong when talking about the ordering of 
the Delete; I should have tested first. 

It appears that instead of deleting both attributes that were initially 
there and new attributes, it only deletes already present attributes. That is 
because, although it does the delete after the addAttribute, the regex is only 
run on the attributes that already existed[1]. So again it does keep the same 
ordering as before but it's contrary to what we though.

Everything else looks good though. If you could change the documentation 
(and maybe throw in a unit test) for the delete ordering I will +1 and merge.

[1] 
https://github.com/apache/nifi/blob/b519204602a5bd40f219f77ac556563010eca4c1/nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java#L601-L601


> UpdateAttribute performance improvements
> 
>
> Key: NIFI-3249
> URL: https://issues.apache.org/jira/browse/NIFI-3249
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>Priority: Minor
> Attachments: after.png, before.png
>
>
> UpdateAttribute does a lot of work in every onTrigger() that it doesn't need 
> to.
> The default actions map can be built at schedule time so that it doesn't need 
> to be done on every trigger.
> getPropertyValue() can be implemented using ConcurrentMap.computeIfAbsent()
> Update actions can be ignored if there is a delete action for the same 
> attribute.
> Only need to call processSession.updateAttributes() and 
> processSession.deleteAttributes() if there are attributes to update and 
> delete respectively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1356: NIFI-3249 - UpdateAttribute performance improvements

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1356
  
Sorry @brosander but I was a bit wrong when talking about the ordering of 
the Delete; I should have tested first. 

It appears that instead of deleting both attributes that were initially 
there and new attributes, it only deletes already present attributes. That is 
because, although it does the delete after the addAttribute, the regex is only 
run on the attributes that already existed[1]. So again it does keep the same 
ordering as before but it's contrary to what we though.

Everything else looks good though. If you could change the documentation 
(and maybe throw in a unit test) for the delete ordering I will +1 and merge.

[1] 
https://github.com/apache/nifi/blob/b519204602a5bd40f219f77ac556563010eca4c1/nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java#L601-L601


---
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-3228) PutS3Object Does Not Write s3.contenttype Attribute

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3228:
--

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1362
  
@pvillard31 , thanks for fixing this.  I verified that build passes with 
tests and contrib-check, the previously broken integration test 
"testContentType" is fixed by this change, and that the before and after 
attribute behavior works as expected in a simple PutS3Object flow.


> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1362: NIFI-3228 added s3.contenttype in PutS3Object

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1362
  
@pvillard31 , thanks for fixing this.  I verified that build passes with 
tests and contrib-check, the previously broken integration test 
"testContentType" is fixed by this change, and that the before and after 
attribute behavior works as expected in a simple PutS3Object flow.


---
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 #1362: NIFI-3228 added s3.contenttype in PutS3Object

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3228) PutS3Object Does Not Write s3.contenttype Attribute

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3228:
--

Github user asfgit closed the pull request at:

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


> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3228) PutS3Object Does Not Write s3.contenttype Attribute

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-3228 added s3.contenttype in PutS3Object

Signed-off-by: James Wing 

This closes #1362.


> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3264) ScrollElasticsearchHTTP support for sliced scroll

[Josh Harrison (JIRA)]

Josh Harrison created NIFI-3264:
---

 Summary: ScrollElasticsearchHTTP support for sliced scroll
 Key: NIFI-3264
 URL: https://issues.apache.org/jira/browse/NIFI-3264
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Josh Harrison


Elasticsearch 5.x supports sliced scrolls - adding functionality to the 
ScrollElasticsearchHTTP processor to take advantage of this has the potential 
to dramatically speed up extraction of data from an ES cluster with the 
ScrollElasticsearchHTTP processor.

This could either be an explicit processor setting, or could be the default 
behavior when increasing the threading on a ScrollElasticsearchHTTP processor.

See for reference:
https://www.elastic.co/guide/en/elasticsearch/reference/5.1/search-request-scroll.html#sliced-scroll



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3263) QueryElasticsearchHttp - add support for Elasticsearch query DSL

[Josh Harrison (JIRA)]

Josh Harrison created NIFI-3263:
---

 Summary: QueryElasticsearchHttp - add support for Elasticsearch 
query DSL
 Key: NIFI-3263
 URL: https://issues.apache.org/jira/browse/NIFI-3263
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Josh Harrison


The QueryElasticsearchHttp processor currently only supports Lucene style 
queries. From what I've been able to find, Lucene style queries do not support 
aggregations. Providing support for Elasticsearch query DSL in the 
QueryElasticsearchHTTP (and optionally the ScrollElasticsearchHTTP processor) 
would enhance the processor functionality substantially.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3262) PutElasticsearch support for _routing/_parent

[Josh Harrison (JIRA)]

Josh Harrison created NIFI-3262:
---

 Summary: PutElasticsearch support for _routing/_parent
 Key: NIFI-3262
 URL: https://issues.apache.org/jira/browse/NIFI-3262
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Josh Harrison


Due to the structure of the current nifi Elasticsearch indexing processors, it 
doesn't appear possible to specify explicit _routing or _parent fields when 
using any of the PutElasticsearch processors (PutElasticsearch, 
PutElasticsearchHTTP, PutElasticsearch5).
The ability to optionally specify the _parent and/or _routing parameters that 
can be present in a normal bulk index request would be really valuable.

An alternative to adding a handled attribute would be adding support for the 
bulk indexing syntax as defined on 
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html 
- a two line structure where line one contains the indexing instructions in a 
JSON object, and line two contains the content of the object. Each line ends 
with an explicit newline character (\n). This would allow bulk indexing, 
update, delete, etc operations to be carried out through nifi.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3164) Add log to startup stating loading nars

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-3164:
-
Assignee: Pierre Villard
  Status: Patch Available  (was: Open)

> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Pierre Villard
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1365: NIFI-3164 Added message at startup to log NAR loadi...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-3164 Added message at startup to log NAR loading

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/pvillard31/nifi NIFI-3164

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

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


commit a3c4ae1d90955ccacc6c02698f5250515e3c9493
Author: Pierre Villard 
Date:   2016-12-28T17:59:15Z

NIFI-3164 Added message at startup to log NAR loading




---
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-3164) Add log to startup stating loading nars

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3164:
--

GitHub user pvillard31 opened a pull request:

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

NIFI-3164 Added message at startup to log NAR loading

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/pvillard31/nifi NIFI-3164

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

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


commit a3c4ae1d90955ccacc6c02698f5250515e3c9493
Author: Pierre Villard 
Date:   2016-12-28T17:59:15Z

NIFI-3164 Added message at startup to log NAR loading




> Add log to startup stating loading nars
> ---
>
> Key: NIFI-3164
> URL: https://issues.apache.org/jira/browse/NIFI-3164
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Priority: Minor
>
> Today NiFi can take a while to startup while its loading all the nar's.
> However looking at the logs during startup one would not know why service is 
> not yet up.
> It would be helpful if we added an entry in the log that mentions we will be 
> loading nar's and it can take a while. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1856) ExecuteStreamCommand Needs to Consume Standard Error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1856:
--

GitHub user rkarthik29 opened a pull request:

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

NIFI-1856 ExecuteStreamCommand Needs to Consume Standard Error

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/rkarthik29/nifi-1 1856

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

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


commit 963651d094153d3b03e1e9b5ae333189683c5ed6
Author: Kathik Narayanan 
Date:   2016-12-28T17:47:44Z

NIFI-1856 ExecuteStreamCommand Needs to Consume Standard Error




> ExecuteStreamCommand Needs to Consume Standard Error
> 
>
> Key: NIFI-1856
> URL: https://issues.apache.org/jira/browse/NIFI-1856
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Alan Jackoway
>Assignee: Karthik Narayanan
>
> I was using ExecuteStreamProcess to run certain hdfs commands that are tricky 
> to write in nifi but easy in bash (e.g. {{hadoop fs -rm -r 
> /data/*/2014/05/05}})
> However, my larger commands kept hanging even though when I run them from the 
> command line they finish quickly.
> Based on 
> http://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html
>  I believe that ExecuteStreamCommand and possibly other processors need to 
> consume the standard error stream to prevent the processes from blocking when 
> standard error gets filled.
> To reproduce. Create this as ~/write.py
> {code:python}
> import sys
> count = int(sys.argv[1])
> for x in range(count):
> sys.stderr.write("ERROR %d\n" % x)
> sys.stdout.write("OUTPUT %d\n" % x)
> {code}
> Create a flow that goes 
> # GenerateFlowFile - 5 minutes schedule 0 bytes size 
> # ExecuteStreamCommand - Command arguments /Users/alanj/write.py;100 Command 
> Path python
> # PutFile - /tmp/write/
> routing output stream of ExecuteStreamCommand to PutFile
> When you turn everything on, you get 100 lines (not 200) of just the standard 
> output in /tmp/write.
> Next, change the command arguments to /Users/alanj/write.py;10 and turn 
> everything on again. The command will hang.
> I believe that whenever you execute a process the way ExecuteStreamCommand is 
> doing, you need to consume the standard error stream to keep it from 
> blocking. This may also affect things like ExecuteProcess and ExecuteScript 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1364: NIFI-1856 ExecuteStreamCommand Needs to Consume Sta...

[rkarthik29]

GitHub user rkarthik29 opened a pull request:

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

NIFI-1856 ExecuteStreamCommand Needs to Consume Standard Error

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/rkarthik29/nifi-1 1856

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

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


commit 963651d094153d3b03e1e9b5ae333189683c5ed6
Author: Kathik Narayanan 
Date:   2016-12-28T17:47:44Z

NIFI-1856 ExecuteStreamCommand Needs to Consume Standard Error




---
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-3183) Add "command" and "arguments" attributes to FlowFiles generated by ExecuteProcess and ExecuteStreamCommand

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-3183:
-
Assignee: Pierre Villard
  Status: Patch Available  (was: Open)

Added attributes in ExecuteProcess processor. Attributes are already available 
in ExecuteStreamCommand Processor.

> Add "command" and "arguments" attributes to FlowFiles generated by 
> ExecuteProcess and ExecuteStreamCommand
> --
>
> Key: NIFI-3183
> URL: https://issues.apache.org/jira/browse/NIFI-3183
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Randy Gelhausen
>Assignee: Pierre Villard
>
> It's common to use ExecuteProcess/ExecuteStreamCommand to generate new data 
> sources which are routed and handled downstream dynamically based on the 
> command executed (and arguments passed).
> Adding the given command and arguments as attributes of FlowFiles generated 
> by these processors makes this pattern easier to implement.
> See MiNiFi-161/MiNiFi-166 for additional detail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3183) Add "command" and "arguments" attributes to FlowFiles generated by ExecuteProcess and ExecuteStreamCommand

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3183:
--

GitHub user pvillard31 opened a pull request:

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

NIFI-3183 Added command and arguments as FF attributes in ExecuteProc…

…ess processor

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [X] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [X] Have you written or updated unit tests to verify your changes?
- [ ] 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/pvillard31/nifi NIFI-3183

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

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


commit fb5e3620546ec4cf6ca1aeb4f4bdb7b2b25409f9
Author: Pierre Villard 
Date:   2016-12-28T17:30:24Z

NIFI-3183 Added command and arguments as FF attributes in ExecuteProcess 
processor




> Add "command" and "arguments" attributes to FlowFiles generated by 
> ExecuteProcess and ExecuteStreamCommand
> --
>
> Key: NIFI-3183
> URL: https://issues.apache.org/jira/browse/NIFI-3183
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Randy Gelhausen
>
> It's common to use ExecuteProcess/ExecuteStreamCommand to generate new data 
> sources which are routed and handled downstream dynamically based on the 
> command executed (and arguments passed).
> Adding the given command and arguments as attributes of FlowFiles generated 
> by these processors makes this pattern easier to implement.
> See MiNiFi-161/MiNiFi-166 for additional detail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1363: NIFI-3183 Added command and arguments as FF attribu...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-3183 Added command and arguments as FF attributes in ExecuteProc…

…ess processor

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [X] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [X] Have you written or updated unit tests to verify your changes?
- [ ] 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/pvillard31/nifi NIFI-3183

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

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


commit fb5e3620546ec4cf6ca1aeb4f4bdb7b2b25409f9
Author: Pierre Villard 
Date:   2016-12-28T17:30:24Z

NIFI-3183 Added command and arguments as FF attributes in ExecuteProcess 
processor




---
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-3249) UpdateAttribute performance improvements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3249:
--

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

https://github.com/apache/nifi/pull/1356#discussion_r94056185
  
--- Diff: 
nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java
 ---
@@ -259,6 +270,14 @@ public void onScheduled(final ProcessContext context) 
throws IOException {
 
 context.getStateManager().setState(tempMap, Scope.LOCAL);
 }
+
+defaultActions = getDefaultActions(context.getProperties());
+debugEnabled = getLogger().isDebugEnabled();
+}
+
+@OnUnscheduled
+public void onUnScheduled() {
+defaultActions = null;
--- End diff --

good catch


> UpdateAttribute performance improvements
> 
>
> Key: NIFI-3249
> URL: https://issues.apache.org/jira/browse/NIFI-3249
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>Priority: Minor
> Attachments: after.png, before.png
>
>
> UpdateAttribute does a lot of work in every onTrigger() that it doesn't need 
> to.
> The default actions map can be built at schedule time so that it doesn't need 
> to be done on every trigger.
> getPropertyValue() can be implemented using ConcurrentMap.computeIfAbsent()
> Update actions can be ignored if there is a delete action for the same 
> attribute.
> Only need to call processSession.updateAttributes() and 
> processSession.deleteAttributes() if there are attributes to update and 
> delete respectively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1356: NIFI-3249 - UpdateAttribute performance improvement...

[brosander]

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

https://github.com/apache/nifi/pull/1356#discussion_r94056185
  
--- Diff: 
nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java
 ---
@@ -259,6 +270,14 @@ public void onScheduled(final ProcessContext context) 
throws IOException {
 
 context.getStateManager().setState(tempMap, Scope.LOCAL);
 }
+
+defaultActions = getDefaultActions(context.getProperties());
+debugEnabled = getLogger().isDebugEnabled();
+}
+
+@OnUnscheduled
+public void onUnScheduled() {
+defaultActions = null;
--- End diff --

good catch


---
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-3228) PutS3Object Does Not Write s3.contenttype Attribute

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3228:
--

Github user jvwing commented on the issue:

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


> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1362: NIFI-3228 added s3.contenttype in PutS3Object

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1362
  
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] [Updated] (NIFI-3153) Update AWS SDK

[James Wing (JIRA)]

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

James Wing updated NIFI-3153:
-
Status: Patch Available  (was: Open)

> Update AWS SDK
> --
>
> Key: NIFI-3153
> URL: https://issues.apache.org/jira/browse/NIFI-3153
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: James Wing
>Assignee: James Wing
>Priority: Minor
>
> I propose to update NiFi's AWS SDK to v1.11.68 (December 16, 2016) or later 
> to get support for recent AWS updates:
> * New Regions - ap-south-1 (Mumbai), ca-central-1 (Canada), eu-west-2 
> (London), us-east-2 (Ohio)
> * New AWS services
> NiFi's current SDK is v1.11.8 (June 16, 2016).  I looked through the [AWS SDK 
> for Java release notes|https://aws.amazon.com/releasenotes/Java?browse=1] to 
> search for upgrade complications.  Most of the changes look fine -- mostly 
> new services, regions, and simple bug fixes.   I found one item of interest:
> * New [Retry 
> Throttling|https://aws.amazon.com/blogs/developer/introducing-retry-throttling/]
>  feature has been made the default rather than optional starting in 
> [v1.11.12|https://aws.amazon.com/releasenotes/Java/2878241577606051].  It 
> looks very sensible to not flog the system pointlessly if requests are 
> already failing, and I  expect it to be a benefit for most NiFi/AWS use 
> cases.  However, it is the kind of sneaky behavioral change I was looking for.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3261) Create joint processor and controller service archetype

[Aldrin Piri (JIRA)]

Aldrin Piri created NIFI-3261:
-

 Summary: Create joint processor and controller service archetype
 Key: NIFI-3261
 URL: https://issues.apache.org/jira/browse/NIFI-3261
 Project: Apache NiFi
  Issue Type: Task
  Components: Tools and Build
Reporter: Aldrin Piri


It would be helpful to have a Maven archetype that provides the boilerplate 
functionality for a NAR bundle that includes both a controller service and 
processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1856) ExecuteStreamCommand Needs to Consume Standard Error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1856:
--

Github user rkarthik29 closed the pull request at:

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


> ExecuteStreamCommand Needs to Consume Standard Error
> 
>
> Key: NIFI-1856
> URL: https://issues.apache.org/jira/browse/NIFI-1856
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Alan Jackoway
>Assignee: Karthik Narayanan
>
> I was using ExecuteStreamProcess to run certain hdfs commands that are tricky 
> to write in nifi but easy in bash (e.g. {{hadoop fs -rm -r 
> /data/*/2014/05/05}})
> However, my larger commands kept hanging even though when I run them from the 
> command line they finish quickly.
> Based on 
> http://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html
>  I believe that ExecuteStreamCommand and possibly other processors need to 
> consume the standard error stream to prevent the processes from blocking when 
> standard error gets filled.
> To reproduce. Create this as ~/write.py
> {code:python}
> import sys
> count = int(sys.argv[1])
> for x in range(count):
> sys.stderr.write("ERROR %d\n" % x)
> sys.stdout.write("OUTPUT %d\n" % x)
> {code}
> Create a flow that goes 
> # GenerateFlowFile - 5 minutes schedule 0 bytes size 
> # ExecuteStreamCommand - Command arguments /Users/alanj/write.py;100 Command 
> Path python
> # PutFile - /tmp/write/
> routing output stream of ExecuteStreamCommand to PutFile
> When you turn everything on, you get 100 lines (not 200) of just the standard 
> output in /tmp/write.
> Next, change the command arguments to /Users/alanj/write.py;10 and turn 
> everything on again. The command will hang.
> I believe that whenever you execute a process the way ExecuteStreamCommand is 
> doing, you need to consume the standard error stream to keep it from 
> blocking. This may also affect things like ExecuteProcess and ExecuteScript 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1355: NIFI-1856 ExecuteStreamCommand Needs to Consume Sta...

[rkarthik29]

Github user rkarthik29 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #34: MINIFI-150 Adjusting ignored source ignore...

[apiri]

GitHub user apiri opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/34

MINIFI-150 Adjusting ignored source ignore files

MINIFI-150 Adjusting ignored source ignore files to prevent inclusion of 
git and supporting CMake directories.

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

$ git pull https://github.com/apiri/nifi-minifi-cpp MINIFI-150

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

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


commit 0911b778c003780b3a5155de50ade7de6f51f4e4
Author: Aldrin Piri 
Date:   2016-12-28T16:33:04Z

MINIFI-150 Adjusting source ignore files to prevent inclusion of git and 
supporting CMake directories.




---
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 #1356: NIFI-3249 - UpdateAttribute performance improvement...

[JPercivall]

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

https://github.com/apache/nifi/pull/1356#discussion_r94050652
  
--- Diff: 
nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-processor/src/main/java/org/apache/nifi/processors/attributes/UpdateAttribute.java
 ---
@@ -259,6 +270,14 @@ public void onScheduled(final ProcessContext context) 
throws IOException {
 
 context.getStateManager().setState(tempMap, Scope.LOCAL);
 }
+
+defaultActions = getDefaultActions(context.getProperties());
+debugEnabled = getLogger().isDebugEnabled();
+}
+
+@OnUnscheduled
+public void onUnScheduled() {
+defaultActions = null;
--- End diff --

This needs to be in the "OnStopped", not the "OnUnscheduled". 
"OnUnscheduled" will get executed once the user hits the "stop" button and 
there could still be threads running, leading to the NPE below. ("OnStopped" 
runs once all threads running the ontrigger have stopped)

![screen shot 2016-12-28 at 11 28 11 
am](https://cloud.githubusercontent.com/assets/11302527/21526179/39ea5e8c-ccf0-11e6-8653-a3d8e7e02f04.png)



---
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-3260) Official Docker Image

[Jeremy Dyer (JIRA)]

Jeremy Dyer created NIFI-3260:
-

 Summary: Official Docker Image
 Key: NIFI-3260
 URL: https://issues.apache.org/jira/browse/NIFI-3260
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Tools and Build
Reporter: Jeremy Dyer
Assignee: Jeremy Dyer


This JIRA is for setting up a Docker folder structure within the NiFi source 
code as discussed in the dev mailing list at

https://lists.apache.org/thread.html/e905a559cb01b30f1a7032cec5c9605685f27a65bdf7fee41b735089@%3Cdev.nifi.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3231) PutTCP and PutUDP should support EL for host and port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3231:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/1361
  
Good catch @ddewaele, thank you!


> PutTCP and PutUDP should support EL for host and port
> -
>
> Key: NIFI-3231
> URL: https://issues.apache.org/jira/browse/NIFI-3231
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.1.1
>Reporter: Bryan Bende
>Assignee: Pierre Villard
>
> PutTCP and PutUDP should support expression language (without a flow file) 
> for host and port in order to make use of the variable registry and reference 
> different hosts and ports per environment.
> Relevant code:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutTCP.java#L110
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutUDP.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1361: NIFI-3231 Added EL support to hostname and port in PutTCP/...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/1361
  
Good catch @ddewaele, thank you!


---
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-2693) Documentation fails to load if .nar unpacking fails at startup

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky commented on NIFI-2693:


[~d3v3l0] Actually, thank you for reminding. Will do my best to target it for 
the next release. Shouldn't be that difficult.

> Documentation fails to load if .nar unpacking fails at startup
> --
>
> Key: NIFI-2693
> URL: https://issues.apache.org/jira/browse/NIFI-2693
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joey Frazee
>Assignee: Oleg Zhurakousky
>
> The NiFi documentation can fail to load and throws an NPE if some but not all 
> of the .nars don't unpack at startup.
> {code}
> HTTP ERROR 500
> Problem accessing /nifi-docs/documentation. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
> at 
> org.apache.nifi.web.docs.DocumentationController.doGet(DocumentationController.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A warning does get logged, but it doesn't give you any indication of which 
> .nar file is broken [1], so while it's easy to spot that the problem is with 
> the .nar unpacking, you have no idea which .nar is causing it.
> The NPE appears to be because when a .nar doesn't unpack, it doesn't return 
> the extensionMapping thus far [2], so NiFi is operational with a subset of 
> the .nars, but doesn't get access to docs for those since instead of a 
> partial extensionMapping it's just null.
> 1. 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarUnpacker.java#L162
> 2. 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarUnpacker.java#L169



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2693) Documentation fails to load if .nar unpacking fails at startup

[Dieter Kling (JIRA)]

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

Dieter Kling commented on NIFI-2693:


Any progress here?

> Documentation fails to load if .nar unpacking fails at startup
> --
>
> Key: NIFI-2693
> URL: https://issues.apache.org/jira/browse/NIFI-2693
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joey Frazee
>Assignee: Oleg Zhurakousky
>
> The NiFi documentation can fail to load and throws an NPE if some but not all 
> of the .nars don't unpack at startup.
> {code}
> HTTP ERROR 500
> Problem accessing /nifi-docs/documentation. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
> at 
> org.apache.nifi.web.docs.DocumentationController.doGet(DocumentationController.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A warning does get logged, but it doesn't give you any indication of which 
> .nar file is broken [1], so while it's easy to spot that the problem is with 
> the .nar unpacking, you have no idea which .nar is causing it.
> The NPE appears to be because when a .nar doesn't unpack, it doesn't return 
> the extensionMapping thus far [2], so NiFi is operational with a subset of 
> the .nars, but doesn't get access to docs for those since instead of a 
> partial extensionMapping it's just null.
> 1. 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarUnpacker.java#L162
> 2. 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarUnpacker.java#L169



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3228) PutS3Object Does Not Write s3.contenttype Attribute

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-3228:
-
Assignee: Pierre Villard
  Status: Patch Available  (was: Open)

> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.1, 1.1.0
>Reporter: James Wing
>Assignee: Pierre Villard
>Priority: Trivial
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3228) PutS3Object Does Not Write s3.contenttype Attribute

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3228:
--

GitHub user pvillard31 opened a pull request:

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

NIFI-3228 added s3.contenttype in PutS3Object

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [X] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [X] Have you written or updated unit tests to verify your changes?
- [ ] 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/pvillard31/nifi NIFI-3228

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

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


commit 72cc8b1d0204b1d2079674f63874e5e4ab88f42c
Author: Pierre Villard 
Date:   2016-12-28T14:26:28Z

NIFI-3228 added s3.contenttype in PutS3Object




> PutS3Object Does Not Write s3.contenttype Attribute
> ---
>
> Key: NIFI-3228
> URL: https://issues.apache.org/jira/browse/NIFI-3228
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.0.1
>Reporter: James Wing
>Priority: Trivial
>
> The PutS3Object processor documents that it writes the "s3.contenttype" 
> attribute.  There is an integration test for this, 
> ITPutS3Object.testContentType, but it is failing.  I did not find code in 
> PutS3Object that attempts to write this attribute.
> PutS3Object should be fixed to write the attribute, or the documentation and 
> test should be adjusted to match the behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1362: NIFI-3228 added s3.contenttype in PutS3Object

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-3228 added s3.contenttype in PutS3Object

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [X] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [X] Have you written or updated unit tests to verify your changes?
- [ ] 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/pvillard31/nifi NIFI-3228

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

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


commit 72cc8b1d0204b1d2079674f63874e5e4ab88f42c
Author: Pierre Villard 
Date:   2016-12-28T14:26:28Z

NIFI-3228 added s3.contenttype in PutS3Object




---
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-3231) PutTCP and PutUDP should support EL for host and port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3231:
--

Github user ddewaele commented on the issue:

https://github.com/apache/nifi/pull/1361
  
@pvillard31 : Was looking at the same ... I think PutSplunk is also 
impacted and will also need to call `evaluateAttributeExpressions`.


> PutTCP and PutUDP should support EL for host and port
> -
>
> Key: NIFI-3231
> URL: https://issues.apache.org/jira/browse/NIFI-3231
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.1.1
>Reporter: Bryan Bende
>Assignee: Pierre Villard
>
> PutTCP and PutUDP should support expression language (without a flow file) 
> for host and port in order to make use of the variable registry and reference 
> different hosts and ports per environment.
> Relevant code:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutTCP.java#L110
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutUDP.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1361: NIFI-3231 Added EL support to hostname and port in PutTCP/...

[ddewaele]

Github user ddewaele commented on the issue:

https://github.com/apache/nifi/pull/1361
  
@pvillard31 : Was looking at the same ... I think PutSplunk is also 
impacted and will also need to call `evaluateAttributeExpressions`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (NIFI-3226) Elastic search url should support expression language

[Pierre Villard (JIRA)]

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

Pierre Villard resolved NIFI-3226.
--
   Resolution: Duplicate
 Assignee: Matt Burgess
Fix Version/s: 1.2.0

> Elastic search url should support expression language 
> --
>
> Key: NIFI-3226
> URL: https://issues.apache.org/jira/browse/NIFI-3226
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Frank Maritato
>Assignee: Matt Burgess
> Fix For: 1.2.0
>
>
> We have different environments, dev, staging, production, each with different 
> elastic search servers. Instead of having to manually change the url for each 
> elastic search processor can you please support expression language for this 
> property so I can specify ${elasticsearch.url} ?
> The following two processors would need this change:
> * PutElasticsearchHttp
> * FetchElasticsearchHttp
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-3231) PutTCP and PutUDP should support EL for host and port

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-3231:
-
Assignee: Pierre Villard
  Status: Patch Available  (was: Open)

> PutTCP and PutUDP should support EL for host and port
> -
>
> Key: NIFI-3231
> URL: https://issues.apache.org/jira/browse/NIFI-3231
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.1.1, 1.1.0, 1.0.0
>Reporter: Bryan Bende
>Assignee: Pierre Villard
>
> PutTCP and PutUDP should support expression language (without a flow file) 
> for host and port in order to make use of the variable registry and reference 
> different hosts and ports per environment.
> Relevant code:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutTCP.java#L110
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutUDP.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-3231) PutTCP and PutUDP should support EL for host and port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3231:
--

GitHub user pvillard31 opened a pull request:

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

NIFI-3231 Added EL support to hostname and port in PutTCP/UDP

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [X] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [X] Have you written or updated unit tests to verify your changes?
- [ ] 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/pvillard31/nifi NIFI-3231

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

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


commit 639e1927b0f0fb8d6f715e42a9d0fe6933280739
Author: Pierre Villard 
Date:   2016-12-28T13:39:22Z

NIFI-3231 Added EL support to hostname and port in PutTCP/UDP




> PutTCP and PutUDP should support EL for host and port
> -
>
> Key: NIFI-3231
> URL: https://issues.apache.org/jira/browse/NIFI-3231
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.1.1
>Reporter: Bryan Bende
>
> PutTCP and PutUDP should support expression language (without a flow file) 
> for host and port in order to make use of the variable registry and reference 
> different hosts and ports per environment.
> Relevant code:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutTCP.java#L110
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutUDP.java#L94



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1361: NIFI-3231 Added EL support to hostname and port in ...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-3231 Added EL support to hostname and port in PutTCP/UDP

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [X] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [X] Have you written or updated unit tests to verify your changes?
- [ ] 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/pvillard31/nifi NIFI-3231

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

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


commit 639e1927b0f0fb8d6f715e42a9d0fe6933280739
Author: Pierre Villard 
Date:   2016-12-28T13:39:22Z

NIFI-3231 Added EL support to hostname and port in PutTCP/UDP




---
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-3254) NiFi RPG definition URL doesn't support underscores

[Pierre Villard (JIRA)]

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

Pierre Villard commented on NIFI-3254:
--

This is due to the fact that {{URI.create(string)}} is not accepting underscore 
in the string. See here
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=5049974
https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

I believe we do not want to change the behavior here.

> NiFi RPG definition URL doesn't support underscores
> ---
>
> Key: NIFI-3254
> URL: https://issues.apache.org/jira/browse/NIFI-3254
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.1
>Reporter: Viacheslav Kalashnikov
>
> Looks like that RPG definition URL doesn't support underscores.
> How to reproduce:
> 1st try:
> Put RPG on canvas.
> to type in URL property: http://nifi-node:8080/nifi
> Click ADD.
> RPG will be successfully added
> 2nd try:
> Put RPG on canvas.
> to type in URL property: http://nifi_node:8080/nifi
> Click ADD.
> Error message "The specified remote process group URL is malformed: 
> http://nifi_node:8080/nifi; will be received.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (NIFI-3127) NullPointerException in SplitText on empty files

[Joseph Gresock (JIRA)]

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

Joseph Gresock closed NIFI-3127.


> NullPointerException in SplitText on empty files
> 
>
> Key: NIFI-3127
> URL: https://issues.apache.org/jira/browse/NIFI-3127
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
> Fix For: 1.2.0
>
>
> This can be reproduced by routing an empty file to SplitText and setting the 
> line split count to 1.
> 2016-11-30 13:00:01,133 ERROR [Timer-Driven Process Thread-62] 
> o.a.nifi.processors.standard.SplitText 
> SplitText[id=7ef1aa84-233c-31d6-b34d-b169660f5284] 
> SplitText[id=7ef1aa84-233c-31d6-b34d-b169660f5284] failed to process due to 
> java.lang.NullPointerException; rolling back session: 
> java.lang.NullPointerException
> 2016-11-30 13:00:01,133 ERROR [Timer-Driven Process Thread-62] 
> o.a.nifi.processors.standard.SplitText
> java.lang.NullPointerException: null
> at 
> org.apache.nifi.processors.standard.SplitText.generateSplitFlowFiles(SplitText.java:292)
>  ~[nifi-standard-processors-1.1.0.jar:1.1.0]
> at 
> org.apache.nifi.processors.standard.SplitText.onTrigger(SplitText.java:253) 
> ~[nifi-standard-processors-1.1.0.jar:1.1.0]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-1.1.0.jar:1.1.0]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
>  [nifi-framework-core-1.1.0.jar:1.1.0]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-1.1.0.jar:1.1.0]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-1.1.0.jar:1.1.0]
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
>  [nifi-framework-core-1.1.0.jar:1.1.0]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)