[GitHub] nifi pull request #1025: Trying to fix Travis build failure.

[ijokarumawak]

Github user ijokarumawak closed the pull request at:

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


---
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 #1008: NIFI-2763 S3 processors do not work with older S3-compatib...

[baank]

Github user baank commented on the issue:

https://github.com/apache/nifi/pull/1008
  
Entirely up to you James.

The signer is applied AWS wide so potentially could be useful for other 
non-AWS implementations of say SQS/SNS. That said the bug is only directly 
affecting S3.


---
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-2763) S3 processors do not work with older S3-compatible object stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2763:
--

Github user baank commented on the issue:

https://github.com/apache/nifi/pull/1008
  
Entirely up to you James.

The signer is applied AWS wide so potentially could be useful for other 
non-AWS implementations of say SQS/SNS. That said the bug is only directly 
affecting S3.


> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[jira] [Commented] (NIFI-2763) S3 processors do not work with older S3-compatible object stores

[Franco (JIRA)]

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

Franco commented on NIFI-2763:
--

James:

We are using the CEPH object store. V4 signer support was only added into their 
trunk in March this year.

> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[jira] [Commented] (NIFI-2728) Travis CI experiences GC overhead limit exceeded

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2728:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/985
  
@ijokarumawak 


> Travis CI experiences GC overhead limit exceeded 
> -
>
> Key: NIFI-2728
> URL: https://issues.apache.org/jira/browse/NIFI-2728
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Andre
>
> travis-ci is currently broken and frequently reporting 
> {{GC overhead limit exceeded}}



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

[GitHub] nifi issue #985: NIFI-2728 - Attempt to fix travis-ci build woes

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/985
  
@ijokarumawak 


---
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 #1025: Trying to fix Travis build failure.

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1025
  
@ijokarumawak 

there's already a PR for that keen for you to look at

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

and merge it if you don't mind




---
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 #1025: Trying to fix Travis build failure.

[ijokarumawak]

GitHub user ijokarumawak opened a pull request:

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

Trying to fix Travis build failure.

Adding JVM option for maven.

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

$ git pull https://github.com/ijokarumawak/nifi travis-oom

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

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


commit 56f34e64e195ebed7e2395ad28246e3e23641b57
Author: Koji Kawamura 
Date:   2016-09-16T01:06:54Z

Trying to fix Travis build failure.




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

[jira] [Commented] (NIFI-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2266:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/999
  
Yes @alopresto, I noticed it, hopefully I've done all the required 
modifications.


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
> Fix For: 1.1.0, 0.8.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



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

[GitHub] nifi issue #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/999
  
Yes @alopresto, I noticed it, hopefully I've done all the required 
modifications.


---
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 #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
Thanks @pvillard31 . Be careful with `StandardProcessorTestRunner` -- I 
think my IDE cleaned up the `` typing on line 392 which will 
cause an issue with Java 7 compatibility. 


---
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-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2266:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
Thanks @pvillard31 . Be careful with `StandardProcessorTestRunner` -- I 
think my IDE cleaned up the `` typing on line 392 which will 
cause an issue with Java 7 compatibility. 


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
> Fix For: 1.1.0, 0.8.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



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

[jira] [Resolved] (NIFI-2373) GetHTTP - not working with sites that only support TLS

[Pierre Villard (JIRA)]

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

Pierre Villard resolved NIFI-2373.
--
   Resolution: Fixed
 Assignee: Andy LoPresto
Fix Version/s: 0.8.0
   1.1.0

Fixed with:
https://github.com/apache/nifi/pull/999

> GetHTTP - not working with sites that only support TLS
> --
>
> Key: NIFI-2373
> URL: https://issues.apache.org/jira/browse/NIFI-2373
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.5.1, 0.7.0
> Environment: Windows & Debian
>Reporter: Tim
>Assignee: Andy LoPresto
> Fix For: 1.1.0, 0.8.0
>
> Attachments: Test_GetHTTP.xml
>
>
> Hi,
> I'm using GetHTTP processor to download a file from nvd.nist.gov.
> Recently, they have disabled support for SSL and only allow connections to be 
> established through TLS 1.1 or TLS 1.2. 
> Since this change, the GetHTTP processor fails to download the file and 
> returns a generic "javax.net.ssl.SSLHandshakeException: Remote host closed 
> connection during handshake" error.
> How to reproduce:
>  - Create GetHTTP Processor
>  - Create StandardSSLContextService
>  - Configure URL & test download:
>https://nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-Modified.xml.gz
> What I've tried so far:
>  - Changing the SSL Protocol attribute of the SSLContextService (to TLS, TLS 
> 1.1 or TLS 1.2, no difference)
>  - Disabling SSL with the following startup argument: 
> -Dhttps.protocols=TLSv1.2



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

[jira] [Resolved] (NIFI-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[Pierre Villard (JIRA)]

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

Pierre Villard resolved NIFI-2266.
--
   Resolution: Fixed
Fix Version/s: 0.8.0
   1.1.0

> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
> Fix For: 1.1.0, 0.8.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



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

[jira] [Commented] (NIFI-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2266:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/999
  
Thanks @alopresto, everything is OK! I merged it to master. I also followed 
recommendations from @mosermw to cherry-pick into 0.x with Java 7 compatibility.


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



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

[GitHub] nifi issue #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/999
  
Thanks @alopresto, everything is OK! I merged it to master. I also followed 
recommendations from @mosermw to cherry-pick into 0.x with Java 7 compatibility.


---
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 #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF subversion and git services (JIRA)]

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

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

Commit 639e6d6a76ba92dbefd259861e2efc2ba2247f43 in nifi's branch refs/heads/0.x 
from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=639e6d6 ]

NIFI-2266 Refactored GetHTTP processor to use SSLContext protocol vs. 
hard-coded TLSv1.

This closes #999.


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



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

[GitHub] nifi-minifi pull request #33: Minifi 108

[JPercivall]

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

https://github.com/apache/nifi-minifi/pull/33#discussion_r79056475
  
--- Diff: 
minifi-toolkit/minifi-toolkit-configuration/src/test/resources/StressTestFramework.yml
 ---
@@ -13,6 +13,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+MiNiFi Config Version: 2
--- End diff --

Unless I'm missing it, I don't see any modifications to the 
System_Admin_Guide.md (where the yml properties are described). Could you 
update them with the new id property and the maybe a bit about versioning of 
the config schemas?


---
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 pull request #33: Minifi 108

[JPercivall]

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

https://github.com/apache/nifi-minifi/pull/33#discussion_r79067507
  
--- Diff: 
minifi-toolkit/minifi-toolkit-configuration/src/test/resources/CsvToJson.yml ---
@@ -13,6 +13,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+MiNiFi Config Version: 2
--- End diff --

The config files in the toolkit were updated but not the ones in 
minifi-bootstrap or the default one that gets bundled (in minifi-resources). 
Could you update those too?

Kinda sucks that we have test yml files in multiple locations that will 
need to be updated each time there is a change to the schema. Any thoughts to 
remedy this/if you think it's worth it?


---
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 pull request #33: Minifi 108

[JPercivall]

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

https://github.com/apache/nifi-minifi/pull/33#discussion_r79064157
  
--- Diff: 
minifi-commons/minifi-commons-schema/src/main/java/org/apache/nifi/minifi/commons/schema/ConfigSchema.java
 ---
@@ -42,10 +44,14 @@
  *
  */
 public class ConfigSchema extends BaseSchema {
-public static final String 
FOUND_THE_FOLLOWING_DUPLICATE_PROCESSOR_NAMES = "Found the following duplicate 
processor names: ";
-public static final String 
FOUND_THE_FOLLOWING_DUPLICATE_CONNECTION_NAMES = "Found the following duplicate 
connection names: ";
+public static final String FOUND_THE_FOLLOWING_DUPLICATE_PROCESSOR_IDS 
= "Found the following duplicate processor ids: ";
+public static final String 
FOUND_THE_FOLLOWING_DUPLICATE_CONNECTION_IDS = "Found the following duplicate 
connection ids: ";
 public static final String 
FOUND_THE_FOLLOWING_DUPLICATE_REMOTE_PROCESSING_GROUP_NAMES = "Found the 
following duplicate remote processing group names: ";
+public static final String 
FOUND_THE_FOLLOWING_DUPLICATE_REMOTE_INPUT_PORT_IDS = "Found the following 
duplicate remote input port ids: ";
+public static final String FOUND_THE_FOLLOWING_DUPLICATE_IDS = "Found 
the following ids that occur both in Processors and Remote Input Ports: ";
--- End diff --

This brings up a good point that all the ids within a PG (ie. all the ids 
we have) will have to be unique. So will need to add a check including 
connections and RPGs themselves.


---
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 pull request #33: Minifi 108

[JPercivall]

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

https://github.com/apache/nifi-minifi/pull/33#discussion_r79055685
  
--- Diff: 
minifi-toolkit/minifi-toolkit-configuration/src/test/resources/InvokeHttpMiNiFiTemplateTest.yml
 ---
@@ -255,8 +273,8 @@ Remote Processing Groups:
   timeout: 30 sec
--- End diff --

I believe RPGs will have similar problems as Processors with duplicate 
names.

Given that and to keep consistency, do you think we should add ids for them 
as well?


---
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-2727) Modify TailFile processor to allow Expression Language for initial file propery

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2727:
--

GitHub user apsaltis opened a pull request:

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

Adding EL support to TailFile processor

Adding in support for EL to be provided with both the "File to Tail" and 
the "Rolling Filename Pattern". The use case(s) behind this are documented in 
JIRA NIFI-2727

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

$ git pull https://github.com/apsaltis/nifi NIFI-2727

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

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


commit 277fc009bb2597345a00a3ecde1a8d3c7195fdfa
Author: Andrew Psaltis 
Date:   2016-09-14T17:15:25Z

NIFI-2727 -- Adding EL support to TailFile

commit c1de30a13094f2254328f43fd5635b691382e93c
Author: Andrew Psaltis 
Date:   2016-09-15T21:05:06Z

Adding in support for EL to be provided with both the initial file name and 
the tail pattern, per JIRA NIFI-2727




> Modify TailFile processor to allow Expression Language for initial file 
> propery
> ---
>
> Key: NIFI-2727
> URL: https://issues.apache.org/jira/browse/NIFI-2727
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrew Psaltis
>Assignee: Andrew Psaltis
>
> There are times between designign a MiNiFi flow that the initial file to be 
> Tailed is not know at design time. Often the design and deploy may be 
> seperates by days and thus non-deterministic. Therefore, the initial file 
> name is not known ahead of time. This could be fixed by modifying the 
> config.yml on the agent box when it is deployed, however, that seems to be a 
> more brittle solution and puts the burden on the person doing the agent 
> deploy. This model may also not work when the MiNiFi management facilities 
> are realized.



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

[jira] [Resolved] (NIFI-2784) Command line site-to-site client in toolkit would be useful

[Bryan Rosander (JIRA)]

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

Bryan Rosander resolved NIFI-2784.
--
Resolution: Duplicate

Jira froze and I accidentally created this twice

> Command line site-to-site client in toolkit would be useful
> ---
>
> Key: NIFI-2784
> URL: https://issues.apache.org/jira/browse/NIFI-2784
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>
> A command line site-to-site client in the toolkit would be beneficial in 
> several scenarios:
> 1. Easily pipe data into, out of NiFi flows using command line utilities or 
> other (non-java) programs makes integrating other tools with NiFi trivial
> 2. Easier to debug site-to-site issues when only one NiFi instance is 
> involved in the troubleshooting process
> 3. Dev testing site-to-site is easier command line reproduction of 
> issues/validation of functionality



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

[jira] [Commented] (NIFI-1942) Create a processor to validate CSV against a user-supplied schema

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1942:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/476
  
Thanks @JPercivall !
I did the modification in the ``OnSchedule`` method and it is now working 
as expected. I also took the liberty to squash my commits. Let me know if there 
is something else.


> Create a processor to validate CSV against a user-supplied schema
> -
>
> Key: NIFI-1942
> URL: https://issues.apache.org/jira/browse/NIFI-1942
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
> Attachments: ValidateCSV.xml
>
>
> In order to extend the set of "quality control" processors, it would be 
> interesting to have a processor validating CSV formatted flow files against a 
> user-specified schema.
> Flow file validated against schema would be routed to "valid" relationship 
> although flow file not validated against schema would be routed to "invalid" 
> relationship.



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

[jira] [Created] (NIFI-2784) Command line site-to-site client in toolkit would be useful

[Bryan Rosander (JIRA)]

Bryan Rosander created NIFI-2784:


 Summary: Command line site-to-site client in toolkit would be 
useful
 Key: NIFI-2784
 URL: https://issues.apache.org/jira/browse/NIFI-2784
 Project: Apache NiFi
  Issue Type: New Feature
Reporter: Bryan Rosander


A command line site-to-site client in the toolkit would be beneficial in 
several scenarios:
1. Easily pipe data into, out of NiFi flows using command line utilities or 
other (non-java) programs makes integrating other tools with NiFi trivial
2. Easier to debug site-to-site issues when only one NiFi instance is involved 
in the troubleshooting process
3. Dev testing site-to-site is easier command line reproduction of 
issues/validation of functionality



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

[jira] [Created] (NIFI-2783) Command line site-to-site client in toolkit would be useful

[Bryan Rosander (JIRA)]

Bryan Rosander created NIFI-2783:


 Summary: Command line site-to-site client in toolkit would be 
useful
 Key: NIFI-2783
 URL: https://issues.apache.org/jira/browse/NIFI-2783
 Project: Apache NiFi
  Issue Type: New Feature
Reporter: Bryan Rosander


A command line site-to-site client in the toolkit would be beneficial in 
several scenarios:
1. Easily pipe data into, out of NiFi flows using command line utilities or 
other (non-java) programs makes integrating other tools with NiFi trivial
2. Easier to debug site-to-site issues when only one NiFi instance is involved 
in the troubleshooting process
3. Dev testing site-to-site is easier command line reproduction of 
issues/validation of functionality



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

[jira] [Assigned] (NIFI-1870) Restore go to source/destination capability

[Matt Gilman (JIRA)]

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

Matt Gilman reassigned NIFI-1870:
-

Assignee: Matt Gilman

> Restore go to source/destination capability
> ---
>
> Key: NIFI-1870
> URL: https://issues.apache.org/jira/browse/NIFI-1870
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>




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

[jira] [Updated] (NIFI-2164) ConsumeJMS should allow user to configure trade-off between 'best effort' and 'guaranteed receipt' of data

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky updated NIFI-2164:
---
Status: Reopened  (was: Reopened)

> ConsumeJMS should allow user to configure trade-off between 'best effort' and 
> 'guaranteed receipt' of data
> --
>
> Key: NIFI-2164
> URL: https://issues.apache.org/jira/browse/NIFI-2164
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Oleg Zhurakousky
>
> Currently the ConsumeJMS Processor uses auto-acknowledge acknowledgement. 
> This is beneficial for many use cases but could result in data loss if NiFi 
> is shut down. We should expose a 'Delivery Guarantee' property that allows 
> the user to choose between 'Best Effort', which will provide better 
> performance or 'Guaranteed Receipt', which will guarantee that data has been 
> committed to NiFi's Content & FlowFile Repositories before acknowledging the 
> message.



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

[GitHub] nifi-minifi-cpp issue #11: Minifi 103

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/11
  
Looks good.  Merged


---
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 #11: Minifi 103

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
@pvillard31 I really appreciate your persistence with this one. Not sure 
why I missed that the last time. 

I added a method to clear the flowfile queue in the test runner, because it 
seems that multiple test cases are causing side-effects. Each should now be 
completely independent. 

(From the latest commit message:)
```
All tests pass (in test suite when running individually or as a suite, and 
when running entire project via Maven).

Will raise additional Jira for more full-featured addition of 
clearQueue mechanics to StandardProcessorTestRunner and related interfaces.```

Please verify on your end. 


---
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 pull request #32: MINIFI-104 - Making connection ids filesystem ...

[brosander]

Github user brosander closed the pull request at:

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


---
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-2771) REST API does not compress responses

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2771:
--

Github user asfgit closed the pull request at:

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


> REST API does not compress responses
> 
>
> Key: NIFI-2771
> URL: https://issues.apache.org/jira/browse/NIFI-2771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> Responses from the REST API do not appear to be compressed. In the logs, we 
> see warnings:
> 2016-09-13 15:22:23,124 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
> Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
> 2016-09-13 15:22:23,124 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
> GzipFilter is deprecated. Use GzipHandler



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

[GitHub] nifi pull request #1020: Ensuring responses from the REST API are compressed

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2771) REST API does not compress responses

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky updated NIFI-2771:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> REST API does not compress responses
> 
>
> Key: NIFI-2771
> URL: https://issues.apache.org/jira/browse/NIFI-2771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> Responses from the REST API do not appear to be compressed. In the logs, we 
> see warnings:
> 2016-09-13 15:22:23,124 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
> Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
> 2016-09-13 15:22:23,124 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
> GzipFilter is deprecated. Use GzipHandler



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

[jira] [Commented] (NIFI-2771) REST API does not compress responses

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2771:
- Using GzipHandler instead of GzipFilter.

This closes #1020


> REST API does not compress responses
> 
>
> Key: NIFI-2771
> URL: https://issues.apache.org/jira/browse/NIFI-2771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> Responses from the REST API do not appear to be compressed. In the logs, we 
> see warnings:
> 2016-09-13 15:22:23,124 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
> Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
> 2016-09-13 15:22:23,124 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
> GzipFilter is deprecated. Use GzipHandler



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

[GitHub] nifi-minifi pull request #33: Minifi 108

[brosander]

GitHub user brosander opened a pull request:

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

Minifi 108



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

$ git pull https://github.com/brosander/nifi-minifi MINIFI-108

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

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


commit 1143b336df143c28051c558e68f20dd50d824d00
Author: Bryan Rosander 
Date:   2016-09-07T21:36:32Z

MINIFI-104 - Making connection ids filesystem friendly, unique

commit 8a36cae4566ecbbd4d90cb0540e831655fc84cf6
Author: Bryan Rosander 
Date:   2016-09-09T17:39:15Z

MINIFI-104 - Introducing configuration versioning, adding id to connection

commit dab92ae488fc50d5cff01dd8fe62fe1d258c771c
Author: Bryan Rosander 
Date:   2016-09-09T18:11:14Z

MINIFI-104 - Renaming version property

commit 012565d1501d08c54dcdf144613592d32d56f6b9
Author: Bryan Rosander 
Date:   2016-09-15T14:31:16Z

MINIFI-108 - Using ids for processors, source, destination




---
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-2774) ConsumeJMS processor losses messages on NiFi restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2774:
--

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

https://github.com/apache/nifi/pull/1022#discussion_r79015458
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -78,22 +77,24 @@
  */
 @Override
 protected void rendezvousWithJms(ProcessContext context, 
ProcessSession processSession) throws ProcessException {
-final JMSResponse response = this.targetResource.consume();
-if (response != null){
-FlowFile flowFile = processSession.create();
-flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
-@Override
-public void process(final OutputStream out) throws 
IOException {
-out.write(response.getMessageBody());
-}
-});
-Map jmsHeaders = response.getMessageHeaders();
-flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
-processSession.getProvenanceReporter().receive(flowFile, 
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
-processSession.transfer(flowFile, REL_SUCCESS);
-} else {
-context.yield();
-}
+this.targetResource.consume(response -> {
+if (response != null) {
+FlowFile flowFile = processSession.create();
+flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
+@Override
+public void process(final OutputStream out) throws 
IOException {
+out.write(response.getMessageBody());
+}
+});
+Map jmsHeaders = 
response.getMessageHeaders();
+flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
+processSession.getProvenanceReporter().receive(flowFile,
+
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
+processSession.transfer(flowFile, REL_SUCCESS);
--- End diff --

@ckmcd good catch. Indeed that window exists and we need to commit session 
within the callback and before message ack. Will address.


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[GitHub] nifi pull request #1022: NIFI-2774 changed the default ACK mode to CLIENT

[olegz]

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

https://github.com/apache/nifi/pull/1022#discussion_r79015458
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -78,22 +77,24 @@
  */
 @Override
 protected void rendezvousWithJms(ProcessContext context, 
ProcessSession processSession) throws ProcessException {
-final JMSResponse response = this.targetResource.consume();
-if (response != null){
-FlowFile flowFile = processSession.create();
-flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
-@Override
-public void process(final OutputStream out) throws 
IOException {
-out.write(response.getMessageBody());
-}
-});
-Map jmsHeaders = response.getMessageHeaders();
-flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
-processSession.getProvenanceReporter().receive(flowFile, 
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
-processSession.transfer(flowFile, REL_SUCCESS);
-} else {
-context.yield();
-}
+this.targetResource.consume(response -> {
+if (response != null) {
+FlowFile flowFile = processSession.create();
+flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
+@Override
+public void process(final OutputStream out) throws 
IOException {
+out.write(response.getMessageBody());
+}
+});
+Map jmsHeaders = 
response.getMessageHeaders();
+flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
+processSession.getProvenanceReporter().receive(flowFile,
+
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
+processSession.transfer(flowFile, REL_SUCCESS);
--- End diff --

@ckmcd good catch. Indeed that window exists and we need to commit session 
within the callback and before message ack. Will address.


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

[jira] [Comment Edited] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky edited comment on NIFI-2774 at 9/15/16 5:12 PM:
-

Ok, will make it configurable. 
However there are few caveats to keep in mind; 
While Session defines 4 different QoS modes, one is related to transactions 
(_SESSION_TRANSACTED_) which itself brings a whole other level of JMS 
integration (i.e., transaction managers, XA etc).
Also, given that this new JMS support oriented to be portable across multiple 
providers, JMS specifications allows for custom QoS modes while implementing 
Session. This means that aside from the 4 defined by JMS specification there 
may be other once specific to providers. It is just an integer value known to 
Session implementation.

So, for now I advocate for excluding the support for _SESSION_TRANSACTED_ since 
it is primarily designed for integrating with third party transaction managers 
while from the QoS perspective pertaining to this particular issue would 
accomplish the same as _CLIENT_ACKNOWLEDGE_.
Given that QoS value used is just an integer and to support provider specific 
QoS the new configuration field will be of Integer type defaulting to 2 
(_CLIENT_ACKNOWLEDGE_), thus allowing provider specific QoS values be used. 
However, since we don't know if those custom QoS modes will require additional 
configuration options I am somewhat reluctant to do even that, which means IMHO 
the best we can do at he moment is expose *only* 3 QoS modes defined by JMS 
spec - _CLIENT_ACKNOWLEDGE - default, AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE_.


was (Author: ozhurakousky):
Ok, will make it configurable. 
However there are few caveats to keep in mind; 
While Session defines 4 different QoS modes, one is related to transactions 
(_SESSION_TRANSACTED_) which itself brings a whole other level of JMS 
integration (i.e., transaction managers, XA etc).
Also, given that this new JMS support oriented to be portable across multiple 
providers, JMS specifications allows for custom QoS modes while implementing 
Session. This means that aside from the 4 defined by JMS specification there 
may be other once specific to providers. It is just an integer value known to 
Session implementation.

So, for now I advocate for excluding the support for _SESSION_TRANSACTED_ since 
it is primarily designed for integrating with third party transaction managers 
while from the QoS perspective pertaining to this particular issue would 
accomplish the same as _CLIENT_ACKNOWLEDGE_.
Given that QoS value used is just an integer and to support provider specific 
QoS the new configuration field will be of Integer type defaulting to 2 
(_CLIENT_ACKNOWLEDGE_), thus allowing provider specific QoS values be used. 
However, since we don't know if those custom QoS modes will require additional 
configuration options I am somewhat reluctant to do even that, which means IMHO 
the best we can do at he moment is expose *only* 3 QoS modes defined by JMS 
spec - _CLIENT_ACKNOWLEDGE - default, AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE.

> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[jira] [Commented] (NIFI-1942) Create a processor to validate CSV against a user-supplied schema

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1942:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/476
  
@pvillard31, I know what the problem with the end-line characters is. When 
going from the UI to Java, the characters are escaped so that what you input is 
transferred over to Java as is. So when you type the characters "\" and "\n" 
into the UI the Java string will end up being those two characters *not* the 
interpreted value "\n".

There's been some discussion about it before and how we need to make some 
change but it hasn't been a top priority. For now what is done, is something 
like is done here[1]. Where the default value is escaped and then in the 
OnScheduled[2] or as a separate method[3] it is interpreted. 

[1] 
https://github.com/apache/nifi/blob/1373bf672586ba5ddcfa697c45c832ccc79425cb/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/listen/AbstractListenEventBatchingProcessor.java#L61-L61
[2] 
https://github.com/apache/nifi/blob/1373bf672586ba5ddcfa697c45c832ccc79425cb/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/listen/AbstractListenEventBatchingProcessor.java#L97-L97
[3] 
https://github.com/apache/nifi/blob/cd846c8d627efb2606f72b6af009358dec27be63/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/put/AbstractPutEventProcessor.java#L566-L566


> Create a processor to validate CSV against a user-supplied schema
> -
>
> Key: NIFI-1942
> URL: https://issues.apache.org/jira/browse/NIFI-1942
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Minor
> Attachments: ValidateCSV.xml
>
>
> In order to extend the set of "quality control" processors, it would be 
> interesting to have a processor validating CSV formatted flow files against a 
> user-specified schema.
> Flow file validated against schema would be routed to "valid" relationship 
> although flow file not validated against schema would be routed to "invalid" 
> relationship.



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

[GitHub] nifi issue #476: NIFI-1942 Processor to validate CSV against user-supplied s...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/476
  
@pvillard31, I know what the problem with the end-line characters is. When 
going from the UI to Java, the characters are escaped so that what you input is 
transferred over to Java as is. So when you type the characters "\" and "\n" 
into the UI the Java string will end up being those two characters *not* the 
interpreted value "\n".

There's been some discussion about it before and how we need to make some 
change but it hasn't been a top priority. For now what is done, is something 
like is done here[1]. Where the default value is escaped and then in the 
OnScheduled[2] or as a separate method[3] it is interpreted. 

[1] 
https://github.com/apache/nifi/blob/1373bf672586ba5ddcfa697c45c832ccc79425cb/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/listen/AbstractListenEventBatchingProcessor.java#L61-L61
[2] 
https://github.com/apache/nifi/blob/1373bf672586ba5ddcfa697c45c832ccc79425cb/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/listen/AbstractListenEventBatchingProcessor.java#L97-L97
[3] 
https://github.com/apache/nifi/blob/cd846c8d627efb2606f72b6af009358dec27be63/nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/put/AbstractPutEventProcessor.java#L566-L566


---
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 #1022: NIFI-2774 changed the default ACK mode to CLIENT

[ckmcd]

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

https://github.com/apache/nifi/pull/1022#discussion_r79008301
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -78,22 +77,24 @@
  */
 @Override
 protected void rendezvousWithJms(ProcessContext context, 
ProcessSession processSession) throws ProcessException {
-final JMSResponse response = this.targetResource.consume();
-if (response != null){
-FlowFile flowFile = processSession.create();
-flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
-@Override
-public void process(final OutputStream out) throws 
IOException {
-out.write(response.getMessageBody());
-}
-});
-Map jmsHeaders = response.getMessageHeaders();
-flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
-processSession.getProvenanceReporter().receive(flowFile, 
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
-processSession.transfer(flowFile, REL_SUCCESS);
-} else {
-context.yield();
-}
+this.targetResource.consume(response -> {
+if (response != null) {
+FlowFile flowFile = processSession.create();
+flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
+@Override
+public void process(final OutputStream out) throws 
IOException {
+out.write(response.getMessageBody());
+}
+});
+Map jmsHeaders = 
response.getMessageHeaders();
+flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
+processSession.getProvenanceReporter().receive(flowFile,
+
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
+processSession.transfer(flowFile, REL_SUCCESS);
--- End diff --

Question: doesn't the session need to be explicitly committed here, before 
the message gets acknowledged, in order to complete the chain of custody?  
Otherwise I believe there is a small window where if NiFi crashed before 
session is committed by scheduler, the acknowledged message can be lost.


---
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-2774) ConsumeJMS processor losses messages on NiFi restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2774:
--

Github user joewitt commented on the issue:

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

Other.commit
Nifi.commit

This means at most once.  Loss is possible but dupes are not.


Nifi.commit
Other.commit

This means at least once.  Dupes are possible but loss is not.

Default mode should always be at least once.


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[GitHub] nifi issue #1022: NIFI-2774 changed the default ACK mode to CLIENT

[joewitt]

Github user joewitt commented on the issue:

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

Other.commit
Nifi.commit

This means at most once.  Loss is possible but dupes are not.


Nifi.commit
Other.commit

This means at least once.  Dupes are possible but loss is not.

Default mode should always be at least once.


---
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-2707) "Bring to Front" function in UI does not to work after exiting group

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2707:
--
Status: Patch Available  (was: In Progress)

> "Bring to Front" function in UI does not to work after exiting group
> 
>
> Key: NIFI-2707
> URL: https://issues.apache.org/jira/browse/NIFI-2707
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> I have some connections that overlap one another. I right-clicked on one and 
> clicked Bring to Front. This worked as expected. However, after I left the 
> Process Group and came back, the connection that was brought to the front is 
> no longer in front.



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

[jira] [Commented] (NIFI-2707) "Bring to Front" function in UI does not to work after exiting group

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2707:
--

GitHub user mcgilman opened a pull request:

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

Ensuring Connection zIndex is honored

NIFI-2707:
- Ensuring that connections are always sorted accordingly to their zIndex. 
This preserves the 'bring to front' settings.

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

$ git pull https://github.com/mcgilman/nifi NIFI-2707

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

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






> "Bring to Front" function in UI does not to work after exiting group
> 
>
> Key: NIFI-2707
> URL: https://issues.apache.org/jira/browse/NIFI-2707
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> I have some connections that overlap one another. I right-clicked on one and 
> clicked Bring to Front. This worked as expected. However, after I left the 
> Process Group and came back, the connection that was brought to the front is 
> no longer in front.



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

[GitHub] nifi pull request #1023: Ensuring Connection zIndex is honored

[mcgilman]

GitHub user mcgilman opened a pull request:

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

Ensuring Connection zIndex is honored

NIFI-2707:
- Ensuring that connections are always sorted accordingly to their zIndex. 
This preserves the 'bring to front' settings.

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

$ git pull https://github.com/mcgilman/nifi NIFI-2707

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

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






---
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 #803: nifi-1214c Mock Framework should allow order-indepen...

[JPercivall]

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

https://github.com/apache/nifi/pull/803#discussion_r79011075
  
--- Diff: nifi-mock/src/main/java/org/apache/nifi/util/MockFlowFile.java ---
@@ -290,4 +291,18 @@ public long getLineageStartIndex() {
 public long getQueueDateIndex() {
 return 0;
 }
+
+public boolean isAttributeEqual(final String attributeName, final 
String expectedValue) {
+// unknown attribute name, so cannot be equal.
+if (attributes.containsKey(attributeName) == false)
+return false;
+
+String value = attributes.get(attributeName);
+return Objects.equals(expectedValue, value);
+}
+
+public boolean isContentEqual(String excpected) {
+final String value = new String(this.data, 
Charset.forName("UTF-8"));
+return Objects.equals(excpected, value);
--- End diff --

Actually I'm confused why this is added when "assertContentEquals"[1] and 
it's various overloading methods exist.

[1] 
https://github.com/apache/nifi/blob/master/nifi-mock/src/main/java/org/apache/nifi/util/MockFlowFile.java#L233-L233


---
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-2774) ConsumeJMS processor losses messages on NiFi restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2774:
--

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

https://github.com/apache/nifi/pull/1022#discussion_r79008301
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -78,22 +77,24 @@
  */
 @Override
 protected void rendezvousWithJms(ProcessContext context, 
ProcessSession processSession) throws ProcessException {
-final JMSResponse response = this.targetResource.consume();
-if (response != null){
-FlowFile flowFile = processSession.create();
-flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
-@Override
-public void process(final OutputStream out) throws 
IOException {
-out.write(response.getMessageBody());
-}
-});
-Map jmsHeaders = response.getMessageHeaders();
-flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
-processSession.getProvenanceReporter().receive(flowFile, 
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
-processSession.transfer(flowFile, REL_SUCCESS);
-} else {
-context.yield();
-}
+this.targetResource.consume(response -> {
+if (response != null) {
+FlowFile flowFile = processSession.create();
+flowFile = processSession.write(flowFile, new 
OutputStreamCallback() {
+@Override
+public void process(final OutputStream out) throws 
IOException {
+out.write(response.getMessageBody());
+}
+});
+Map jmsHeaders = 
response.getMessageHeaders();
+flowFile = 
this.updateFlowFileAttributesWithJmsHeaders(jmsHeaders, flowFile, 
processSession);
+processSession.getProvenanceReporter().receive(flowFile,
+
context.getProperty(DESTINATION).evaluateAttributeExpressions().getValue());
+processSession.transfer(flowFile, REL_SUCCESS);
--- End diff --

Question: doesn't the session need to be explicitly committed here, before 
the message gets acknowledged, in order to complete the chain of custody?  
Otherwise I believe there is a small window where if NiFi crashed before 
session is committed by scheduler, the acknowledged message can be lost.


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[jira] [Commented] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2774:
---

It certainly is the case that default behavior should ack and intuitively 
result in the most reliable behavior possible between two systems.  However, it 
is also entirely reasonable for a user to choose alternative QoS behavior.  It 
is quite common to do things like listen while on for sampling and for maximum 
performance.

While NiFi as a framework might not be about JMS options (i mean it isn't about 
any specific protocols options) the application, which is what users care 
about, certainly should offer JMS processors which let them choose from 
relevant JMS options.


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[jira] [Updated] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

[Christopher McDermott (JIRA)]

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

Christopher McDermott updated NIFI-2774:

Attachment: 2774.patch

Here in an alternate patch that is Java 7 compatible and therefore suited for 
0.x.  Its much less sophisticated then [~ozhurakousky]'s PR but I believe that 
it is functionally equivalent.

> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[GitHub] nifi-minifi-cpp issue #11: Minifi 103

[apiri]

Github user apiri commented on the issue:

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

[GitHub] nifi-minifi-cpp pull request #10: MINIFI-97 minifi.sh stop fix

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #803: nifi-1214c Mock Framework should allow order-indepen...

[JPercivall]

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

https://github.com/apache/nifi/pull/803#discussion_r78998108
  
--- Diff: nifi-mock/src/main/java/org/apache/nifi/util/MockFlowFile.java ---
@@ -290,4 +291,18 @@ public long getLineageStartIndex() {
 public long getQueueDateIndex() {
 return 0;
 }
+
+public boolean isAttributeEqual(final String attributeName, final 
String expectedValue) {
+// unknown attribute name, so cannot be equal.
+if (attributes.containsKey(attributeName) == false)
+return false;
+
+String value = attributes.get(attributeName);
+return Objects.equals(expectedValue, value);
+}
+
+public boolean isContentEqual(String excpected) {
+final String value = new String(this.data, 
Charset.forName("UTF-8"));
+return Objects.equals(excpected, value);
--- End diff --

Instead of comparing a String to binary data (and forcing the "UTF-8" 
character encoding), I think it would be better to have the parameter be a 
byte[] and do Arrays.equal() on them. Thoughts? 


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

[jira] [Updated] (NIFI-2735) Add processor to perform simple aggregations

[Matt Burgess (JIRA)]

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

Matt Burgess updated NIFI-2735:
---
Description: 
This is a proposal for a new processor (AggregateValues, for example) that can 
perform simple aggregation operations such as count, sum, average, min, max, 
and concatenate, over a set of "related" flow files. For example, when a JSON 
file is split on an array (using the SplitJson processor), the total count of 
the splits, the index of each split, and the unique identifier (shared by each 
split) are stored as attributes in each flow file sent to the "splits" 
relationship:

https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.SplitJson/index.html

These attributes are the "fragment.*" attributes in the documentation for 
SplitText, SplitXml, and SplitJson, for example.

Such a processor could perform these operations for each flow file split from 
the original document, and when all documents from a split have been processed, 
a flow file could be transferred to an "aggregate" relationship containing 
attributes for the operation, aggregate value, etc.

An interesting application of this (besides the actual aggregation operations) 
is that you can use the "aggregate" relationship as an event trigger. For 
example if you need to wait until all files from a group are processed, you can 
use AggregateValues and the "aggregate" relationship to indicate downstream 
that the entire group has been processed. If there is not a Split processor 
upstream, then the attributes (fragment.*) would have to be manipulated by the 
data flow designer, but this can be accomplished with other processors 
(including the scripting processors if necessary). 

  was:
This is a proposal for a new processor (AggregateValues, for example) that can 
perform simple aggregation operations such as count, sum, average, min, max, 
and concatenate, over a set of "related" flow files. For example, when a JSON 
file is split on an array (using the SplitJson processor), the total count of 
the splits, the index of each split, and the unique indentifier (shared by each 
split) are stored as attributes in each flow file sent to the "splits" 
relationship:

https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.SplitJson/index.html

These attributes are the "fragment.*" attributes in the documentation for 
SplitText, SplitXml, and SplitJson, for example.

Such a processor could perform these operations for each flow file split from 
the original document, and when all documents from a split have been processed, 
a flow file could be transferred to an "aggregate" relationship containing 
attributes for the operation, aggregate value, etc.

An interesting application of this (besides the actual aggregation operations) 
is that you can use the "aggregate" relationship as an event trigger. For 
example if you need to wait until all files from a group are processed, you can 
use AggregateValues and the "aggregate" relationship to indicate downstream 
that the entire group has been processed. If there is not a Split processor 
upstream, then the attributes (fragment.*) would have to be manipulated by the 
data flow designer, but this can be accomplished with other processors 
(including the scripting processors if necessary). 


> Add processor to perform simple aggregations
> 
>
> Key: NIFI-2735
> URL: https://issues.apache.org/jira/browse/NIFI-2735
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> This is a proposal for a new processor (AggregateValues, for example) that 
> can perform simple aggregation operations such as count, sum, average, min, 
> max, and concatenate, over a set of "related" flow files. For example, when a 
> JSON file is split on an array (using the SplitJson processor), the total 
> count of the splits, the index of each split, and the unique identifier 
> (shared by each split) are stored as attributes in each flow file sent to the 
> "splits" relationship:
> https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.SplitJson/index.html
> These attributes are the "fragment.*" attributes in the documentation for 
> SplitText, SplitXml, and SplitJson, for example.
> Such a processor could perform these operations for each flow file split from 
> the original document, and when all documents from a split have been 
> processed, a flow file could be transferred to an "aggregate" relationship 
> containing attributes for the operation, aggregate value, etc.
> An interesting application of this (besides the actual aggregation 
> operations) is that you can use the "aggregate" relationship as an event 
> trigger. For example if 

[jira] [Commented] (NIFI-2777) Provenance Events' Node Identifier not set when querying only 1 node in cluster

[Christopher Gambino (JIRA)]

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

Christopher Gambino commented on NIFI-2777:
---

The issue was resolved by setting nifi.cluster.is.node to false.  True was the 
default configuration in my install.

> Provenance Events' Node Identifier not set when querying only 1 node in 
> cluster
> ---
>
> Key: NIFI-2777
> URL: https://issues.apache.org/jira/browse/NIFI-2777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.1.0
>
>
> If I open the Provenance page and search for a FlowFile UUID and restrict the 
> search to a specific node, the Node Identifier is not populated in the events 
> that are returned. As a result, I cannot view the lineage.



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

[GitHub] nifi-minifi-cpp issue #10: MINIFI-97 minifi.sh stop fix

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/10
  
Looks good, thanks for finding and patching up.

Will merge in shortly.


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

[jira] [Commented] (NIFI-2777) Provenance Events' Node Identifier not set when querying only 1 node in cluster

[Christopher Gambino (JIRA)]

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

Christopher Gambino commented on NIFI-2777:
---

I encountered the error when hitting list que on a one node install.  I used 
ambari to install nifi.  I am unable to view individual flow files.

> Provenance Events' Node Identifier not set when querying only 1 node in 
> cluster
> ---
>
> Key: NIFI-2777
> URL: https://issues.apache.org/jira/browse/NIFI-2777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.1.0
>
>
> If I open the Provenance page and search for a FlowFile UUID and restrict the 
> search to a specific node, the Node Identifier is not populated in the events 
> that are returned. As a result, I cannot view the lineage.



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

[GitHub] nifi-minifi-cpp issue #10: MINIFI-97 minifi.sh stop fix

[apiri]

Github user apiri commented on the issue:

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


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

[jira] [Commented] (NIFI-2700) Move Spring CachingConnectionFactory to the Service

[Chad Zobrisky (JIRA)]

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

Chad Zobrisky commented on NIFI-2700:
-

Oleg,

I'd like to work on this ticket if that is okay, get my hands dirty with
NIFI some more.

Chad

On Thu, Sep 15, 2016 at 10:42 AM Oleg Zhurakousky (JIRA) 



> Move Spring CachingConnectionFactory to the Service
> ---
>
> Key: NIFI-2700
> URL: https://issues.apache.org/jira/browse/NIFI-2700
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Chad Zobrisky
>Assignee: Oleg Zhurakousky
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently the Spring CachingConnectionFactory is at the processor level which 
> only provides for reuse of session/connection when the processor disconnects 
> and reconnects.  Moving it to the JMSConnectionFactoryProvider would allow 
> reuse across processors.



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

[jira] [Commented] (NIFI-2700) Move Spring CachingConnectionFactory to the Service

[Chad Zobrisky (JIRA)]

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

Chad Zobrisky commented on NIFI-2700:
-

If there are no objections to this ticket's work, I'd like to attempt it and 
submit a MR.

> Move Spring CachingConnectionFactory to the Service
> ---
>
> Key: NIFI-2700
> URL: https://issues.apache.org/jira/browse/NIFI-2700
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Chad Zobrisky
>Assignee: Oleg Zhurakousky
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently the Spring CachingConnectionFactory is at the processor level which 
> only provides for reuse of session/connection when the processor disconnects 
> and reconnects.  Moving it to the JMSConnectionFactoryProvider would allow 
> reuse across processors.



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

[jira] [Reopened] (NIFI-2164) ConsumeJMS should allow user to configure trade-off between 'best effort' and 'guaranteed receipt' of data

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky reopened NIFI-2164:


> ConsumeJMS should allow user to configure trade-off between 'best effort' and 
> 'guaranteed receipt' of data
> --
>
> Key: NIFI-2164
> URL: https://issues.apache.org/jira/browse/NIFI-2164
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Oleg Zhurakousky
>
> Currently the ConsumeJMS Processor uses auto-acknowledge acknowledgement. 
> This is beneficial for many use cases but could result in data loss if NiFi 
> is shut down. We should expose a 'Delivery Guarantee' property that allows 
> the user to choose between 'Best Effort', which will provide better 
> performance or 'Guaranteed Receipt', which will guarantee that data has been 
> committed to NiFi's Content & FlowFile Repositories before acknowledging the 
> message.



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

[jira] [Resolved] (NIFI-2164) ConsumeJMS should allow user to configure trade-off between 'best effort' and 'guaranteed receipt' of data

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky resolved NIFI-2164.

Resolution: Duplicate

> ConsumeJMS should allow user to configure trade-off between 'best effort' and 
> 'guaranteed receipt' of data
> --
>
> Key: NIFI-2164
> URL: https://issues.apache.org/jira/browse/NIFI-2164
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Oleg Zhurakousky
>
> Currently the ConsumeJMS Processor uses auto-acknowledge acknowledgement. 
> This is beneficial for many use cases but could result in data loss if NiFi 
> is shut down. We should expose a 'Delivery Guarantee' property that allows 
> the user to choose between 'Best Effort', which will provide better 
> performance or 'Guaranteed Receipt', which will guarantee that data has been 
> committed to NiFi's Content & FlowFile Repositories before acknowledging the 
> message.



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

[jira] [Assigned] (NIFI-2778) If a Provenance Query is canceled, the repository doesn't stop immediately

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky reassigned NIFI-2778:
--

Assignee: Oleg Zhurakousky

> If a Provenance Query is canceled, the repository doesn't stop immediately
> --
>
> Key: NIFI-2778
> URL: https://issues.apache.org/jira/browse/NIFI-2778
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Oleg Zhurakousky
> Fix For: 1.1.0
>
>
> When a Provenance Query is issued and then canceled, the result object is 
> marked as canceled, but repository continues to search. It should instead 
> stop querying lucene and stop reading events from the provenance log files



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

[jira] [Assigned] (NIFI-2751) When a processor pulls a batch of FlowFiles, it keeps pulling from the same inbound connection instead of round-robin'ing

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky reassigned NIFI-2751:
--

Assignee: Oleg Zhurakousky

> When a processor pulls a batch of FlowFiles, it keeps pulling from the same 
> inbound connection instead of round-robin'ing
> -
>
> Key: NIFI-2751
> URL: https://issues.apache.org/jira/browse/NIFI-2751
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Oleg Zhurakousky
>  Labels: beginner, easyfix, framework, newbie
> Fix For: 1.1.0
>
>
> When a Processor calls ProcessSession.get(int) or 
> ProcessSession.get(FlowFileFilter), the FlowFiles only come from the first 
> inbound connection, unless that connection is empty or doesn't have enough 
> FlowFiles to complete the get() call. It should instead round-robin between 
> the incoming connections, just as ProcessSession.get() does.



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

[jira] [Assigned] (NIFI-2700) Move Spring CachingConnectionFactory to the Service

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky reassigned NIFI-2700:
--

Assignee: Oleg Zhurakousky

> Move Spring CachingConnectionFactory to the Service
> ---
>
> Key: NIFI-2700
> URL: https://issues.apache.org/jira/browse/NIFI-2700
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Chad Zobrisky
>Assignee: Oleg Zhurakousky
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently the Spring CachingConnectionFactory is at the processor level which 
> only provides for reuse of session/connection when the processor disconnects 
> and reconnects.  Moving it to the JMSConnectionFactoryProvider would allow 
> reuse across processors.



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

[GitHub] nifi pull request #1003: NIFI-2755 - Fixes minor typo in Developers Guide

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1020: Ensuring responses from the REST API are compressed

[olegz]

Github user olegz commented on the issue:

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


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

[jira] [Commented] (NIFI-2755) Minor typo on Developer Guide's Controller Services section

[ASF subversion and git services (JIRA)]

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

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

Commit aa933a194110b58a8c2fe07013f37a6fc1d10e71 in nifi's branch 
refs/heads/master from Andre F de Miranda
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=aa933a1 ]

NIFI-2755 - Fixes minor typo in Developers Guide

This closes #1003


> Minor typo on Developer Guide's Controller Services section
> ---
>
> Key: NIFI-2755
> URL: https://issues.apache.org/jira/browse/NIFI-2755
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Andre
>Assignee: Andre
>Priority: Trivial
> Fix For: 1.1.0
>
>
> {{Rather, they are used Processors, Reporting Tasks, and other Controller 
> Services.}}
> should read
> Rather, they are used *by* Processors, Reporting Tasks, and other Controller 
> Services.



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

[jira] [Commented] (NIFI-2711) Allow extension of nifi-assembly pom to override properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2711:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/972
  
@brosander there seems to be merge conflicts now. Would you mind addressing 
them?


> Allow extension of nifi-assembly pom to override properties
> ---
>
> Key: NIFI-2711
> URL: https://issues.apache.org/jira/browse/NIFI-2711
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> As part of the tls-toolkit work, the nifi.properties filtering was moved to 
> nifi-resources.  This didn't take into account usecases where overriding the 
> nifi.properties in an assembly was desired by those extending our assembly.



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

[GitHub] nifi issue #972: NIFI-2711 - Making top-level nifi-assemblies directory with...

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/972
  
@brosander there seems to be merge conflicts now. Would you mind addressing 
them?


---
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-2755) Minor typo on Developer Guide's Controller Services section

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2755:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1003
  
+1, merging


> Minor typo on Developer Guide's Controller Services section
> ---
>
> Key: NIFI-2755
> URL: https://issues.apache.org/jira/browse/NIFI-2755
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Andre
>Assignee: Andre
>Priority: Trivial
> Fix For: 1.1.0
>
>
> {{Rather, they are used Processors, Reporting Tasks, and other Controller 
> Services.}}
> should read
> Rather, they are used *by* Processors, Reporting Tasks, and other Controller 
> Services.



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

[jira] [Commented] (NIFI-2755) Minor typo on Developer Guide's Controller Services section

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2755:
--

Github user asfgit closed the pull request at:

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


> Minor typo on Developer Guide's Controller Services section
> ---
>
> Key: NIFI-2755
> URL: https://issues.apache.org/jira/browse/NIFI-2755
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Andre
>Assignee: Andre
>Priority: Trivial
> Fix For: 1.1.0
>
>
> {{Rather, they are used Processors, Reporting Tasks, and other Controller 
> Services.}}
> should read
> Rather, they are used *by* Processors, Reporting Tasks, and other Controller 
> Services.



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

[jira] [Resolved] (NIFI-2755) Minor typo on Developer Guide's Controller Services section

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky resolved NIFI-2755.

Resolution: Fixed

> Minor typo on Developer Guide's Controller Services section
> ---
>
> Key: NIFI-2755
> URL: https://issues.apache.org/jira/browse/NIFI-2755
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Andre
>Assignee: Andre
>Priority: Trivial
> Fix For: 1.1.0
>
>
> {{Rather, they are used Processors, Reporting Tasks, and other Controller 
> Services.}}
> should read
> Rather, they are used *by* Processors, Reporting Tasks, and other Controller 
> Services.



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

[jira] [Updated] (NIFI-1342) PostHTTP User Agent property should be pre-populated with client default

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky updated NIFI-1342:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> PostHTTP User Agent property should be pre-populated with client default
> 
>
> Key: NIFI-1342
> URL: https://issues.apache.org/jira/browse/NIFI-1342
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 0.4.1
>Reporter: Aldrin Piri
>Assignee: Pierre Villard
>Priority: Trivial
> Fix For: 1.1.0, 0.8.0
>
>
> Currently, PostHTTP shows an empty string for the User Agent property which 
> is used in web requests, but this actually results in the default of the 
> client being used.  For clarity, and if the backing library supports it, 
> getting the User Agent string used by the library as the default processor 
> User Agent property would be a nice improvement.



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

[GitHub] nifi issue #1003: NIFI-2755 - Fixes minor typo in Developers Guide

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1003
  
+1, merging


---
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 #1021: NIFI-1342 Added default User-Agent in PostHttp

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1342) PostHTTP User Agent property should be pre-populated with client default

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky updated NIFI-1342:
---
Fix Version/s: 0.8.0
   1.1.0

> PostHTTP User Agent property should be pre-populated with client default
> 
>
> Key: NIFI-1342
> URL: https://issues.apache.org/jira/browse/NIFI-1342
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 0.4.1
>Reporter: Aldrin Piri
>Assignee: Pierre Villard
>Priority: Trivial
> Fix For: 1.1.0, 0.8.0
>
>
> Currently, PostHTTP shows an empty string for the User Agent property which 
> is used in web requests, but this actually results in the default of the 
> client being used.  For clarity, and if the backing library supports it, 
> getting the User Agent string used by the library as the default processor 
> User Agent property would be a nice improvement.



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

[jira] [Commented] (NIFI-2781) Broken bower install

[Scott Aslan (JIRA)]

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

Scott Aslan commented on NIFI-2781:
---

Looks like the latest bower does not play well with this maven plugin: 
https://github.com/eirslett/frontend-maven-plugin/issues/461 and does not 
properly install. We should let npm handle this for us anyway... 

> Broken bower install
> 
>
> Key: NIFI-2781
> URL: https://issues.apache.org/jira/browse/NIFI-2781
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0
>Reporter: Andrew Psaltis
>Assignee: Scott Aslan
>
> Often times when building the NiFi source, the installation of bower fails 
> and thus the whole build fails. 
> Looking at a mvn debug log, appears to show this:
> [INFO] Running 'npm install bower' in 
> /Users/apsaltis/development/forked-nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/target/frontend-working-directory
> [WARNING] npm WARN package.json mqlight@1.0.2016051011 No repository field.
> [ERROR] npm http GET https://registry.npmjs.org/bower
> [ERROR] npm http 200 https://registry.npmjs.org/bower
> [INFO] bower@1.7.9 ../../../../../../../../../node_modules/bower
> [INFO] 
> [INFO] --- frontend-maven-plugin:1.0:bower (bower-install) @ nifi-web-ui ---
> In essence nothing is there. This is reproducible in my environment, which 
> looks like this:
> $ printenv
> TERM_PROGRAM=iTerm.app
> TERM=xterm
> SHELL=/bin/bash
> TMPDIR=/var/folders/5l/xlzh00b10_lf16cd06dqwvs4gn/T/
> Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.jdxbKLHhHZ/Render
> TERM_PROGRAM_VERSION=3.0.7
> OLDPWD=/Users/apsaltis/development/forked-nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui
> TERM_SESSION_ID=w0t0p1:4401C1E6-AF27-43E2-91BF-7814B628BEC1
> USER=apsaltis
> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.VHh1dBoww3/Listeners
> __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
> PATH=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sb...
> PWD=/Users/apsaltis/development/forked-nifi
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
> LANG=en_US.UTF-8
> ITERM_PROFILE=Default
> XPC_FLAGS=0x0
> XPC_SERVICE_NAME=0
> SHLVL=1
> HOME=/Users/apsaltis
> COLORFGBG=7;0
> ITERM_SESSION_ID=w0t0p1:4401C1E6-AF27-43E2-91BF-7814B628BEC1
> LOGNAME=apsaltis
> _=/usr/bin/printenv



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

[jira] [Commented] (NIFI-1342) PostHTTP User Agent property should be pre-populated with client default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1342:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1021
  
+1, merging


> PostHTTP User Agent property should be pre-populated with client default
> 
>
> Key: NIFI-1342
> URL: https://issues.apache.org/jira/browse/NIFI-1342
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 0.4.1
>Reporter: Aldrin Piri
>Priority: Trivial
>
> Currently, PostHTTP shows an empty string for the User Agent property which 
> is used in web requests, but this actually results in the default of the 
> client being used.  For clarity, and if the backing library supports it, 
> getting the User Agent string used by the library as the default processor 
> User Agent property would be a nice improvement.



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

[GitHub] nifi issue #1021: NIFI-1342 Added default User-Agent in PostHttp

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1021
  
+1, merging


---
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-2537) Allow specification of Custom-MimeTypes.xml for IdentifyMimeTypes processor

[Michael Moser (JIRA)]

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

Michael Moser updated NIFI-2537:

Fix Version/s: (was: 0.8.0)

> Allow specification of Custom-MimeTypes.xml for IdentifyMimeTypes processor
> ---
>
> Key: NIFI-2537
> URL: https://issues.apache.org/jira/browse/NIFI-2537
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 0.7.0
>Reporter: Rich Rademacher
>Priority: Minor
>  Labels: easyfix
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Add property in the IdentifyMimeType processor so the user can add his/her 
> own Custom-MimeTypes.xml file into the Tika Engine.
> This will allow the user to expand the known mime types when this processor 
> is used e.g. to filter flowfiles from unknown sources



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

[jira] [Updated] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky updated NIFI-2774:
---
Affects Version/s: (was: 0.8.0)
   (was: 1.1.0)

> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[GitHub] nifi pull request #1022: NIFI-2774 changed the default ACK mode to CLIENT

[olegz]

GitHub user olegz opened a pull request:

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

NIFI-2774 changed the default ACK mode to CLIENT



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

$ git pull https://github.com/olegz/nifi NIFI-2774

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

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


commit a9a4d2efefe99ecefa14f2b502a13c34545f19b5
Author: Oleg Zhurakousky 
Date:   2016-09-15T13:33:27Z

NIFI-2774 changed the default ACK mode to CLIENT




---
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-1170) TailFile "File to Tail" property should support Wildcards

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1170:
--

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

https://github.com/apache/nifi/pull/980#discussion_r78954211
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

@olegz @joewitt 
Just updated the PR with a default of 10 minutes for refresh frequency, and 
24 hours for maximum age as a daily rollover pattern seems to be indeed the 
most common case. I updated the property descriptions and additional details 
page.
I also changed a little bit the approach on the regex matching while 
listing files to tail. Previously I was only matching the regular expression 
against file name, now I am trying to match the regular expression against the 
path. It gives more flexibility to the users. I added an example in the 
additional details.
And I squashed my commits.
Let me know your thoughts.

@trixpan, I understand your point but it sounds like an edge case, no? It 
would require to tail a very large number of files to get in such a situation. 
I'd be inclined to see this as an additional improvement in a separate PR if 
you agree.


> TailFile "File to Tail" property should support Wildcards
> -
>
> Key: NIFI-1170
> URL: https://issues.apache.org/jira/browse/NIFI-1170
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.4.0
>Reporter: Andre
>
> Because of challenges around log rotation of high volume syslog and app 
> producers, it is customary to logging platform developers to promote file 
> variables based file names such as DynaFiles (rsyslog), Macros(syslog-ng)as 
> alternatives to getting SIGHUPs being sent to the syslog daemon upon every 
> file rotation.
> (To certain extent, used even NiFi's has similar patterns, like for example, 
> when one uses Expression Language to set PutHDFS destination file).
> The current TailFile strategy suggests rotation 

[GitHub] nifi pull request #980: NIFI-1170 - Improved TailFile processor to support m...

[pvillard31]

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

https://github.com/apache/nifi/pull/980#discussion_r78954211
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

@olegz @joewitt 
Just updated the PR with a default of 10 minutes for refresh frequency, and 
24 hours for maximum age as a daily rollover pattern seems to be indeed the 
most common case. I updated the property descriptions and additional details 
page.
I also changed a little bit the approach on the regex matching while 
listing files to tail. Previously I was only matching the regular expression 
against file name, now I am trying to match the regular expression against the 
path. It gives more flexibility to the users. I added an example in the 
additional details.
And I squashed my commits.
Let me know your thoughts.

@trixpan, I understand your point but it sounds like an edge case, no? It 
would require to tail a very large number of files to get in such a situation. 
I'd be inclined to see this as an additional improvement in a separate PR if 
you agree.


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

[jira] [Comment Edited] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky edited comment on NIFI-2774 at 9/15/16 12:40 PM:
--

I was about to suggest to change the type of this issue to "Improvement" since 
it never claimed to allow multiple ack modes, hence not a bug, but. . .

I am actually wondering now if we should even expose AUTO_ACK or any ACK mode 
other then _Session.CLIENT_ACKNOWLEDGE_? My concern is that it will go counter 
to the contract established by NiFi. 
First, the NiFi is not a general purpose framework to simplify interaction with 
JMS, so the goal is not that.
Second, when integrating with external systems, NiFi essentially establishes a 
contract where it attempts to the best of its ability to provide atomic 
consumption of data (from external system to NiFi content repo, or nothing) 
between the external system and the processor that integrates with such system, 
hence it should never expose any attribute that may break such contract.

So unless overruled I am now treating it as a BUG and making an internal change 
to use _Session.CLIENT_ACKNOWLEDGE_ mode, yet not exposing anything new to the 
end user.


was (Author: ozhurakousky):
I was about to suggest to change the type of this issue to "Improvement" since 
it never claimed to allow multiple ack modes, hence not a bug, but. . .

I am actually wondering now if we should even expose AUTO_ACK or an ACK mode 
other then _Session.CLIENT_ACKNOWLEDGE_? My concern is that it will go counter 
to the contract established by NiFi. 
First, the NiFi is not a general purpose framework to simplify interaction with 
JMS, so the goal is not that.
Second, when integrating with external systems, NiFi essentially establishes a 
contract where it attempts to the best of its ability to provide atomic 
consumption of data (from external system to NiFi content repo, or nothing) 
between the external system and the processor that integrates with such system, 
hence it should never expose any attribute that may break such contract.

So unless overruled I am now treating it as a BUG and making an internal change 
to use _Session.CLIENT_ACKNOWLEDGE_ mode, yet not exposing anything new to the 
end user.

> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0, 1.1.0, 0.8.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[jira] [Commented] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky commented on NIFI-2774:


I was about to suggest to change the type of this issue to "Improvement" since 
it never claimed to allow multiple ack modes, hence not a bug, but. . .

I am actually wondering now if we should even expose AUTO_ACK or an ACK mode 
other then _Session.CLIENT_ACKNOWLEDGE_? My concern is that it will go counter 
to the contract established by NiFi. 
First, the NiFi is not a general purpose framework to simplify interaction with 
JMS, so the goal is not that.
Second, when integrating with external systems, NiFi essentially establishes a 
contract where it attempts to the best of its ability to provide atomic 
consumption of data (from external system to NiFi content repo, or nothing) 
between the external system and the processor that integrates with such system, 
hence it should never expose any attribute that may break such contract.

So unless overruled I am now treating it as a BUG and making an internal change 
to use _Session.CLIENT_ACKNOWLEDGE_ mode, yet not exposing anything new to the 
end user.

> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0, 1.1.0, 0.8.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[jira] [Assigned] (NIFI-2781) Broken bower install

[Scott Aslan (JIRA)]

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

Scott Aslan reassigned NIFI-2781:
-

Assignee: Scott Aslan

> Broken bower install
> 
>
> Key: NIFI-2781
> URL: https://issues.apache.org/jira/browse/NIFI-2781
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0
>Reporter: Andrew Psaltis
>Assignee: Scott Aslan
>
> Often times when building the NiFi source, the installation of bower fails 
> and thus the whole build fails. 
> Looking at a mvn debug log, appears to show this:
> [INFO] Running 'npm install bower' in 
> /Users/apsaltis/development/forked-nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/target/frontend-working-directory
> [WARNING] npm WARN package.json mqlight@1.0.2016051011 No repository field.
> [ERROR] npm http GET https://registry.npmjs.org/bower
> [ERROR] npm http 200 https://registry.npmjs.org/bower
> [INFO] bower@1.7.9 ../../../../../../../../../node_modules/bower
> [INFO] 
> [INFO] --- frontend-maven-plugin:1.0:bower (bower-install) @ nifi-web-ui ---
> In essence nothing is there. This is reproducible in my environment, which 
> looks like this:
> $ printenv
> TERM_PROGRAM=iTerm.app
> TERM=xterm
> SHELL=/bin/bash
> TMPDIR=/var/folders/5l/xlzh00b10_lf16cd06dqwvs4gn/T/
> Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.jdxbKLHhHZ/Render
> TERM_PROGRAM_VERSION=3.0.7
> OLDPWD=/Users/apsaltis/development/forked-nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui
> TERM_SESSION_ID=w0t0p1:4401C1E6-AF27-43E2-91BF-7814B628BEC1
> USER=apsaltis
> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.VHh1dBoww3/Listeners
> __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
> PATH=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sb...
> PWD=/Users/apsaltis/development/forked-nifi
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
> LANG=en_US.UTF-8
> ITERM_PROFILE=Default
> XPC_FLAGS=0x0
> XPC_SERVICE_NAME=0
> SHLVL=1
> HOME=/Users/apsaltis
> COLORFGBG=7;0
> ITERM_SESSION_ID=w0t0p1:4401C1E6-AF27-43E2-91BF-7814B628BEC1
> LOGNAME=apsaltis
> _=/usr/bin/printenv



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

[jira] [Created] (NIFI-2781) Broken bower install

[Andrew Psaltis (JIRA)]

Andrew Psaltis created NIFI-2781:


 Summary: Broken bower install
 Key: NIFI-2781
 URL: https://issues.apache.org/jira/browse/NIFI-2781
 Project: Apache NiFi
  Issue Type: Bug
  Components: Tools and Build
Affects Versions: 1.0.0
Reporter: Andrew Psaltis


Often times when building the NiFi source, the installation of bower fails and 
thus the whole build fails. 

Looking at a mvn debug log, appears to show this:

[INFO] Running 'npm install bower' in 
/Users/apsaltis/development/forked-nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/target/frontend-working-directory
[WARNING] npm WARN package.json mqlight@1.0.2016051011 No repository field.
[ERROR] npm http GET https://registry.npmjs.org/bower
[ERROR] npm http 200 https://registry.npmjs.org/bower
[INFO] bower@1.7.9 ../../../../../../../../../node_modules/bower
[INFO] 
[INFO] --- frontend-maven-plugin:1.0:bower (bower-install) @ nifi-web-ui ---

In essence nothing is there. This is reproducible in my environment, which 
looks like this:


$ printenv
TERM_PROGRAM=iTerm.app
TERM=xterm
SHELL=/bin/bash
TMPDIR=/var/folders/5l/xlzh00b10_lf16cd06dqwvs4gn/T/
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.jdxbKLHhHZ/Render
TERM_PROGRAM_VERSION=3.0.7
OLDPWD=/Users/apsaltis/development/forked-nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui
TERM_SESSION_ID=w0t0p1:4401C1E6-AF27-43E2-91BF-7814B628BEC1
USER=apsaltis
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.VHh1dBoww3/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
PATH=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sb...
PWD=/Users/apsaltis/development/forked-nifi
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
LANG=en_US.UTF-8
ITERM_PROFILE=Default
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
SHLVL=1
HOME=/Users/apsaltis
COLORFGBG=7;0
ITERM_SESSION_ID=w0t0p1:4401C1E6-AF27-43E2-91BF-7814B628BEC1
LOGNAME=apsaltis
_=/usr/bin/printenv





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