[jira] [Created] (NIFI-4630) Implement Satori RTM processors

[Laurence Da Luz (JIRA)]

Laurence Da Luz created NIFI-4630:
-

 Summary: Implement Satori RTM processors
 Key: NIFI-4630
 URL: https://issues.apache.org/jira/browse/NIFI-4630
 Project: Apache NiFi
  Issue Type: New Feature
  Components: Extensions
Reporter: Laurence Da Luz


Satori is a cloud-based data platform that provides a publish-subscribe 
messaging service called RTM:
https://www.satori.com/docs/using-satori/overview

This JIRA is to cover two new NiFi processors for communicating with the Satori 
RTM messaging service:

* *ConsumeSatoriRTM* - used to consume a live data feed from a Satori RTM 
channel
* *PublishSatoriRTM* - used to publish messages to a Satori RTM channel



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

[jira] [Commented] (NIFI-4583) Restructure package nifi-solr-processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4583:
--

Github user JohannesDaniel commented on the issue:

https://github.com/apache/nifi/pull/2285
  
(tested both processors in local build)


> Restructure package nifi-solr-processors
> 
>
> Key: NIFI-4583
> URL: https://issues.apache.org/jira/browse/NIFI-4583
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Johannes Peter
>Assignee: Johannes Peter
>Priority: Minor
>
> Several functionalities currently implemented e. g. in GetSolr or 
> SolrProcessor should be made available for other processors or controller 
> services. A class SolrUtils should be created containing several static 
> methods. This includes the methods 
> - getRequestParams (PutSolrContentStream)
> - solrDocumentsToRecordSet (GetSolr) 
> - createSolrClient (SolrProcessor)
> and the inner class QueryResponseOutputStreamCallback (GetSolr)
> Some unit tests might be affected.
> The method declaration  
> protected SolrClient createSolrClient(final ProcessContext context, final 
> String solrLocation)
> should be changed to 
> public static SolrClient createSolrClient(final PropertyContext context, 
> final String solrLocation)
> to be suitable also for controller services.



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

[GitHub] nifi issue #2285: NIFI-4583 Restructure nifi-solr-processors

[JohannesDaniel]

Github user JohannesDaniel commented on the issue:

https://github.com/apache/nifi/pull/2285
  
(tested both processors in local build)


---

[jira] [Commented] (NIFI-4583) Restructure package nifi-solr-processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4583:
--

Github user JohannesDaniel commented on the issue:

https://github.com/apache/nifi/pull/2285
  
Restructured the methods as discussed in JIRA. Additionally, I improved the 
unit tests for GetSolr


> Restructure package nifi-solr-processors
> 
>
> Key: NIFI-4583
> URL: https://issues.apache.org/jira/browse/NIFI-4583
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Johannes Peter
>Assignee: Johannes Peter
>Priority: Minor
>
> Several functionalities currently implemented e. g. in GetSolr or 
> SolrProcessor should be made available for other processors or controller 
> services. A class SolrUtils should be created containing several static 
> methods. This includes the methods 
> - getRequestParams (PutSolrContentStream)
> - solrDocumentsToRecordSet (GetSolr) 
> - createSolrClient (SolrProcessor)
> and the inner class QueryResponseOutputStreamCallback (GetSolr)
> Some unit tests might be affected.
> The method declaration  
> protected SolrClient createSolrClient(final ProcessContext context, final 
> String solrLocation)
> should be changed to 
> public static SolrClient createSolrClient(final PropertyContext context, 
> final String solrLocation)
> to be suitable also for controller services.



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

[GitHub] nifi issue #2285: NIFI-4583 Restructure nifi-solr-processors

[JohannesDaniel]

Github user JohannesDaniel commented on the issue:

https://github.com/apache/nifi/pull/2285
  
Restructured the methods as discussed in JIRA. Additionally, I improved the 
unit tests for GetSolr


---

[jira] [Commented] (NIFI-4583) Restructure package nifi-solr-processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4583:
--

GitHub user JohannesDaniel opened a pull request:

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

NIFI-4583 Restructure nifi-solr-processors

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/JohannesDaniel/nifi NIFI-4583

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

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


commit 9478079d1bbbec5109a01f1d50431d7f06111928
Author: U-WOODMARK\johannes.peter 
Date:   2017-11-21T15:38:18Z

NIFI-4583 Restructure nifi-solr-processors




> Restructure package nifi-solr-processors
> 
>
> Key: NIFI-4583
> URL: https://issues.apache.org/jira/browse/NIFI-4583
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Johannes Peter
>Assignee: Johannes Peter
>Priority: Minor
>
> Several functionalities currently implemented e. g. in GetSolr or 
> SolrProcessor should be made available for other processors or controller 
> services. A class SolrUtils should be created containing several static 
> methods. This includes the methods 
> - getRequestParams (PutSolrContentStream)
> - solrDocumentsToRecordSet (GetSolr) 
> - createSolrClient (SolrProcessor)
> and the inner class QueryResponseOutputStreamCallback (GetSolr)
> Some unit tests might be affected.
> The method declaration  
> protected SolrClient createSolrClient(final ProcessContext context, final 
> String solrLocation)
> should be changed to 
> public static SolrClient createSolrClient(final PropertyContext context, 
> final String solrLocation)
> to be suitable also for controller services.



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

[GitHub] nifi pull request #2285: NIFI-4583 Restructure nifi-solr-processors

[JohannesDaniel]

GitHub user JohannesDaniel opened a pull request:

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

NIFI-4583 Restructure nifi-solr-processors

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/JohannesDaniel/nifi NIFI-4583

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

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


commit 9478079d1bbbec5109a01f1d50431d7f06111928
Author: U-WOODMARK\johannes.peter 
Date:   2017-11-21T15:38:18Z

NIFI-4583 Restructure nifi-solr-processors




---

[jira] [Updated] (NIFI-4505) MapCache/SimpleMapCache/PersistentMapCache: Add keyset method

[Michael Moser (JIRA)]

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

Michael Moser updated NIFI-4505:

Status: Patch Available  (was: Open)

See PR below, combining changes for both NIFI-4504 and NIFI-4505

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


> MapCache/SimpleMapCache/PersistentMapCache: Add keyset method
> -
>
> Key: NIFI-4505
> URL: https://issues.apache.org/jira/browse/NIFI-4505
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Jon Kessler
>Assignee: Michael Moser
>Priority: Minor
>
> Suggest adding a keyset method to the MapCache and implementations as well as 
> to any client/interface that make use of a MapCache.



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

[jira] [Updated] (NIFI-4504) SimpleMapCache/PersistentMapCache: Add removeAndGet and removeByPatternAndGet

[Michael Moser (JIRA)]

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

Michael Moser updated NIFI-4504:

Status: Patch Available  (was: Open)

> SimpleMapCache/PersistentMapCache: Add removeAndGet and removeByPatternAndGet
> -
>
> Key: NIFI-4504
> URL: https://issues.apache.org/jira/browse/NIFI-4504
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Jon Kessler
>Assignee: Michael Moser
>Priority: Minor
>
> Typical map implementations return the value that was removed when performing 
> a remove. Because you couldn't update the existing remove methods without it 
> being a breaking change I suggest adding new versions of the remove and 
> removeByPattern methods that return the removed value(s).
> These changes should also be applied up the chain to any class that makes use 
> of these classes such as the MapCacheServer and 
> AtomicDistributedMapCacheClient.



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

[jira] [Commented] (NIFI-4504) SimpleMapCache/PersistentMapCache: Add removeAndGet and removeByPatternAndGet

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4504:
--

GitHub user mosermw opened a pull request:

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

NIFI-4504, NIFI-4505 added methods to MapCache API …

… including keySet, removeAndGet, removeByPatternAndGet
  cleaned up some warnings on deprecated nifi.stream.io classes

I attempted to update the various implementations of 
DistributedMapCacheClient,
but if the reviewer feels I should leave them unsupported then let me know.

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/mosermw/nifi NIFI-4505

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

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


commit 269fb770d793962a4dbb85b00f66b2d247ebd0fe
Author: Mike Moser 
Date:   2017-11-15T21:54:46Z

NIFI-4504, NIFI-4505 added removeAndGet, removeByPatternAndGet, and keySet 
methods to MapCache API
  cleaned up some warnings on deprecated nifi.stream.io classes




> SimpleMapCache/PersistentMapCache: Add removeAndGet and removeByPatternAndGet
> -
>
> Key: NIFI-4504
> URL: https://issues.apache.org/jira/browse/NIFI-4504
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Jon Kessler
>Assignee: Michael Moser
>Priority: Minor
>
> Typical map implementations return the value that was removed when performing 
> a remove. Because you couldn't update the existing remove methods without it 
> being a breaking change I suggest adding new versions of the remove and 
> removeByPattern methods that return the removed value(s).
> These changes should also be applied up the chain to any class that makes use 
> of these classes such as the MapCacheServer and 
> AtomicDistributedMapCacheClient.



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

[GitHub] nifi pull request #2284: NIFI-4504, NIFI-4505 added methods to MapCache API ...

[mosermw]

GitHub user mosermw opened a pull request:

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

NIFI-4504, NIFI-4505 added methods to MapCache API …

… including keySet, removeAndGet, removeByPatternAndGet
  cleaned up some warnings on deprecated nifi.stream.io classes

I attempted to update the various implementations of 
DistributedMapCacheClient,
but if the reviewer feels I should leave them unsupported then let me know.

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/mosermw/nifi NIFI-4505

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

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


commit 269fb770d793962a4dbb85b00f66b2d247ebd0fe
Author: Mike Moser 
Date:   2017-11-15T21:54:46Z

NIFI-4504, NIFI-4505 added removeAndGet, removeByPatternAndGet, and keySet 
methods to MapCache API
  cleaned up some warnings on deprecated nifi.stream.io classes




---

[jira] [Assigned] (NIFI-4504) SimpleMapCache/PersistentMapCache: Add removeAndGet and removeByPatternAndGet

[Michael Moser (JIRA)]

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

Michael Moser reassigned NIFI-4504:
---

Assignee: Michael Moser

> SimpleMapCache/PersistentMapCache: Add removeAndGet and removeByPatternAndGet
> -
>
> Key: NIFI-4504
> URL: https://issues.apache.org/jira/browse/NIFI-4504
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Jon Kessler
>Assignee: Michael Moser
>Priority: Minor
>
> Typical map implementations return the value that was removed when performing 
> a remove. Because you couldn't update the existing remove methods without it 
> being a breaking change I suggest adding new versions of the remove and 
> removeByPattern methods that return the removed value(s).
> These changes should also be applied up the chain to any class that makes use 
> of these classes such as the MapCacheServer and 
> AtomicDistributedMapCacheClient.



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

[jira] [Updated] (NIFI-4589) Allow multiple keys in FetchDistributedMapCache

[Michael Moser (JIRA)]

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

Michael Moser updated NIFI-4589:

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

> Allow multiple keys in FetchDistributedMapCache
> ---
>
> Key: NIFI-4589
> URL: https://issues.apache.org/jira/browse/NIFI-4589
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.5.0
>
>
> Currently (1.4.0) FetchDistributedMapCache will look up a single key and 
> place the value (if present) in either the flow file content or a user-named 
> attribute, depending on the value of the "Put Cache Value In Attribute" 
> property. If the user wishes to look up more than one value, they need 
> multiple FetchDistributedMapCache processors, and each would make one call to 
> the server to get a single key.
> A useful improvement would be to allow multiple keys to be retrieved at once 
> by FetchDistributedMapCache. This would likely involve the following:
> 1) Update documentation and code to accept a comma-separated list of Cache 
> Key Identifiers
> 2) If a single Cache Key Identifier is specified, current behavior is 
> retained (i.e. output to flow file content or a specified attribute)
> 3) If multiple Cache Key Identifiers are specified, then Put Cache Value In 
> Attribute must be set, and the attributes will be prefixed by the value of 
> said property, followed by a period, followed by the evaluated cache key. So 
> if Cache Key Identifier is set to "field1, field2" and Put Cache Value In 
> Attribute is set to "myattrs", then the value for field1 will be placed in 
> the "myattrs.field1" attribute, and field2's value in "myattrs.field2" 
> respectively.
> 4) Due to the possible presence of Expression Language in the Cache Key 
> Identifier property, it may not be possible to determine whether multiple 
> cache keys are present (i.e. a single EL function that generates a 
> comma-separated list), so the requirement on Put Cache Value In Attribute 
> being set must be checked at validation time (if possible) and also run-time
> 5) To make this fetch efficient, a method "subMap" can be created on the 
> DistributedMapCache API, so multiple keys can be passed and multiple 
> key/value pairs can be returned in a single call to the cache server.
> 6) #5 implies a new protocol version (would be 3 at the time of this writing) 
> be added to the DistributedMapCache API
> 7) If protocol negotiation results in a lower version being used, then the 
> client should gracefully degrade into using the "subMap" operation to make 
> multiple calls to the "get" operation, and fill in the result map manually.



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

[jira] [Commented] (NIFI-4589) Allow multiple keys in FetchDistributedMapCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4589:
--

Github user mosermw commented on the issue:

https://github.com/apache/nifi/pull/2260
  
Code looks good, full build with contrib-check passes, and I tested a small 
flow with success & failure results as expected.  +1 merged.

There is a comment in the ProtocolHandshake class that I would modify to 
reflect version 3 of DistributedMapCache, but it's just a comment and I can 
take care of that in my upcoming PR.


> Allow multiple keys in FetchDistributedMapCache
> ---
>
> Key: NIFI-4589
> URL: https://issues.apache.org/jira/browse/NIFI-4589
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> Currently (1.4.0) FetchDistributedMapCache will look up a single key and 
> place the value (if present) in either the flow file content or a user-named 
> attribute, depending on the value of the "Put Cache Value In Attribute" 
> property. If the user wishes to look up more than one value, they need 
> multiple FetchDistributedMapCache processors, and each would make one call to 
> the server to get a single key.
> A useful improvement would be to allow multiple keys to be retrieved at once 
> by FetchDistributedMapCache. This would likely involve the following:
> 1) Update documentation and code to accept a comma-separated list of Cache 
> Key Identifiers
> 2) If a single Cache Key Identifier is specified, current behavior is 
> retained (i.e. output to flow file content or a specified attribute)
> 3) If multiple Cache Key Identifiers are specified, then Put Cache Value In 
> Attribute must be set, and the attributes will be prefixed by the value of 
> said property, followed by a period, followed by the evaluated cache key. So 
> if Cache Key Identifier is set to "field1, field2" and Put Cache Value In 
> Attribute is set to "myattrs", then the value for field1 will be placed in 
> the "myattrs.field1" attribute, and field2's value in "myattrs.field2" 
> respectively.
> 4) Due to the possible presence of Expression Language in the Cache Key 
> Identifier property, it may not be possible to determine whether multiple 
> cache keys are present (i.e. a single EL function that generates a 
> comma-separated list), so the requirement on Put Cache Value In Attribute 
> being set must be checked at validation time (if possible) and also run-time
> 5) To make this fetch efficient, a method "subMap" can be created on the 
> DistributedMapCache API, so multiple keys can be passed and multiple 
> key/value pairs can be returned in a single call to the cache server.
> 6) #5 implies a new protocol version (would be 3 at the time of this writing) 
> be added to the DistributedMapCache API
> 7) If protocol negotiation results in a lower version being used, then the 
> client should gracefully degrade into using the "subMap" operation to make 
> multiple calls to the "get" operation, and fill in the result map manually.



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

[jira] [Commented] (NIFI-4589) Allow multiple keys in FetchDistributedMapCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4589:
--

Github user asfgit closed the pull request at:

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


> Allow multiple keys in FetchDistributedMapCache
> ---
>
> Key: NIFI-4589
> URL: https://issues.apache.org/jira/browse/NIFI-4589
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> Currently (1.4.0) FetchDistributedMapCache will look up a single key and 
> place the value (if present) in either the flow file content or a user-named 
> attribute, depending on the value of the "Put Cache Value In Attribute" 
> property. If the user wishes to look up more than one value, they need 
> multiple FetchDistributedMapCache processors, and each would make one call to 
> the server to get a single key.
> A useful improvement would be to allow multiple keys to be retrieved at once 
> by FetchDistributedMapCache. This would likely involve the following:
> 1) Update documentation and code to accept a comma-separated list of Cache 
> Key Identifiers
> 2) If a single Cache Key Identifier is specified, current behavior is 
> retained (i.e. output to flow file content or a specified attribute)
> 3) If multiple Cache Key Identifiers are specified, then Put Cache Value In 
> Attribute must be set, and the attributes will be prefixed by the value of 
> said property, followed by a period, followed by the evaluated cache key. So 
> if Cache Key Identifier is set to "field1, field2" and Put Cache Value In 
> Attribute is set to "myattrs", then the value for field1 will be placed in 
> the "myattrs.field1" attribute, and field2's value in "myattrs.field2" 
> respectively.
> 4) Due to the possible presence of Expression Language in the Cache Key 
> Identifier property, it may not be possible to determine whether multiple 
> cache keys are present (i.e. a single EL function that generates a 
> comma-separated list), so the requirement on Put Cache Value In Attribute 
> being set must be checked at validation time (if possible) and also run-time
> 5) To make this fetch efficient, a method "subMap" can be created on the 
> DistributedMapCache API, so multiple keys can be passed and multiple 
> key/value pairs can be returned in a single call to the cache server.
> 6) #5 implies a new protocol version (would be 3 at the time of this writing) 
> be added to the DistributedMapCache API
> 7) If protocol negotiation results in a lower version being used, then the 
> client should gracefully degrade into using the "subMap" operation to make 
> multiple calls to the "get" operation, and fill in the result map manually.



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

[jira] [Commented] (MINIFICPP-251) Move Civet implementations to an extension.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261461#comment-16261461
 ] 

ASF GitHub Bot commented on MINIFICPP-251:
--

Github user calebj commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/203
  
Should be fine now, I think. 


> Move Civet implementations to an extension.
> ---
>
> Key: MINIFICPP-251
> URL: https://issues.apache.org/jira/browse/MINIFICPP-251
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
> Fix For: 0.4.0
>
>
> We should be able to move anything that uses Civet, such as ListenHTTP and 
> any dependencies ( such as boost ) to an extension and allow boost, civet, 
> and any related libraries to be excluded from the build with an argument



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

[GitHub] nifi issue #2260: NIFI-4589: Allow multiple keys in FetchDistributedMapCache...

[mosermw]

Github user mosermw commented on the issue:

https://github.com/apache/nifi/pull/2260
  
Code looks good, full build with contrib-check passes, and I tested a small 
flow with success & failure results as expected.  +1 merged.

There is a comment in the ProtocolHandshake class that I would modify to 
reflect version 3 of DistributedMapCache, but it's just a comment and I can 
take care of that in my upcoming PR.


---

[jira] [Commented] (NIFI-4589) Allow multiple keys in FetchDistributedMapCache

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-4589: Allow multiple keys in FetchDistributedMapCache, add subMap 
operation to API

Signed-off-by: Mike Moser 

This closes #2260.


> Allow multiple keys in FetchDistributedMapCache
> ---
>
> Key: NIFI-4589
> URL: https://issues.apache.org/jira/browse/NIFI-4589
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> Currently (1.4.0) FetchDistributedMapCache will look up a single key and 
> place the value (if present) in either the flow file content or a user-named 
> attribute, depending on the value of the "Put Cache Value In Attribute" 
> property. If the user wishes to look up more than one value, they need 
> multiple FetchDistributedMapCache processors, and each would make one call to 
> the server to get a single key.
> A useful improvement would be to allow multiple keys to be retrieved at once 
> by FetchDistributedMapCache. This would likely involve the following:
> 1) Update documentation and code to accept a comma-separated list of Cache 
> Key Identifiers
> 2) If a single Cache Key Identifier is specified, current behavior is 
> retained (i.e. output to flow file content or a specified attribute)
> 3) If multiple Cache Key Identifiers are specified, then Put Cache Value In 
> Attribute must be set, and the attributes will be prefixed by the value of 
> said property, followed by a period, followed by the evaluated cache key. So 
> if Cache Key Identifier is set to "field1, field2" and Put Cache Value In 
> Attribute is set to "myattrs", then the value for field1 will be placed in 
> the "myattrs.field1" attribute, and field2's value in "myattrs.field2" 
> respectively.
> 4) Due to the possible presence of Expression Language in the Cache Key 
> Identifier property, it may not be possible to determine whether multiple 
> cache keys are present (i.e. a single EL function that generates a 
> comma-separated list), so the requirement on Put Cache Value In Attribute 
> being set must be checked at validation time (if possible) and also run-time
> 5) To make this fetch efficient, a method "subMap" can be created on the 
> DistributedMapCache API, so multiple keys can be passed and multiple 
> key/value pairs can be returned in a single call to the cache server.
> 6) #5 implies a new protocol version (would be 3 at the time of this writing) 
> be added to the DistributedMapCache API
> 7) If protocol negotiation results in a lower version being used, then the 
> client should gracefully degrade into using the "subMap" operation to make 
> multiple calls to the "get" operation, and fill in the result map manually.



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

[GitHub] nifi pull request #2260: NIFI-4589: Allow multiple keys in FetchDistributedM...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] nifi-minifi-cpp issue #203: MINIFICPP-251 Move Civet implementations to an e...

[calebj]

Github user calebj commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/203
  
Should be fine now, I think. 


---

[jira] [Commented] (MINIFICPP-251) Move Civet implementations to an extension.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261453#comment-16261453
 ] 

ASF GitHub Bot commented on MINIFICPP-251:
--

Github user calebj commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/203
  
Still some issues to work out.


> Move Civet implementations to an extension.
> ---
>
> Key: MINIFICPP-251
> URL: https://issues.apache.org/jira/browse/MINIFICPP-251
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
> Fix For: 0.4.0
>
>
> We should be able to move anything that uses Civet, such as ListenHTTP and 
> any dependencies ( such as boost ) to an extension and allow boost, civet, 
> and any related libraries to be excluded from the build with an argument



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

[GitHub] nifi-minifi-cpp issue #203: MINIFICPP-251 Move Civet implementations to an e...

[calebj]

Github user calebj commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/203
  
Still some issues to work out.


---

[jira] [Assigned] (NIFI-4531) LDAP/AD Support

[Aldrin Piri (JIRA)]

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

Aldrin Piri reassigned NIFI-4531:
-

Assignee: Aldrin Piri

> LDAP/AD Support
> ---
>
> Key: NIFI-4531
> URL: https://issues.apache.org/jira/browse/NIFI-4531
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Docker
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
>
> Provide configuration and documentation for setting up instances using LDAP/AD



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

[jira] [Assigned] (NIFI-4530) Two Way SSL Support for Docker image

[Aldrin Piri (JIRA)]

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

Aldrin Piri reassigned NIFI-4530:
-

Assignee: Aldrin Piri

> Two Way SSL Support for Docker image
> 
>
> Key: NIFI-4530
> URL: https://issues.apache.org/jira/browse/NIFI-4530
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Docker
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
>




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

[jira] [Assigned] (NIFI-4529) Provide support for user auth in Docker instances

[Aldrin Piri (JIRA)]

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

Aldrin Piri reassigned NIFI-4529:
-

Assignee: Aldrin Piri

> Provide support for user auth in Docker instances
> -
>
> Key: NIFI-4529
> URL: https://issues.apache.org/jira/browse/NIFI-4529
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Docker
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
>
> We should make the Docker image configurable to support all of the common 
> security options available in NiFi.  This would include LDAP/AD, SSL, and 
> Kerberos.  These will likely be heavily driven by environment variables but 
> this approach should make it easy to integrate the image into target 
> environments and resource managers. 



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

[jira] [Assigned] (NIFI-4529) Provide support for user auth in Docker instances

[Aldrin Piri (JIRA)]

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

Aldrin Piri reassigned NIFI-4529:
-

Assignee: (was: Aldrin Piri)

> Provide support for user auth in Docker instances
> -
>
> Key: NIFI-4529
> URL: https://issues.apache.org/jira/browse/NIFI-4529
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Docker
>Reporter: Aldrin Piri
>
> We should make the Docker image configurable to support all of the common 
> security options available in NiFi.  This would include LDAP/AD, SSL, and 
> Kerberos.  These will likely be heavily driven by environment variables but 
> this approach should make it easy to integrate the image into target 
> environments and resource managers. 



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

[jira] [Commented] (MINIFICPP-251) Move Civet implementations to an extension.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261436#comment-16261436
 ] 

ASF GitHub Bot commented on MINIFICPP-251:
--

GitHub user calebj opened a pull request:

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

MINIFICPP-251 Move Civet implementations to an extension.

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

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

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

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

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

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

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/NiFiLocal/nifi-minifi-cpp MINIFICPP-251

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

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


commit ae09003d288bf9a7fc9b9832574a17154f29ee9a
Author: Caleb Johnson 
Date:   2017-11-16T23:06:22Z

MINIFICPP-251 Move Civet implementations to an extension.




> Move Civet implementations to an extension.
> ---
>
> Key: MINIFICPP-251
> URL: https://issues.apache.org/jira/browse/MINIFICPP-251
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
> Fix For: 0.4.0
>
>
> We should be able to move anything that uses Civet, such as ListenHTTP and 
> any dependencies ( such as boost ) to an extension and allow boost, civet, 
> and any related libraries to be excluded from the build with an argument



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

[GitHub] nifi-minifi-cpp pull request #203: MINIFICPP-251 Move Civet implementations ...

[calebj]

GitHub user calebj opened a pull request:

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

MINIFICPP-251 Move Civet implementations to an extension.

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

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

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

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

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

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

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/NiFiLocal/nifi-minifi-cpp MINIFICPP-251

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

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


commit ae09003d288bf9a7fc9b9832574a17154f29ee9a
Author: Caleb Johnson 
Date:   2017-11-16T23:06:22Z

MINIFICPP-251 Move Civet implementations to an extension.




---

[jira] [Updated] (MINIFICPP-251) Move Civet implementations to an extension.

[marco polo (JIRA)]

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

marco polo updated MINIFICPP-251:
-
Fix Version/s: 0.4.0

> Move Civet implementations to an extension.
> ---
>
> Key: MINIFICPP-251
> URL: https://issues.apache.org/jira/browse/MINIFICPP-251
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
> Fix For: 0.4.0
>
>
> We should be able to move anything that uses Civet, such as ListenHTTP and 
> any dependencies ( such as boost ) to an extension and allow boost, civet, 
> and any related libraries to be excluded from the build with an argument



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

[jira] [Resolved] (MINIFICPP-274) add kafka producer

[marco polo (JIRA)]

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

marco polo resolved MINIFICPP-274.
--
Resolution: Fixed

> add kafka producer
> --
>
> Key: MINIFICPP-274
> URL: https://issues.apache.org/jira/browse/MINIFICPP-274
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Affects Versions: 0.3.0
>Reporter: bqiu
>Assignee: bqiu
>Priority: Minor
> Fix For: 0.3.0
>
>
> Add kafka producer for minifi C++



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

[jira] [Updated] (MINIFICPP-315) Allow Properties to support plain 'b' suffix

[marco polo (JIRA)]

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

marco polo updated MINIFICPP-315:
-
Fix Version/s: 0.4.0

> Allow Properties to support plain 'b' suffix
> 
>
> Key: MINIFICPP-315
> URL: https://issues.apache.org/jira/browse/MINIFICPP-315
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Dustin Rodrigues
>Priority: Minor
> Fix For: 0.4.0
>
>
> Currently, if a property is 'x kb', the value is multiplied by 1024 but if 
> it's 'x k', it's multiplied by 1000. However, values are of the form 'x b' or 
> 'x B', the value doesn't get parsed at all. Instead, 'x' should be returned.



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

[jira] [Updated] (MINIFICPP-274) add kafka producer

[marco polo (JIRA)]

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

marco polo updated MINIFICPP-274:
-
Fix Version/s: 0.3.0

> add kafka producer
> --
>
> Key: MINIFICPP-274
> URL: https://issues.apache.org/jira/browse/MINIFICPP-274
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Affects Versions: 0.3.0
>Reporter: bqiu
>Assignee: bqiu
>Priority: Minor
> Fix For: 0.3.0
>
>
> Add kafka producer for minifi C++



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

[jira] [Updated] (MINIFICPP-307) GenerateFlowFile ignores type property

[marco polo (JIRA)]

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

marco polo updated MINIFICPP-307:
-
Fix Version/s: 0.4.0

> GenerateFlowFile ignores type property
> --
>
> Key: MINIFICPP-307
> URL: https://issues.apache.org/jira/browse/MINIFICPP-307
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Andrew Christianson
>Priority: Minor
> Fix For: 0.4.0
>
>
> It is currently stuck on generating binary data only.



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

[jira] [Updated] (MINIFICPP-277) Produce system packages in build process

[marco polo (JIRA)]

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

marco polo updated MINIFICPP-277:
-
Fix Version/s: 0.4.0

> Produce system packages in build process
> 
>
> Key: MINIFICPP-277
> URL: https://issues.apache.org/jira/browse/MINIFICPP-277
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Andrew Christianson
> Fix For: 0.4.0
>
>
> Users have reported issues with portability of built MiNiFi - C++ binaries. 
> While this issue is caused by multiple factors, one factor is the lack of 
> system packages built to be compatible with standard runtime 
> environments/OSes (e.g. CentOS 6). We should add build targets which produce 
> system packages, and ideally have repeatable builds & release artifacts for 
> major target OSes such that the deployment/installation practice is a simple 
> apt-get or yum install.
> Initial yum OS packages:
> * CentOS 6
> * CentOS 7
> Initial deb OS packages:
> * Ubuntu 14.04
> * Ubuntu 16.04



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

[jira] [Comment Edited] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fredrik Sko (JIRA)]

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

Fredrik Sko edited comment on NIFI-4629 at 11/21/17 7:59 PM:
-

Some additional notes:
* After generating the errors, the log claims to roll back the session
* The flowfiles in the originating queue (between GenerateFlowFile and 
ControlRate as per my attached template) stays in the queue.
* The UI shows the queue still containing the flowfiles, however "empty queue" 
and "list queue" both claims the queue is empty.
* Stopping the processors and trying to delete the connection yields a "Queue 
is not empty" error message, which is expected given the number of items 
queued, but inconsistent with the statement above.

I also tried moving the connection containing the stall/dead/inaccessible 
flowfiles to another destination, but they are not processed any further and 
remains in a state where I'm unable to recover them.


was (Author: frsk):
Some additional notes:
* After generating the errors, the log claims to roll back the session
* The flowfiles in the originating queue (between GenerateFlowFile and 
ControlRate as per my attached template) stays in the queue.
* The UI shows the queue still containing the flowfiles, however "empty queue" 
and "list queue" both claims the queue is empty.
* Stopping the processors and trying to delete the connection yields a "Queue 
is not empty" error message, which is expected given the number of items 
queued, but inconsistent with the statement above.

I also tried moving the connection containing the stall/dead/inaccessible 
flowfiles to another destination, but the are not processed any further and 
remains in a state where I'm unable to recover them.

> Non-existing attribute in ControlRate configuration causes 
> NullPointerException
> ---
>
> Key: NIFI-4629
> URL: https://issues.apache.org/jira/browse/NIFI-4629
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration, Core UI
>Affects Versions: 1.4.0
> Environment: Ubuntu LTS 16.04
> openjdk-8-jre
>Reporter: Fredrik Sko
>Priority: Critical
>  Labels: ControlRate, NullPointerException, Processor
> Attachments: ControlRate-NP.xml
>
>
> When using the ControlRate processor, defining the "Grouping Attribute" with 
> a missing/non-existing attribute name produces NullPointerException errors.
> Processor configuration:
> {quote}
> Rate Control Criteria: flowfile count
> Maximum rate: 10
> Rate Controlled Attributes: (No value set)
> Time Duration: 1 min
> Grouping Attribute: foobar
> {quote}
> ControlRate with the following configuration when sent a flowfile without the 
> attribute {{foobar}} generates the following error:
> bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
> ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due 
> to java.lang.NullPointerException; rolling back session: null
> Additionally, the incoming flowfiles now ends up in some "dead" state where 
> I'm unable to even empty the queue.
> A simple template for reproduction is attached.



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

[jira] [Comment Edited] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fredrik Sko (JIRA)]

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

Fredrik Sko edited comment on NIFI-4629 at 11/21/17 7:49 PM:
-

Some additional notes:
* After generating the errors, the log claims to roll back the session
* The flowfiles in the originating queue (between GenerateFlowFile and 
ControlRate as per my attached template) stays in the queue.
* The UI shows the queue still containing the flowfiles, however "empty queue" 
and "list queue" both claims the queue is empty.
* Stopping the processors and trying to delete the connection yields a "Queue 
is not empty" error message, which is expected given the number of items 
queued, but inconsistent with the statement above.

I also tried moving the connection containing the stall/dead/inaccessible 
flowfiles to another destination, but the are not processed any further and 
remains in a state where I'm unable to recover them.


was (Author: frsk):
Some additional notes:
* After generating the errors, the log claims to roll back the session
* The flowfiles in the originating queue (between GenerateFlowFile and 
ControlRate as per my attached template) stays in the queue.
* The UI shows the queue still containing the flowfiles, however "empty queue" 
and "list queue" both claims the queue is empty.
* Stopping the processors and trying to delete the connection yields a "Queue 
is not empty" error message, which is expected given the number of items 
queued, but inconsistent with the statement above.

> Non-existing attribute in ControlRate configuration causes 
> NullPointerException
> ---
>
> Key: NIFI-4629
> URL: https://issues.apache.org/jira/browse/NIFI-4629
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration, Core UI
>Affects Versions: 1.4.0
> Environment: Ubuntu LTS 16.04
> openjdk-8-jre
>Reporter: Fredrik Sko
>Priority: Critical
>  Labels: ControlRate, NullPointerException, Processor
> Attachments: ControlRate-NP.xml
>
>
> When using the ControlRate processor, defining the "Grouping Attribute" with 
> a missing/non-existing attribute name produces NullPointerException errors.
> Processor configuration:
> {quote}
> Rate Control Criteria: flowfile count
> Maximum rate: 10
> Rate Controlled Attributes: (No value set)
> Time Duration: 1 min
> Grouping Attribute: foobar
> {quote}
> ControlRate with the following configuration when sent a flowfile without the 
> attribute {{foobar}} generates the following error:
> bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
> ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due 
> to java.lang.NullPointerException; rolling back session: null
> Additionally, the incoming flowfiles now ends up in some "dead" state where 
> I'm unable to even empty the queue.
> A simple template for reproduction is attached.



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

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

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

https://github.com/apache/nifi/pull/2283#discussion_r152381607
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListenHTTP.java
 ---
@@ -126,6 +126,12 @@
 .addValidator(StandardValidators.REGULAR_EXPRESSION_VALIDATOR)
 .required(false)
 .build();
+public static final PropertyDescriptor RETURN_CODE = new 
PropertyDescriptor.Builder()
+   .name("Return Code")
+   .description("The HTTP return code returned after every HTTP 
call")
+   .required(true)
--- End diff --

since it is defaulting to 200 which is what it always was and is optional 
I'd recommend we remove this line


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi pull request #2283: NIFI-4597 Add a property to override HTTP return co...

[joewitt]

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

https://github.com/apache/nifi/pull/2283#discussion_r152381607
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListenHTTP.java
 ---
@@ -126,6 +126,12 @@
 .addValidator(StandardValidators.REGULAR_EXPRESSION_VALIDATOR)
 .required(false)
 .build();
+public static final PropertyDescriptor RETURN_CODE = new 
PropertyDescriptor.Builder()
+   .name("Return Code")
+   .description("The HTTP return code returned after every HTTP 
call")
+   .required(true)
--- End diff --

since it is defaulting to 200 which is what it always was and is optional 
I'd recommend we remove this line


---

[jira] [Commented] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fredrik Sko (JIRA)]

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

Fredrik Sko commented on NIFI-4629:
---

Some additional notes:
* After generating the errors, the log claims to roll back the session
* The flowfiles in the originating queue (between GenerateFlowFile and 
ControlRate as per my attached template) stays in the queue.
* The UI shows the queue still containing the flowfiles, however "empty queue" 
and "list queue" both claims the queue is empty.
* Stopping the processors and trying to delete the connection yields a "Queue 
is not empty" error message, which is expected given the number of items 
queued, but inconsistent with the statement above.

> Non-existing attribute in ControlRate configuration causes 
> NullPointerException
> ---
>
> Key: NIFI-4629
> URL: https://issues.apache.org/jira/browse/NIFI-4629
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration, Core UI
>Affects Versions: 1.4.0
> Environment: Ubuntu LTS 16.04
> openjdk-8-jre
>Reporter: Fredrik Sko
>Priority: Critical
>  Labels: ControlRate, NullPointerException, Processor
> Attachments: ControlRate-NP.xml
>
>
> When using the ControlRate processor, defining the "Grouping Attribute" with 
> a missing/non-existing attribute name produces NullPointerException errors.
> Processor configuration:
> {quote}
> Rate Control Criteria: flowfile count
> Maximum rate: 10
> Rate Controlled Attributes: (No value set)
> Time Duration: 1 min
> Grouping Attribute: foobar
> {quote}
> ControlRate with the following configuration when sent a flowfile without the 
> attribute {{foobar}} generates the following error:
> bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
> ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due 
> to java.lang.NullPointerException; rolling back session: null
> Additionally, the incoming flowfiles now ends up in some "dead" state where 
> I'm unable to even empty the queue.
> A simple template for reproduction is attached.



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

[jira] [Resolved] (MINIFICPP-316) Resolve build issue with GPS extension

[marco polo (JIRA)]

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

marco polo resolved MINIFICPP-316.
--
Resolution: Fixed

> Resolve build issue with GPS extension
> --
>
> Key: MINIFICPP-316
> URL: https://issues.apache.org/jira/browse/MINIFICPP-316
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.3.0
>Reporter: marco polo
>Assignee: marco polo
> Fix For: 0.3.0
>
>




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

[jira] [Created] (NIFIREG-57) Provide ability to provide different 'verbiage providers' for flow differences when comparing two flows

[Mark Payne (JIRA)]

Mark Payne created NIFIREG-57:
-

 Summary: Provide ability to provide different 'verbiage providers' 
for flow differences when comparing two flows
 Key: NIFIREG-57
 URL: https://issues.apache.org/jira/browse/NIFIREG-57
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Mark Payne
Assignee: Mark Payne






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

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

GitHub user sbouchex opened a pull request:

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

NIFI-4597 Add a property to override HTTP return code in ListenHTTP 
processor

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [ x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ x] Have you written or updated unit tests to verify your changes?
- [ x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ x] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [x ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [x ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [x ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/infovista/nifi NIFI-4597-bis

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

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


commit f295b9437a7bd3bfb165f7e145a30803126a3e89
Author: sbouchex 
Date:   2017-11-21T19:23:26Z

Add a property to override HTTP return code in ListenHTTP processor




> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi pull request #2283: NIFI-4597 Add a property to override HTTP return co...

[sbouchex]

GitHub user sbouchex opened a pull request:

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

NIFI-4597 Add a property to override HTTP return code in ListenHTTP 
processor

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

### For code changes:
- [ x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ x] Have you written or updated unit tests to verify your changes?
- [ x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ x] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [x ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [x ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [x ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/infovista/nifi NIFI-4597-bis

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

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


commit f295b9437a7bd3bfb165f7e145a30803126a3e89
Author: sbouchex 
Date:   2017-11-21T19:23:26Z

Add a property to override HTTP return code in ListenHTTP processor




---

[jira] [Updated] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fredrik Sko (JIRA)]

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

Fredrik Sko updated NIFI-4629:
--
Component/s: Core UI

> Non-existing attribute in ControlRate configuration causes 
> NullPointerException
> ---
>
> Key: NIFI-4629
> URL: https://issues.apache.org/jira/browse/NIFI-4629
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration, Core UI
>Affects Versions: 1.4.0
> Environment: Ubuntu LTS 16.04
> openjdk-8-jre
>Reporter: Fredrik Sko
>Priority: Critical
>  Labels: ControlRate, NullPointerException, Processor
> Attachments: ControlRate-NP.xml
>
>
> When using the ControlRate processor, defining the "Grouping Attribute" with 
> a missing/non-existing attribute name produces NullPointerException errors.
> Processor configuration:
> {quote}
> Rate Control Criteria: flowfile count
> Maximum rate: 10
> Rate Controlled Attributes: (No value set)
> Time Duration: 1 min
> Grouping Attribute: foobar
> {quote}
> ControlRate with the following configuration when sent a flowfile without the 
> attribute {{foobar}} generates the following error:
> bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
> ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due 
> to java.lang.NullPointerException; rolling back session: null
> Additionally, the incoming flowfiles now ends up in some "dead" state where 
> I'm unable to even empty the queue.
> A simple template for reproduction is attached.



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

[jira] [Commented] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fredrik Sko (JIRA)]

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

Fredrik Sko commented on NIFI-4629:
---

bq. Additionally, the incoming flowfiles now ends up in some "dead" state where 
I'm unable to even empty the queue.

To clarify, this is the reason I submitted the issue with a critical severity. 
This makes my data inaccessible and I have yet to find a workaround to recover 
it.

> Non-existing attribute in ControlRate configuration causes 
> NullPointerException
> ---
>
> Key: NIFI-4629
> URL: https://issues.apache.org/jira/browse/NIFI-4629
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.4.0
> Environment: Ubuntu LTS 16.04
> openjdk-8-jre
>Reporter: Fredrik Sko
>Priority: Critical
>  Labels: ControlRate, NullPointerException, Processor
> Attachments: ControlRate-NP.xml
>
>
> When using the ControlRate processor, defining the "Grouping Attribute" with 
> a missing/non-existing attribute name produces NullPointerException errors.
> Processor configuration:
> {quote}
> Rate Control Criteria: flowfile count
> Maximum rate: 10
> Rate Controlled Attributes: (No value set)
> Time Duration: 1 min
> Grouping Attribute: foobar
> {quote}
> ControlRate with the following configuration when sent a flowfile without the 
> attribute {{foobar}} generates the following error:
> bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
> ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due 
> to java.lang.NullPointerException; rolling back session: null
> Additionally, the incoming flowfiles now ends up in some "dead" state where 
> I'm unable to even empty the queue.
> A simple template for reproduction is attached.



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

[jira] [Updated] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fredrik Sko (JIRA)]

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

Fredrik Sko updated NIFI-4629:
--
Description: 
When using the ControlRate processor, defining the "Grouping Attribute" with a 
missing/non-existing attribute name produces NullPointerException errors.

Processor configuration:
{quote}
Rate Control Criteria: flowfile count
Maximum rate: 10
Rate Controlled Attributes: (No value set)
Time Duration: 1 min
Grouping Attribute: foobar
{quote}

ControlRate with the following configuration when sent a flowfile without the 
attribute {{foobar}} generates the following error:

bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due to 
java.lang.NullPointerException; rolling back session: null

Additionally, the incoming flowfiles now ends up in some "dead" state where I'm 
unable to even empty the queue.

A simple template for reproduction is attached.

  was:
When using the ControlRate processor, defining the "Grouping Attribute" with a 
missing/non-existing attribute name produces NullPointerException errors.

Processor configuration:
{quote}
Rate Control Criteria: flowfile count
Maximum rate: 10
Rate Controlled Attributes: (No value set)
Time Duration: 1 min
Grouping Attribute: foobar
{quote}

ControlRate with the following configuration when sent a flowfile without the 
attributes {{foobar}} generates the following error:

bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due to 
java.lang.NullPointerException; rolling back session: null

Additionally, the incoming flowfiles now ends up in some "dead" state where I'm 
unable to even empty the queue.

A simple template for reproduction is attached.


> Non-existing attribute in ControlRate configuration causes 
> NullPointerException
> ---
>
> Key: NIFI-4629
> URL: https://issues.apache.org/jira/browse/NIFI-4629
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.4.0
> Environment: Ubuntu LTS 16.04
> openjdk-8-jre
>Reporter: Fredrik Sko
>Priority: Critical
>  Labels: ControlRate, NullPointerException, Processor
> Attachments: ControlRate-NP.xml
>
>
> When using the ControlRate processor, defining the "Grouping Attribute" with 
> a missing/non-existing attribute name produces NullPointerException errors.
> Processor configuration:
> {quote}
> Rate Control Criteria: flowfile count
> Maximum rate: 10
> Rate Controlled Attributes: (No value set)
> Time Duration: 1 min
> Grouping Attribute: foobar
> {quote}
> ControlRate with the following configuration when sent a flowfile without the 
> attribute {{foobar}} generates the following error:
> bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
> ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due 
> to java.lang.NullPointerException; rolling back session: null
> Additionally, the incoming flowfiles now ends up in some "dead" state where 
> I'm unable to even empty the queue.
> A simple template for reproduction is attached.



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

[jira] [Created] (NIFI-4629) Non-existing attribute in ControlRate configuration causes NullPointerException

[Fred Sko (JIRA)]

Fred Sko created NIFI-4629:
--

 Summary: Non-existing attribute in ControlRate configuration 
causes NullPointerException
 Key: NIFI-4629
 URL: https://issues.apache.org/jira/browse/NIFI-4629
 Project: Apache NiFi
  Issue Type: Bug
  Components: Configuration
Affects Versions: 1.4.0
 Environment: Ubuntu LTS 16.04
openjdk-8-jre
Reporter: Fred Sko
Priority: Critical
 Attachments: ControlRate-NP.xml

When using the ControlRate processor, defining the "Grouping Attribute" with a 
missing/non-existing attribute name produces NullPointerException errors.

Processor configuration:
{quote}
Rate Control Criteria: flowfile count
Maximum rate: 10
Rate Controlled Attributes: (No value set)
Time Duration: 1 min
Grouping Attribute: foobar
{quote}

ControlRate with the following configuration when sent a flowfile without the 
attributes {{foobar}} generates the following error:

bq. ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] 
ControlRate\[id=dff05b32-015f-1000-db55-5957a9298bab] failed to process due to 
java.lang.NullPointerException; rolling back session: null

Additionally, the incoming flowfiles now ends up in some "dead" state where I'm 
unable to even empty the queue.

A simple template for reproduction is attached.



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

[jira] [Resolved] (MINIFICPP-317) CPACK Ignore files excludes any build dir making it impossible to build third party dependencies from generated source

[Aldrin Piri (JIRA)]

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

Aldrin Piri resolved MINIFICPP-317.
---
Resolution: Fixed

> CPACK Ignore files excludes any build dir making it impossible to build third 
> party dependencies from generated source
> --
>
> Key: MINIFICPP-317
> URL: https://issues.apache.org/jira/browse/MINIFICPP-317
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
>Priority: Blocker
> Fix For: 0.3.0
>
>




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

[jira] [Commented] (MINIFICPP-317) CPACK Ignore files excludes any build dir making it impossible to build third party dependencies from generated source

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261266#comment-16261266
 ] 

ASF GitHub Bot commented on MINIFICPP-317:
--

Github user asfgit closed the pull request at:

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


> CPACK Ignore files excludes any build dir making it impossible to build third 
> party dependencies from generated source
> --
>
> Key: MINIFICPP-317
> URL: https://issues.apache.org/jira/browse/MINIFICPP-317
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
>Priority: Blocker
> Fix For: 0.3.0
>
>




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

[GitHub] nifi-minifi-cpp pull request #202: MINIFICPP-317: Update the cpackage ignore...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (MINIFICPP-317) CPACK Ignore files excludes any build dir making it impossible to build third party dependencies from generated source

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261263#comment-16261263
 ] 

ASF GitHub Bot commented on MINIFICPP-317:
--

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/202
  
change makes sense, will get this merged


> CPACK Ignore files excludes any build dir making it impossible to build third 
> party dependencies from generated source
> --
>
> Key: MINIFICPP-317
> URL: https://issues.apache.org/jira/browse/MINIFICPP-317
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
>Priority: Blocker
> Fix For: 0.3.0
>
>




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

[GitHub] nifi-minifi-cpp issue #202: MINIFICPP-317: Update the cpackage ignore files ...

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/202
  
change makes sense, will get this merged


---

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2266
  
@sbouchex totally understand.  Git is a powerful animal and it can easily 
make us all feel a little lost. Will try to keep an eye out for the next one.  
Thanks for sticking with it.


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi issue #2266: NIFI-4597 Add a property to override HTTP return code in L...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2266
  
@sbouchex totally understand.  Git is a powerful animal and it can easily 
make us all feel a little lost. Will try to keep an eye out for the next one.  
Thanks for sticking with it.


---

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

Github user sbouchex commented on the issue:

https://github.com/apache/nifi/pull/2266
  
Gonna restart the branch, I have messed up everything :-(


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi issue #2266: NIFI-4597 Add a property to override HTTP return code in L...

[sbouchex]

Github user sbouchex commented on the issue:

https://github.com/apache/nifi/pull/2266
  
Gonna restart the branch, I have messed up everything :-(


---

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

Github user sbouchex closed the pull request at:

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


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi pull request #2266: NIFI-4597 Add a property to override HTTP return co...

[sbouchex]

Github user sbouchex closed the pull request at:

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


---

[jira] [Commented] (MINIFICPP-317) CPACK Ignore files excludes any build dir making it impossible to build third party dependencies from generated source

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261229#comment-16261229
 ] 

ASF GitHub Bot commented on MINIFICPP-317:
--

GitHub user phrocker opened a pull request:

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

MINIFICPP-317: Update the cpackage ignore files option so that don't …

…ignore subdirectories named build in third party

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

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

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

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

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

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

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-317

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

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


commit 2e084846c66f5d61c8d7b9f1ce047427bfcccefb
Author: Marc Parisi 
Date:   2017-11-21T18:29:44Z

MINIFICPP-317: Update the cpackage ignore files option so that don't ignore 
subdirectories named build in third party




> CPACK Ignore files excludes any build dir making it impossible to build third 
> party dependencies from generated source
> --
>
> Key: MINIFICPP-317
> URL: https://issues.apache.org/jira/browse/MINIFICPP-317
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
>Priority: Blocker
> Fix For: 0.3.0
>
>




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

[GitHub] nifi-minifi-cpp pull request #202: MINIFICPP-317: Update the cpackage ignore...

[phrocker]

GitHub user phrocker opened a pull request:

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

MINIFICPP-317: Update the cpackage ignore files option so that don't …

…ignore subdirectories named build in third party

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

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

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

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

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

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

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-317

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

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


commit 2e084846c66f5d61c8d7b9f1ce047427bfcccefb
Author: Marc Parisi 
Date:   2017-11-21T18:29:44Z

MINIFICPP-317: Update the cpackage ignore files option so that don't ignore 
subdirectories named build in third party




---

[jira] [Created] (MINIFICPP-317) CPACK Ignore files excludes any build dir making it impossible to build third party dependencies from generated source

[marco polo (JIRA)]

marco polo created MINIFICPP-317:


 Summary: CPACK Ignore files excludes any build dir making it 
impossible to build third party dependencies from generated source
 Key: MINIFICPP-317
 URL: https://issues.apache.org/jira/browse/MINIFICPP-317
 Project: NiFi MiNiFi C++
  Issue Type: Bug
Reporter: marco polo
Assignee: marco polo
Priority: Blocker
 Fix For: 0.3.0






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

[jira] [Created] (NIFI-4628) Update ListS3 proccesor to support List Objects Version 2

[Andrew Burkard (JIRA)]

Andrew Burkard created NIFI-4628:


 Summary: Update ListS3 proccesor to support List Objects Version 2
 Key: NIFI-4628
 URL: https://issues.apache.org/jira/browse/NIFI-4628
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Extensions
Reporter: Andrew Burkard
Priority: Minor


AWS has revised the List Objects API: 
http://docs.aws.amazon.com/AmazonS3/latest/API/v2-RESTBucketGET.html

The main difference is the new API passes a continuation token in the response 
for multi-page listings rather than requiring the client to keep track of the 
lexicographically last key listed. The new version also appears to be the only 
API supported going forward for new AWS services (e.g. Snowball). It would be 
nice if the ListS3 processor supported either via an attribute.



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

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2266
  
Please remove the merge commit.  Might need to rebase and put your core 
changes over it.


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi issue #2266: NIFI-4597 Add a property to override HTTP return code in L...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2266
  
Please remove the merge commit.  Might need to rebase and put your core 
changes over it.


---

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

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

https://github.com/apache/nifi/pull/2266#discussion_r152358153
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestListenHTTP.java
 ---
@@ -89,7 +90,7 @@ public void testPOSTRequestsReceivedReturnCodeWithoutEL() 
throws Exception {
 runner.setProperty(ListenHTTP.BASE_PATH, HTTP_BASE_PATH);
 runner.setProperty(ListenHTTP.RETURN_CODE, Integer.toString(204));
 
-testPOSTRequestsReceived(204);
+testPOSTRequestsReceived(HttpServletResponse.SC_OK);
--- End diff --

should this have been HttpServletResponse. SC_NO_CONTENT?  The line removed 
had a code of 204 but this is now passing in a 200.


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi pull request #2266: NIFI-4597 Add a property to override HTTP return co...

[joewitt]

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

https://github.com/apache/nifi/pull/2266#discussion_r152358153
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestListenHTTP.java
 ---
@@ -89,7 +90,7 @@ public void testPOSTRequestsReceivedReturnCodeWithoutEL() 
throws Exception {
 runner.setProperty(ListenHTTP.BASE_PATH, HTTP_BASE_PATH);
 runner.setProperty(ListenHTTP.RETURN_CODE, Integer.toString(204));
 
-testPOSTRequestsReceived(204);
+testPOSTRequestsReceived(HttpServletResponse.SC_OK);
--- End diff --

should this have been HttpServletResponse. SC_NO_CONTENT?  The line removed 
had a code of 204 but this is now passing in a 200.


---

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

Github user sbouchex commented on the issue:

https://github.com/apache/nifi/pull/2266
  
@joewitt changed


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi issue #2266: NIFI-4597 Add a property to override HTTP return code in L...

[sbouchex]

Github user sbouchex commented on the issue:

https://github.com/apache/nifi/pull/2266
  
@joewitt changed


---

[jira] [Updated] (NIFI-4459) Confluent Schema Registry - not tolerant to error in single Subject

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-4459:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

+1 merged to master

> Confluent Schema Registry - not tolerant to error in single Subject
> ---
>
> Key: NIFI-4459
> URL: https://issues.apache.org/jira/browse/NIFI-4459
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Dave Torok
>Assignee: Mark Payne
>Priority: Minor
> Fix For: 1.5.0
>
>
> Getting Could not find Schema with id 12345 from the Confluent Schema 
> Registry.
> Root cause:
> 1.  RestSchemaRegistryClient.java  - gets all subjects from the registry 
> {noformat}https://{registry}/subjects{noformat}
> 2.  Iterates through the subjects to get schema IDs  (getSchema method line 
> 113-126)
> {noformat}https://{registry}/subjects/{subjectname}/ids/latest{noformat}
> 3.  If  ANY subject in the list of subjects has an error / resource not 
> found, lookup FAILS, even if the subject with the matching ID is anywhere in 
> the list of subjects.
> Proposed Fix: 
> Tolerate individual subject calls that return errors (NOT_FOUND status).



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

[jira] [Commented] (NIFI-4459) Confluent Schema Registry - not tolerant to error in single Subject

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4459:
--

Github user asfgit closed the pull request at:

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


> Confluent Schema Registry - not tolerant to error in single Subject
> ---
>
> Key: NIFI-4459
> URL: https://issues.apache.org/jira/browse/NIFI-4459
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Dave Torok
>Assignee: Mark Payne
>Priority: Minor
> Fix For: 1.5.0
>
>
> Getting Could not find Schema with id 12345 from the Confluent Schema 
> Registry.
> Root cause:
> 1.  RestSchemaRegistryClient.java  - gets all subjects from the registry 
> {noformat}https://{registry}/subjects{noformat}
> 2.  Iterates through the subjects to get schema IDs  (getSchema method line 
> 113-126)
> {noformat}https://{registry}/subjects/{subjectname}/ids/latest{noformat}
> 3.  If  ANY subject in the list of subjects has an error / resource not 
> found, lookup FAILS, even if the subject with the matching ID is anywhere in 
> the list of subjects.
> Proposed Fix: 
> Tolerate individual subject calls that return errors (NOT_FOUND status).



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

[jira] [Commented] (NIFI-4459) Confluent Schema Registry - not tolerant to error in single Subject

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-4459: This closes #2240. Catch Exception if trying to iterate over many 
confluent schemas and unable to load one; in this case log a WARNING and 
continue on; also updated Jersey client to newest

Signed-off-by: joewitt 


> Confluent Schema Registry - not tolerant to error in single Subject
> ---
>
> Key: NIFI-4459
> URL: https://issues.apache.org/jira/browse/NIFI-4459
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Dave Torok
>Assignee: Mark Payne
>Priority: Minor
> Fix For: 1.5.0
>
>
> Getting Could not find Schema with id 12345 from the Confluent Schema 
> Registry.
> Root cause:
> 1.  RestSchemaRegistryClient.java  - gets all subjects from the registry 
> {noformat}https://{registry}/subjects{noformat}
> 2.  Iterates through the subjects to get schema IDs  (getSchema method line 
> 113-126)
> {noformat}https://{registry}/subjects/{subjectname}/ids/latest{noformat}
> 3.  If  ANY subject in the list of subjects has an error / resource not 
> found, lookup FAILS, even if the subject with the matching ID is anywhere in 
> the list of subjects.
> Proposed Fix: 
> Tolerate individual subject calls that return errors (NOT_FOUND status).



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

[jira] [Commented] (NIFIREG-52) Kerberos Identity Provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261153#comment-16261153
 ] 

ASF GitHub Bot commented on NIFIREG-52:
---

Github user asfgit closed the pull request at:

https://github.com/apache/nifi-registry/pull/41


> Kerberos Identity Provider
> --
>
> Key: NIFIREG-52
> URL: https://issues.apache.org/jira/browse/NIFIREG-52
> Project: NiFi Registry
>  Issue Type: New Feature
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Implement a new NiFi Registry IdentityProvider implementation backed by 
> Kerberos that will allow a JWT to be generated given a valid Kerberos ticket. 
> Will be similar to the NiFi implementation of KerberosProvider



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

[jira] [Commented] (NIFIREG-52) Kerberos Identity Provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261154#comment-16261154
 ] 

ASF GitHub Bot commented on NIFIREG-52:
---

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/41
  
Thanks @bbende! 


> Kerberos Identity Provider
> --
>
> Key: NIFIREG-52
> URL: https://issues.apache.org/jira/browse/NIFIREG-52
> Project: NiFi Registry
>  Issue Type: New Feature
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Implement a new NiFi Registry IdentityProvider implementation backed by 
> Kerberos that will allow a JWT to be generated given a valid Kerberos ticket. 
> Will be similar to the NiFi implementation of KerberosProvider



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

[jira] [Resolved] (NIFIREG-52) Kerberos Identity Provider

[Bryan Bende (JIRA)]

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

Bryan Bende resolved NIFIREG-52.

   Resolution: Fixed
Fix Version/s: 0.0.1

> Kerberos Identity Provider
> --
>
> Key: NIFIREG-52
> URL: https://issues.apache.org/jira/browse/NIFIREG-52
> Project: NiFi Registry
>  Issue Type: New Feature
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Implement a new NiFi Registry IdentityProvider implementation backed by 
> Kerberos that will allow a JWT to be generated given a valid Kerberos ticket. 
> Will be similar to the NiFi implementation of KerberosProvider



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

[jira] [Commented] (NIFIREG-52) Kerberos Identity Provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261151#comment-16261151
 ] 

ASF GitHub Bot commented on NIFIREG-52:
---

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/41
  
Tested SPNEGO and the Kerbers username/password identity provider, 
everything seems to be working, nice job! Going to merge...


> Kerberos Identity Provider
> --
>
> Key: NIFIREG-52
> URL: https://issues.apache.org/jira/browse/NIFIREG-52
> Project: NiFi Registry
>  Issue Type: New Feature
>Reporter: Kevin Doran
>Assignee: Kevin Doran
>
> Implement a new NiFi Registry IdentityProvider implementation backed by 
> Kerberos that will allow a JWT to be generated given a valid Kerberos ticket. 
> Will be similar to the NiFi implementation of KerberosProvider



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

[GitHub] nifi-registry pull request #41: NIFIREG-52 Add Kerberos Support

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi-registry/pull/41


---

[GitHub] nifi-registry issue #41: NIFIREG-52 Add Kerberos Support

[kevdoran]

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/41
  
Thanks @bbende! 


---

[GitHub] nifi-registry issue #41: NIFIREG-52 Add Kerberos Support

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/41
  
Tested SPNEGO and the Kerbers username/password identity provider, 
everything seems to be working, nice job! Going to merge...


---

[jira] [Commented] (NIFI-4463) MQTT client disconnection in ConsumeMQTT Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4463:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2241
  
@dometec thanks for your contribution and particularly for it being such a 
substantive one.  This will require someone to give it a good review/test 
cycle.  Apologies for the delay but hopefully someone will soon jump on this.


> MQTT client disconnection in ConsumeMQTT Processor
> --
>
> Key: NIFI-4463
> URL: https://issues.apache.org/jira/browse/NIFI-4463
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
> Environment: OS: Centos /
> MQTT Borker: mosquitto
>Reporter: Stefano Melzi
>Priority: Minor
>
> When internal queue is full the messageArrived method throws an exception 
> causing the MQTT client to disconnect. This event is managed creating a new 
> client which try to reconnect to the broker.
> In our test using a mosquitto broker with a high mqtt traffic and a low value 
> for "Max Queue Size" property we experiment broker disconnection when 
> internal queue is full, but after this event MQTT Processor remains blocked 
> without any attempt to reconnect.



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

[GitHub] nifi issue #2241: NIFI-4463 New MQTT Consume logic

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2241
  
@dometec thanks for your contribution and particularly for it being such a 
substantive one.  This will require someone to give it a good review/test 
cycle.  Apologies for the delay but hopefully someone will soon jump on this.


---

[jira] [Updated] (NIFI-3515) Consider adding @EventDriven to PutFile

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-3515:
--
Fix Version/s: 1.5.0

> Consider adding @EventDriven to PutFile
> ---
>
> Key: NIFI-3515
> URL: https://issues.apache.org/jira/browse/NIFI-3515
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Michael Hogue
>Priority: Trivial
> Fix For: 1.5.0
>
>
> PutFile seems like it could potentially be a candidate for supporting Event 
> Driven scheduling...



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

[jira] [Resolved] (NIFI-3515) Consider adding @EventDriven to PutFile

[Joseph Witt (JIRA)]

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

Joseph Witt resolved NIFI-3515.
---
Resolution: Fixed

+1 merged to master

> Consider adding @EventDriven to PutFile
> ---
>
> Key: NIFI-3515
> URL: https://issues.apache.org/jira/browse/NIFI-3515
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Michael Hogue
>Priority: Trivial
> Fix For: 1.5.0
>
>
> PutFile seems like it could potentially be a candidate for supporting Event 
> Driven scheduling...



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

[jira] [Commented] (NIFI-3515) Consider adding @EventDriven to PutFile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3515:
--

Github user asfgit closed the pull request at:

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


> Consider adding @EventDriven to PutFile
> ---
>
> Key: NIFI-3515
> URL: https://issues.apache.org/jira/browse/NIFI-3515
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Michael Hogue
>Priority: Trivial
>
> PutFile seems like it could potentially be a candidate for supporting Event 
> Driven scheduling...



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

[GitHub] nifi pull request #2257: NIFI-3515: Added @EventDriven to PutFile

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (NIFI-3515) Consider adding @EventDriven to PutFile

[ASF subversion and git services (JIRA)]

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

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

Commit 73702004b955598bde264b1cf55bfca2f8a50a50 in nifi's branch 
refs/heads/master from m-hogue
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=7370200 ]

NIFI-3515: This closes #2257. Added EventDriven annotation to PutFile

Signed-off-by: joewitt 


> Consider adding @EventDriven to PutFile
> ---
>
> Key: NIFI-3515
> URL: https://issues.apache.org/jira/browse/NIFI-3515
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Michael Hogue
>Priority: Trivial
>
> PutFile seems like it could potentially be a candidate for supporting Event 
> Driven scheduling...



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

[jira] [Commented] (MINIFICPP-251) Move Civet implementations to an extension.

[Caleb Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261135#comment-16261135
 ] 

Caleb Johnson commented on MINIFICPP-251:
-

I think I'll move them to their own folder, which is only added to the build 
with add_subdirectory() when both civet and curl features are enabled

> Move Civet implementations to an extension.
> ---
>
> Key: MINIFICPP-251
> URL: https://issues.apache.org/jira/browse/MINIFICPP-251
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>
> We should be able to move anything that uses Civet, such as ListenHTTP and 
> any dependencies ( such as boost ) to an extension and allow boost, civet, 
> and any related libraries to be excluded from the build with an argument



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

[jira] [Commented] (NIFI-3515) Consider adding @EventDriven to PutFile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3515:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2257
  
+1 merging to master.  Probably will want to document that this processor 
if configured with too many threads can make for a very unhappy file system in 
certain cases.  But that was true previously as well.


> Consider adding @EventDriven to PutFile
> ---
>
> Key: NIFI-3515
> URL: https://issues.apache.org/jira/browse/NIFI-3515
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Michael Hogue
>Priority: Trivial
>
> PutFile seems like it could potentially be a candidate for supporting Event 
> Driven scheduling...



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

[GitHub] nifi issue #2257: NIFI-3515: Added @EventDriven to PutFile

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2257
  
+1 merging to master.  Probably will want to document that this processor 
if configured with too many threads can make for a very unhappy file system in 
certain cases.  But that was true previously as well.


---

[jira] [Commented] (MINIFICPP-251) Move Civet implementations to an extension.

[Caleb Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261124#comment-16261124
 ] 

Caleb Johnson commented on MINIFICPP-251:
-

How should the curl tests be restructured? All of them require civet, and any 
tests of civet would need curl.

> Move Civet implementations to an extension.
> ---
>
> Key: MINIFICPP-251
> URL: https://issues.apache.org/jira/browse/MINIFICPP-251
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>
> We should be able to move anything that uses Civet, such as ListenHTTP and 
> any dependencies ( such as boost ) to an extension and allow boost, civet, 
> and any related libraries to be excluded from the build with an argument



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

[jira] [Commented] (NIFI-4597) Add a property to override HTTP return code in ListenHTTP processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4597:
--

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

https://github.com/apache/nifi/pull/2266#discussion_r152349436
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListenHTTP.java
 ---
@@ -95,6 +95,13 @@
 .expressionLanguageSupported(true)
 .addValidator(StandardValidators.POSITIVE_INTEGER_VALIDATOR)
 .build();
+public static final PropertyDescriptor RETURN_CODE = new 
PropertyDescriptor.Builder()
+.name("Return Code")
+.description("The HTTP return code returned after every HTTP 
call")
+.required(true)
+.defaultValue("200")
--- End diff --

Probably should use string value of HttpServletResponse.SC_OK instead of 
"200".  Stays consistent with previous entry used.  Not a big deal at all 
obviously.


> Add a property to override HTTP return code in ListenHTTP processor
> ---
>
> Key: NIFI-4597
> URL: https://issues.apache.org/jira/browse/NIFI-4597
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Sébastien Bouchex Bellomié
> Fix For: 1.5.0
>
>
> Current ListenHTTP processor is always returning 200 as HTTP return code but 
> is some case, 204 may be required.
> I know that I may use the HandlerHttpRequest and HandlerHttpResponse couple 
> but that's a bit overkill to this.
> The idea is to have a property (default value is 200) giving the ability to 
> override the return code.



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

[GitHub] nifi pull request #2266: NIFI-4597 Add a property to override HTTP return co...

[joewitt]

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

https://github.com/apache/nifi/pull/2266#discussion_r152349436
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListenHTTP.java
 ---
@@ -95,6 +95,13 @@
 .expressionLanguageSupported(true)
 .addValidator(StandardValidators.POSITIVE_INTEGER_VALIDATOR)
 .build();
+public static final PropertyDescriptor RETURN_CODE = new 
PropertyDescriptor.Builder()
+.name("Return Code")
+.description("The HTTP return code returned after every HTTP 
call")
+.required(true)
+.defaultValue("200")
--- End diff --

Probably should use string value of HttpServletResponse.SC_OK instead of 
"200".  Stays consistent with previous entry used.  Not a big deal at all 
obviously.


---

[jira] [Commented] (MINIFICPP-304) Release MiNiFI C++ Version 0.3.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261113#comment-16261113
 ] 

ASF GitHub Bot commented on MINIFICPP-304:
--

Github user asfgit closed the pull request at:

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


> Release MiNiFI C++ Version 0.3.0
> 
>
> Key: MINIFICPP-304
> URL: https://issues.apache.org/jira/browse/MINIFICPP-304
> Project: NiFi MiNiFi C++
>  Issue Type: Task
>Reporter: marco polo
>Assignee: marco polo
> Fix For: 0.3.0
>
>




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

[GitHub] nifi-minifi-cpp pull request #201: MINIFICPP-304: Update readme to reflect c...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (MINIFICPP-304) Release MiNiFI C++ Version 0.3.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261110#comment-16261110
 ] 

ASF GitHub Bot commented on MINIFICPP-304:
--

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/201
  
looks good, will merge


> Release MiNiFI C++ Version 0.3.0
> 
>
> Key: MINIFICPP-304
> URL: https://issues.apache.org/jira/browse/MINIFICPP-304
> Project: NiFi MiNiFi C++
>  Issue Type: Task
>Reporter: marco polo
>Assignee: marco polo
> Fix For: 0.3.0
>
>




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

[GitHub] nifi-minifi-cpp issue #201: MINIFICPP-304: Update readme to reflect correct ...

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/201
  
looks good, will merge


---

[jira] [Commented] (MINIFICPP-304) Release MiNiFI C++ Version 0.3.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261105#comment-16261105
 ] 

ASF GitHub Bot commented on MINIFICPP-304:
--

GitHub user phrocker opened a pull request:

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

 MINIFICPP-304: Update readme to reflect correct lib

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

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

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

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

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

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

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-304-R

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

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


commit c61ba7d03a54c16f8b22fbab41c996f2fc9bbd05
Author: Marc Parisi 
Date:   2017-11-21T17:28:13Z

 MINIFICPP-304: Update readme to reflect correct lib




> Release MiNiFI C++ Version 0.3.0
> 
>
> Key: MINIFICPP-304
> URL: https://issues.apache.org/jira/browse/MINIFICPP-304
> Project: NiFi MiNiFi C++
>  Issue Type: Task
>Reporter: marco polo
>Assignee: marco polo
> Fix For: 0.3.0
>
>




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

[GitHub] nifi-minifi-cpp pull request #201: MINIFICPP-304: Update readme to reflect c...

[phrocker]

GitHub user phrocker opened a pull request:

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

 MINIFICPP-304: Update readme to reflect correct lib

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

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

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

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

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

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

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-304-R

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

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


commit c61ba7d03a54c16f8b22fbab41c996f2fc9bbd05
Author: Marc Parisi 
Date:   2017-11-21T17:28:13Z

 MINIFICPP-304: Update readme to reflect correct lib




---

[jira] [Resolved] (NIFI-4623) Remove obsolete instability warning in documentation of newer (>= 0_10) Kafka processors

[Joseph Witt (JIRA)]

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

Joseph Witt resolved NIFI-4623.
---
Resolution: Fixed

+1 merged to master.  Thanks for contributing [~jwoschitz]!

> Remove obsolete instability warning in documentation of newer (>= 0_10) Kafka 
> processors
> 
>
> Key: NIFI-4623
> URL: https://issues.apache.org/jira/browse/NIFI-4623
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.4.0
>Reporter: Janosch Woschitz
>Priority: Minor
>  Labels: documentation
> Fix For: 1.5.0
>
>
> The documentation of all Kafka processors (publish and consume) does contain 
> the following warning:
> {quote}Please note there are cases where the publisher can get into an 
> indefinite stuck state. We are closely monitoring how this evolves in the 
> Kafka community and will take advantage of those fixes as soon as we can. In 
> the meantime it is possible to enter states where the only resolution will be 
> to restart the JVM NiFi runs on.{quote}
> Based on a conversation on the dev mailing list, Joe Witt stated that this 
> warning is not needed anymore for processors targeting Kafka 0_10 and beyond:
> {quote}It was there previously because it
> was observed that timeout conditions could cause threads to stay in a
> hung state and as the caller of the client we weren't in a position to
> resolve it.  However, newer client libraries are better and I no
> longer have observed these issues personally.  For the 0_10 or newer
> clients I think we can adjust the docs to indicate that these should
> work just fine.{quote}



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

[jira] [Updated] (NIFI-4623) Remove obsolete instability warning in documentation of newer (>= 0_10) Kafka processors

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-4623:
--
Fix Version/s: 1.5.0

> Remove obsolete instability warning in documentation of newer (>= 0_10) Kafka 
> processors
> 
>
> Key: NIFI-4623
> URL: https://issues.apache.org/jira/browse/NIFI-4623
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.4.0
>Reporter: Janosch Woschitz
>Priority: Minor
>  Labels: documentation
> Fix For: 1.5.0
>
>
> The documentation of all Kafka processors (publish and consume) does contain 
> the following warning:
> {quote}Please note there are cases where the publisher can get into an 
> indefinite stuck state. We are closely monitoring how this evolves in the 
> Kafka community and will take advantage of those fixes as soon as we can. In 
> the meantime it is possible to enter states where the only resolution will be 
> to restart the JVM NiFi runs on.{quote}
> Based on a conversation on the dev mailing list, Joe Witt stated that this 
> warning is not needed anymore for processors targeting Kafka 0_10 and beyond:
> {quote}It was there previously because it
> was observed that timeout conditions could cause threads to stay in a
> hung state and as the caller of the client we weren't in a position to
> resolve it.  However, newer client libraries are better and I no
> longer have observed these issues personally.  For the 0_10 or newer
> clients I think we can adjust the docs to indicate that these should
> work just fine.{quote}



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

[jira] [Commented] (NIFI-4623) Remove obsolete instability warning in documentation of newer (>= 0_10) Kafka processors

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-4623: This closes #2281. Removed obsolete instability warning in 
documentation of newer (>= 0_10) Kafka processors

Signed-off-by: joewitt 


> Remove obsolete instability warning in documentation of newer (>= 0_10) Kafka 
> processors
> 
>
> Key: NIFI-4623
> URL: https://issues.apache.org/jira/browse/NIFI-4623
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.4.0
>Reporter: Janosch Woschitz
>Priority: Minor
>  Labels: documentation
>
> The documentation of all Kafka processors (publish and consume) does contain 
> the following warning:
> {quote}Please note there are cases where the publisher can get into an 
> indefinite stuck state. We are closely monitoring how this evolves in the 
> Kafka community and will take advantage of those fixes as soon as we can. In 
> the meantime it is possible to enter states where the only resolution will be 
> to restart the JVM NiFi runs on.{quote}
> Based on a conversation on the dev mailing list, Joe Witt stated that this 
> warning is not needed anymore for processors targeting Kafka 0_10 and beyond:
> {quote}It was there previously because it
> was observed that timeout conditions could cause threads to stay in a
> hung state and as the caller of the client we weren't in a position to
> resolve it.  However, newer client libraries are better and I no
> longer have observed these issues personally.  For the 0_10 or newer
> clients I think we can adjust the docs to indicate that these should
> work just fine.{quote}



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