[jira] [Assigned] (NIFI-2604) JDBC Connection Pool support for lib directory and expression language
[ https://issues.apache.org/jira/browse/NIFI-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess reassigned NIFI-2604: -- Assignee: Matt Burgess > JDBC Connection Pool support for lib directory and expression language > -- > > Key: NIFI-2604 > URL: https://issues.apache.org/jira/browse/NIFI-2604 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Witt >Assignee: Matt Burgess > > It would be ideal if the JDBC Connection Service supported specifying a > directory instead of particular driver jars. It would also be helpful if it > accepted expression language statements so that it could refer to a location > that is based on variable registry values so it is more portable between > environments. > This stems from a user list thread titled "adding dependencies like jdbc > drivers to the build" on Aug 18 2016 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2599) Enhance Status History Dialog
[ https://issues.apache.org/jira/browse/NIFI-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430815#comment-15430815 ] Joseph Witt commented on NIFI-2599: --- by will review i meant i forgot, haven't gotten to it, and won't be able to right away so if anyone can grab pelase do > Enhance Status History Dialog > - > > Key: NIFI-2599 > URL: https://issues.apache.org/jira/browse/NIFI-2599 > Project: Apache NiFi > Issue Type: Bug >Reporter: Scott Aslan >Assignee: Scott Aslan >Priority: Critical > Fix For: 1.0.0 > > > On reasonable screen res it starts out needing scrolling which seems > unfortunate - then there is a resizer thing but i cannot seem to get it to do > anything - might be because it is hidden by the scrollbar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #894: [NIFI-2599] Enhance Status History Dialog
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/894 Reviewing... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2599) Enhance Status History Dialog
[ https://issues.apache.org/jira/browse/NIFI-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430836#comment-15430836 ] ASF GitHub Bot commented on NIFI-2599: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/894 Reviewing... > Enhance Status History Dialog > - > > Key: NIFI-2599 > URL: https://issues.apache.org/jira/browse/NIFI-2599 > Project: Apache NiFi > Issue Type: Bug >Reporter: Scott Aslan >Assignee: Scott Aslan >Priority: Critical > Fix For: 1.0.0 > > > On reasonable screen res it starts out needing scrolling which seems > unfortunate - then there is a resizer thing but i cannot seem to get it to do > anything - might be because it is hidden by the scrollbar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
Mark Payne created NIFI-2617: Summary: If no ZooKeeper quorum, NiFi does not respond to some web requests Key: NIFI-2617 URL: https://issues.apache.org/jira/browse/NIFI-2617 Project: Apache NiFi Issue Type: Bug Components: Core Framework Reporter: Mark Payne Assignee: Mark Payne Fix For: 1.0.0 If I lose a ZooKeeper quorum, some web requests never return from NiFi, regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #906: NIFI-2617: Instead of retrying an infinite number of...
GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/906 NIFI-2617: Instead of retrying an infinite number of times to communi⦠â¦cate with ZooKeeper, should try only for a short period in CuratorLeaderElectionManager. This is because web requests may be blocked waiting on a determination of which node is cluster coordinator You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-2617 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/906.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 #906 commit 71b58299d625e11bd2c7cc570fdf86ddf8f647b5 Author: Mark Payne Date: 2016-08-22T14:27:26Z NIFI-2617: Instead of retrying an infinite number of times to communicate with ZooKeeper, should try only for a short period in CuratorLeaderElectionManager. This is because web requests may be blocked waiting on a determination of which node is cluster coordinator --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #896: NIFI-2600: Ensure that we do not close Index Searchers prem...
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/896 Reviewing... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2600) Provenance Repository can close Index Reader too soon
[ https://issues.apache.org/jira/browse/NIFI-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430868#comment-15430868 ] ASF GitHub Bot commented on NIFI-2600: -- Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/896 Reviewing... > Provenance Repository can close Index Reader too soon > - > > Key: NIFI-2600 > URL: https://issues.apache.org/jira/browse/NIFI-2600 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > In NIFI-2452, we addressed an issue where the Persistent Provenance Repo > closed Index Readers / Index Searchers before they should. I have found > another case in which that can happen. > Using a separate JIRA rather than re-opening the other, since NIFI-2452 has a > fix Version of both 1.0.0-BETA and 1.0.0 and 1.0.0-BETA has already been > released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430866#comment-15430866 ] ASF GitHub Bot commented on NIFI-2617: -- GitHub user markap14 opened a pull request: https://github.com/apache/nifi/pull/906 NIFI-2617: Instead of retrying an infinite number of times to communi… …cate with ZooKeeper, should try only for a short period in CuratorLeaderElectionManager. This is because web requests may be blocked waiting on a determination of which node is cluster coordinator You can merge this pull request into a Git repository by running: $ git pull https://github.com/markap14/nifi NIFI-2617 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/906.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 #906 commit 71b58299d625e11bd2c7cc570fdf86ddf8f647b5 Author: Mark Payne Date: 2016-08-22T14:27:26Z NIFI-2617: Instead of retrying an infinite number of times to communicate with ZooKeeper, should try only for a short period in CuratorLeaderElectionManager. This is because web requests may be blocked waiting on a determination of which node is cluster coordinator > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-2617: - Status: Patch Available (was: Open) > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430892#comment-15430892
]
Joseph Witt commented on NIFI-2411:
---
removed myself as assignee for review. anyone else avail please grab it
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Witt updated NIFI-2411:
--
Assignee: Joe Skora (was: Joseph Witt)
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (NIFI-2618) TestPostHTTPGroovy test in 0.x branch fails using Java 7
Michael Moser created NIFI-2618: --- Summary: TestPostHTTPGroovy test in 0.x branch fails using Java 7 Key: NIFI-2618 URL: https://issues.apache.org/jira/browse/NIFI-2618 Project: Apache NiFi Issue Type: Task Components: Core Framework Affects Versions: 0.7.0 Reporter: Michael Moser Priority: Trivial The TestPostHTTPGroovy unit test testDefaultShouldPreferTLSv1_2 fails on the 0.x branch when using Java 7 to build. The default TLS in Java 7 is TLSv1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430926#comment-15430926
]
Mark Payne commented on NIFI-2411:
--
I'll pick it up to review.
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (NIFI-2619) ClassLoaderUtils doesn't support spaces between paths or URLs in the paths
Matt Burgess created NIFI-2619: -- Summary: ClassLoaderUtils doesn't support spaces between paths or URLs in the paths Key: NIFI-2619 URL: https://issues.apache.org/jira/browse/NIFI-2619 Project: Apache NiFi Issue Type: Bug Reporter: Matt Burgess Assignee: Matt Burgess ClassLoaderUtils.getCustomClassLoader() splits a module path list on a comma, but doesn't trim the individual entries. Also in ClassLoaderUtils.getURLsForClasspath(), it is assumed that the paths are Files, but they could also already be URLs. Logic should be added to check if the path is already a valid URL, and add it to the list if so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #906: NIFI-2617: Instead of retrying an infinite number of times ...
Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/906 @markap14 picking up for review --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430942#comment-15430942 ] ASF GitHub Bot commented on NIFI-2617: -- Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/906 @markap14 picking up for review > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2618) TestPostHTTPGroovy test in 0.x branch fails using Java 7
[ https://issues.apache.org/jira/browse/NIFI-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Skora reassigned NIFI-2618: --- Assignee: Joe Skora > TestPostHTTPGroovy test in 0.x branch fails using Java 7 > > > Key: NIFI-2618 > URL: https://issues.apache.org/jira/browse/NIFI-2618 > Project: Apache NiFi > Issue Type: Task > Components: Core Framework >Affects Versions: 0.7.0 >Reporter: Michael Moser >Assignee: Joe Skora >Priority: Trivial > > The TestPostHTTPGroovy unit test testDefaultShouldPreferTLSv1_2 fails on the > 0.x branch when using Java 7 to build. The default TLS in Java 7 is TLSv1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Payne updated NIFI-2411:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430953#comment-15430953
]
Mark Payne commented on NIFI-2411:
--
[~jskora] - looks good. +1, Merged to 0.x and master. Thanks!
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #905: NIFI-2611: Fixing bugs in UnpackContent with flow file unpa...
Github user mosermw commented on the issue: https://github.com/apache/nifi/pull/905 Thanks for catching and fixing this bug @gresockj! Reviewing ... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430952#comment-15430952
]
ASF subversion and git services commented on NIFI-2411:
---
Commit 58868abad058c143cfcc2cd9b938df579c72e1aa in nifi's branch refs/heads/0.x
from [~jskora]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=58868ab ]
NIFI-2411: Update to support offsets larger than 2 gigabyte. This closes #903.
This closes #904.
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi pull request #907: NIFI-2619: Added logic to ClassLoaderUtils to trim m...
GitHub user mattyb149 opened a pull request: https://github.com/apache/nifi/pull/907 NIFI-2619: Added logic to ClassLoaderUtils to trim module paths and accept URLs You can merge this pull request into a Git repository by running: $ git pull https://github.com/mattyb149/nifi NIFI-2619 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/907.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 #907 commit 663ada18ff39deb261b6923c47f1f422b859e302 Author: Matt Burgess Date: 2016-08-22T15:09:14Z NIFI-2619: Added unit test showing bugs commit 623d41affe5e24142a2fd8a48d97e682e9245af7 Author: Matt Burgess Date: 2016-08-22T15:11:52Z NIFI-2619: Added logic to ClassLoaderUtils to trim module paths and accept URLs --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2619) ClassLoaderUtils doesn't support spaces between paths or URLs in the paths
[ https://issues.apache.org/jira/browse/NIFI-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430960#comment-15430960 ] ASF GitHub Bot commented on NIFI-2619: -- GitHub user mattyb149 opened a pull request: https://github.com/apache/nifi/pull/907 NIFI-2619: Added logic to ClassLoaderUtils to trim module paths and accept URLs You can merge this pull request into a Git repository by running: $ git pull https://github.com/mattyb149/nifi NIFI-2619 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/907.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 #907 commit 663ada18ff39deb261b6923c47f1f422b859e302 Author: Matt Burgess Date: 2016-08-22T15:09:14Z NIFI-2619: Added unit test showing bugs commit 623d41affe5e24142a2fd8a48d97e682e9245af7 Author: Matt Burgess Date: 2016-08-22T15:11:52Z NIFI-2619: Added logic to ClassLoaderUtils to trim module paths and accept URLs > ClassLoaderUtils doesn't support spaces between paths or URLs in the paths > -- > > Key: NIFI-2619 > URL: https://issues.apache.org/jira/browse/NIFI-2619 > Project: Apache NiFi > Issue Type: Bug >Reporter: Matt Burgess >Assignee: Matt Burgess > > ClassLoaderUtils.getCustomClassLoader() splits a module path list on a comma, > but doesn't trim the individual entries. > Also in ClassLoaderUtils.getURLsForClasspath(), it is assumed that the paths > are Files, but they could also already be URLs. Logic should be added to > check if the path is already a valid URL, and add it to the list if so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430957#comment-15430957
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/905
Thanks for catching and fixing this bug @gresockj! Reviewing ...
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-2619) ClassLoaderUtils doesn't support spaces between paths or URLs in the paths
[ https://issues.apache.org/jira/browse/NIFI-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-2619: --- Status: Patch Available (was: In Progress) > ClassLoaderUtils doesn't support spaces between paths or URLs in the paths > -- > > Key: NIFI-2619 > URL: https://issues.apache.org/jira/browse/NIFI-2619 > Project: Apache NiFi > Issue Type: Bug >Reporter: Matt Burgess >Assignee: Matt Burgess > > ClassLoaderUtils.getCustomClassLoader() splits a module path list on a comma, > but doesn't trim the individual entries. > Also in ClassLoaderUtils.getURLsForClasspath(), it is assumed that the paths > are Files, but they could also already be URLs. Logic should be added to > check if the path is already a valid URL, and add it to the list if so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #905: NIFI-2611: Fixing bugs in UnpackContent with flow fi...
Github user mosermw commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75697030
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestUnpackContent.java
---
@@ -199,11 +199,12 @@ public void testFlowFileStreamV3() throws IOException
{
final TestRunner runner = TestRunners.newTestRunner(new
UnpackContent());
runner.setProperty(UnpackContent.PACKAGING_FORMAT,
UnpackContent.PackageFormat.FLOWFILE_STREAM_FORMAT_V3.toString());
runner.enqueue(dataPath.resolve("data.flowfilev3"));
+runner.enqueue(dataPath.resolve("data.flowfilev3"));
-runner.run();
+runner.run(2);
-runner.assertTransferCount(UnpackContent.REL_SUCCESS, 2);
-runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 1);
+runner.assertTransferCount(UnpackContent.REL_SUCCESS, 4);
+runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 2);
--- End diff --
I would like to see this pattern (send 2 flowfiles) in other unit tests,
too. Can we add this to testTar(), testTarWithFilter(), testZip(),
testZipWithFilter(), and testFlowFileStreamV2()?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430965#comment-15430965
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user mosermw commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75697030
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestUnpackContent.java
---
@@ -199,11 +199,12 @@ public void testFlowFileStreamV3() throws IOException
{
final TestRunner runner = TestRunners.newTestRunner(new
UnpackContent());
runner.setProperty(UnpackContent.PACKAGING_FORMAT,
UnpackContent.PackageFormat.FLOWFILE_STREAM_FORMAT_V3.toString());
runner.enqueue(dataPath.resolve("data.flowfilev3"));
+runner.enqueue(dataPath.resolve("data.flowfilev3"));
-runner.run();
+runner.run(2);
-runner.assertTransferCount(UnpackContent.REL_SUCCESS, 2);
-runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 1);
+runner.assertTransferCount(UnpackContent.REL_SUCCESS, 4);
+runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 2);
--- End diff --
I would like to see this pattern (send 2 flowfiles) in other unit tests,
too. Can we add this to testTar(), testTarWithFilter(), testZip(),
testZipWithFilter(), and testFlowFileStreamV2()?
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi pull request #905: NIFI-2611: Fixing bugs in UnpackContent with flow fi...
Github user mosermw commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75697333
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -536,7 +541,7 @@ public static PackageFormat getFormat(String textValue)
{
return FLOWFILE_STREAM_FORMAT_V3;
case "flowfile-stream-v2":
return FLOWFILE_STREAM_FORMAT_V2;
-case "flowfile-stream-v1":
+case "flowfile-tar-v1":
--- End diff --
I can't help but hope there is a better way to avoid duplicating these
strings in the code, but it's fine for now.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430969#comment-15430969
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user mosermw commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75697333
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -536,7 +541,7 @@ public static PackageFormat getFormat(String textValue)
{
return FLOWFILE_STREAM_FORMAT_V3;
case "flowfile-stream-v2":
return FLOWFILE_STREAM_FORMAT_V2;
-case "flowfile-stream-v1":
+case "flowfile-tar-v1":
--- End diff --
I can't help but hope there is a better way to avoid duplicating these
strings in the code, but it's fine for now.
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #907: NIFI-2619: Added logic to ClassLoaderUtils to trim module p...
Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/907 @mattyb149 will take a look --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
[
https://issues.apache.org/jira/browse/NIFI-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430990#comment-15430990
]
ASF GitHub Bot commented on NIFI-2605:
--
Github user JPercivall commented on the issue:
https://github.com/apache/nifi/pull/900
Reviewing
> On restart of all nodes in nifi cluster one of the nodes failed to join the
> cluster with fingerprint mismatch
> -
>
> Key: NIFI-2605
> URL: https://issues.apache.org/jira/browse/NIFI-2605
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Follow stack trace was present in the node that did not connect
> {code}
> 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1]
> o.a.n.c.p.impl.SocketProtocolListener Finished processing request
> ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052
> bytes) from host in 61 millis
> 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService
> Failed to load flow from cluster due to:
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866)
> ~[nifi-framework-core-1.0.0.jar:1.0.0]
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492)
> ~[nifi-framework-core-1.0.0.jar:1.0.0]
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746)
> [nifi-jetty-1.0.0.jar:1.0.0]
> at org.apache.nifi.NiFi.(NiFi.java:137)
> [nifi-runtime-1.0.0.jar:1.0.0]
> at org.apache.nifi.NiFi.main(NiFi.java:227)
> [nifi-runtime-1.0.0.jar:1.0.0]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000--
> Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #900: NIFI-2605: Fixing a regression bug where nodes would potent...
Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/900 Reviewing --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430991#comment-15430991
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user mosermw commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75698608
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -182,15 +182,18 @@ public void onStopped() {
public void onScheduled(ProcessContext context) throws
ProcessException {
if (fileFilter == null) {
fileFilter =
Pattern.compile(context.getProperty(FILE_FILTER).getValue());
-tarUnpacker = new TarUnpacker(fileFilter);
-zipUnpacker = new ZipUnpacker(fileFilter);
-flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
-flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
-flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
}
+}
+
+private void initPackagers(ProcessContext context) {
+tarUnpacker = new TarUnpacker(fileFilter);
+zipUnpacker = new ZipUnpacker(fileFilter);
+flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
+flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
+flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
--- End diff --
With this, we will create 5 unpacker objects on each onTrigger(). It works
but it's inefficient and I think there's a better way.
What do you think of avoiding construction of flowFileTarUnpacker or
flowFileStreamV2Unpacker or flowFileStreamV3Unpacker in the onScheduled()
method, but instead construct the appropriate one in the initUnpacker() method?
Inside initUnpacker() the tarUnpacker and zipUnpacker can be reused but
FlowFileStreamUnpacker can be constructed anew.
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2619) ClassLoaderUtils doesn't support spaces between paths or URLs in the paths
[ https://issues.apache.org/jira/browse/NIFI-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430989#comment-15430989 ] ASF GitHub Bot commented on NIFI-2619: -- Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/907 @mattyb149 will take a look > ClassLoaderUtils doesn't support spaces between paths or URLs in the paths > -- > > Key: NIFI-2619 > URL: https://issues.apache.org/jira/browse/NIFI-2619 > Project: Apache NiFi > Issue Type: Bug >Reporter: Matt Burgess >Assignee: Matt Burgess > > ClassLoaderUtils.getCustomClassLoader() splits a module path list on a comma, > but doesn't trim the individual entries. > Also in ClassLoaderUtils.getURLsForClasspath(), it is assumed that the paths > are Files, but they could also already be URLs. Logic should be added to > check if the path is already a valid URL, and add it to the list if so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #905: NIFI-2611: Fixing bugs in UnpackContent with flow fi...
Github user mosermw commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75698608
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -182,15 +182,18 @@ public void onStopped() {
public void onScheduled(ProcessContext context) throws
ProcessException {
if (fileFilter == null) {
fileFilter =
Pattern.compile(context.getProperty(FILE_FILTER).getValue());
-tarUnpacker = new TarUnpacker(fileFilter);
-zipUnpacker = new ZipUnpacker(fileFilter);
-flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
-flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
-flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
}
+}
+
+private void initPackagers(ProcessContext context) {
+tarUnpacker = new TarUnpacker(fileFilter);
+zipUnpacker = new ZipUnpacker(fileFilter);
+flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
+flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
+flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
--- End diff --
With this, we will create 5 unpacker objects on each onTrigger(). It works
but it's inefficient and I think there's a better way.
What do you think of avoiding construction of flowFileTarUnpacker or
flowFileStreamV2Unpacker or flowFileStreamV3Unpacker in the onScheduled()
method, but instead construct the appropriate one in the initUnpacker() method?
Inside initUnpacker() the tarUnpacker and zipUnpacker can be reused but
FlowFileStreamUnpacker can be constructed anew.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Updated] (NIFI-2615) Add support for GetTCP processor
[ https://issues.apache.org/jira/browse/NIFI-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Psaltis updated NIFI-2615: - Description: This processor will allow NiFi to connect to a host via TCP, thus acting as the client and consume data. This should provide the following properties: * Port * Endpoint address * Receive Buffer Size * Keep Alive * Connection Timeout was: This processor will allow NiFi to connect to a host via TCP, thus acting as the client and consume data. This should provide the following properties: * Port * Endpoint address * Disconnect after X messages * Disconnect after X seconds If neither of the "Disconnect" properties are populated then the client will keep the connection open until the processor is stopped. > Add support for GetTCP processor > > > Key: NIFI-2615 > URL: https://issues.apache.org/jira/browse/NIFI-2615 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0, 0.7.0, 0.6.1 >Reporter: Andrew Psaltis >Assignee: Andrew Psaltis > > This processor will allow NiFi to connect to a host via TCP, thus acting as > the client and consume data. This should provide the following properties: > * Port > * Endpoint address > * Receive Buffer Size > * Keep Alive > * Connection Timeout -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
[
https://issues.apache.org/jira/browse/NIFI-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431036#comment-15431036
]
ASF GitHub Bot commented on NIFI-2605:
--
Github user JPercivall commented on a diff in the pull request:
https://github.com/apache/nifi/pull/900#discussion_r75701992
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/test/java/org/apache/nifi/cluster/integration/Node.java
---
@@ -311,6 +320,11 @@ public boolean hasRole(final String roleName) {
return leaderAddress.equals(getClusterAddress());
}
+public void addProcessor(final Processor example) throws
ProcessorInstantiationException {
--- End diff --
Why is there a "addProcessor" method being added Node.java? There aren't
any other "addX" methods and it seems weird to be "adding" it to a node.
> On restart of all nodes in nifi cluster one of the nodes failed to join the
> cluster with fingerprint mismatch
> -
>
> Key: NIFI-2605
> URL: https://issues.apache.org/jira/browse/NIFI-2605
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Follow stack trace was present in the node that did not connect
> {code}
> 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1]
> o.a.n.c.p.impl.SocketProtocolListener Finished processing request
> ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052
> bytes) from host in 61 millis
> 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService
> Failed to load flow from cluster due to:
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866)
> ~[nifi-framework-core-1.0.0.jar:1.0.0]
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492)
> ~[nifi-framework-core-1.0.0.jar:1.0.0]
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746)
> [nifi-jetty-1.0.0.jar:1.0.0]
> at org.apache.nifi.NiFi.(NiFi.java:137)
> [nifi-runtime-1.0.0.jar:1.0.0]
> at org.apache.nifi.NiFi.main(NiFi.java:227)
> [nifi-runtime-1.0.0.jar:1.0.0]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000--
> Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2604) JDBC Connection Pool support for lib directory and expression language
[ https://issues.apache.org/jira/browse/NIFI-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431035#comment-15431035 ] Matt Burgess commented on NIFI-2604: The Database Driver property already accepts expression language statements so we're in good shape there. Proposed solution: Change the "Database Driver Jar Url" property to "Database Driver Location(s)", and accept a comma-separated list of URLs or local files/folders. NOTE: This will invalidate existing processors, but copying the value from the old property to the new property should work. The addition of local files helps the user experience (as many users have local JARs so typing file:/// is often extraneous), and the addition of local folders allows all driver dependencies (and the driver JAR itself) to be specified in a single path in the property (rather than having to list individual JARs). > JDBC Connection Pool support for lib directory and expression language > -- > > Key: NIFI-2604 > URL: https://issues.apache.org/jira/browse/NIFI-2604 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Witt >Assignee: Matt Burgess > > It would be ideal if the JDBC Connection Service supported specifying a > directory instead of particular driver jars. It would also be helpful if it > accepted expression language statements so that it could refer to a location > that is based on variable registry values so it is more portable between > environments. > This stems from a user list thread titled "adding dependencies like jdbc > drivers to the build" on Aug 18 2016 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #900: NIFI-2605: Fixing a regression bug where nodes would...
Github user JPercivall commented on a diff in the pull request:
https://github.com/apache/nifi/pull/900#discussion_r75702141
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/test/java/org/apache/nifi/cluster/integration/Node.java
---
@@ -311,6 +320,11 @@ public boolean hasRole(final String roleName) {
return leaderAddress.equals(getClusterAddress());
}
+public void addProcessor(final Processor example) throws
ProcessorInstantiationException {
--- End diff --
Intellij also says it's not used
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
[
https://issues.apache.org/jira/browse/NIFI-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431037#comment-15431037
]
ASF GitHub Bot commented on NIFI-2605:
--
Github user JPercivall commented on a diff in the pull request:
https://github.com/apache/nifi/pull/900#discussion_r75702141
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/test/java/org/apache/nifi/cluster/integration/Node.java
---
@@ -311,6 +320,11 @@ public boolean hasRole(final String roleName) {
return leaderAddress.equals(getClusterAddress());
}
+public void addProcessor(final Processor example) throws
ProcessorInstantiationException {
--- End diff --
Intellij also says it's not used
> On restart of all nodes in nifi cluster one of the nodes failed to join the
> cluster with fingerprint mismatch
> -
>
> Key: NIFI-2605
> URL: https://issues.apache.org/jira/browse/NIFI-2605
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Arpit Gupta
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Follow stack trace was present in the node that did not connect
> {code}
> 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1]
> o.a.n.c.p.impl.SocketProtocolListener Finished processing request
> ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052
> bytes) from host in 61 millis
> 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService
> Failed to load flow from cluster due to:
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
> to cluster because local flow is different than cluster flow.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866)
> ~[nifi-framework-core-1.0.0.jar:1.0.0]
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492)
> ~[nifi-framework-core-1.0.0.jar:1.0.0]
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746)
> [nifi-jetty-1.0.0.jar:1.0.0]
> at org.apache.nifi.NiFi.(NiFi.java:137)
> [nifi-runtime-1.0.0.jar:1.0.0]
> at org.apache.nifi.NiFi.main(NiFi.java:227)
> [nifi-runtime-1.0.0.jar:1.0.0]
> Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
> configuration is not inheritable by the flow controller because of flow
> differences: Found difference in Flows:
> Local Fingerprint:
> 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000--
> Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431049#comment-15431049
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user gresockj commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75703161
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestUnpackContent.java
---
@@ -199,11 +199,12 @@ public void testFlowFileStreamV3() throws IOException
{
final TestRunner runner = TestRunners.newTestRunner(new
UnpackContent());
runner.setProperty(UnpackContent.PACKAGING_FORMAT,
UnpackContent.PackageFormat.FLOWFILE_STREAM_FORMAT_V3.toString());
runner.enqueue(dataPath.resolve("data.flowfilev3"));
+runner.enqueue(dataPath.resolve("data.flowfilev3"));
-runner.run();
+runner.run(2);
-runner.assertTransferCount(UnpackContent.REL_SUCCESS, 2);
-runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 1);
+runner.assertTransferCount(UnpackContent.REL_SUCCESS, 4);
+runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 2);
--- End diff --
Working on it now
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi pull request #905: NIFI-2611: Fixing bugs in UnpackContent with flow fi...
Github user gresockj commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75703161
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestUnpackContent.java
---
@@ -199,11 +199,12 @@ public void testFlowFileStreamV3() throws IOException
{
final TestRunner runner = TestRunners.newTestRunner(new
UnpackContent());
runner.setProperty(UnpackContent.PACKAGING_FORMAT,
UnpackContent.PackageFormat.FLOWFILE_STREAM_FORMAT_V3.toString());
runner.enqueue(dataPath.resolve("data.flowfilev3"));
+runner.enqueue(dataPath.resolve("data.flowfilev3"));
-runner.run();
+runner.run(2);
-runner.assertTransferCount(UnpackContent.REL_SUCCESS, 2);
-runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 1);
+runner.assertTransferCount(UnpackContent.REL_SUCCESS, 4);
+runner.assertTransferCount(UnpackContent.REL_ORIGINAL, 2);
--- End diff --
Working on it now
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #905: NIFI-2611: Fixing bugs in UnpackContent with flow fi...
Github user gresockj commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75703219
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -536,7 +541,7 @@ public static PackageFormat getFormat(String textValue)
{
return FLOWFILE_STREAM_FORMAT_V3;
case "flowfile-stream-v2":
return FLOWFILE_STREAM_FORMAT_V2;
-case "flowfile-stream-v1":
+case "flowfile-tar-v1":
--- End diff --
I created some constants and used them in both places.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431050#comment-15431050
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user gresockj commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75703219
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -536,7 +541,7 @@ public static PackageFormat getFormat(String textValue)
{
return FLOWFILE_STREAM_FORMAT_V3;
case "flowfile-stream-v2":
return FLOWFILE_STREAM_FORMAT_V2;
-case "flowfile-stream-v1":
+case "flowfile-tar-v1":
--- End diff --
I created some constants and used them in both places.
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi pull request #900: NIFI-2605: Fixing a regression bug where nodes would...
Github user JPercivall commented on a diff in the pull request:
https://github.com/apache/nifi/pull/900#discussion_r75701992
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/test/java/org/apache/nifi/cluster/integration/Node.java
---
@@ -311,6 +320,11 @@ public boolean hasRole(final String roleName) {
return leaderAddress.equals(getClusterAddress());
}
+public void addProcessor(final Processor example) throws
ProcessorInstantiationException {
--- End diff --
Why is there a "addProcessor" method being added Node.java? There aren't
any other "addX" methods and it seems weird to be "adding" it to a node.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2562) PutHDFS writes corrupted data in the transparent disk encryption zone
[ https://issues.apache.org/jira/browse/NIFI-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431052#comment-15431052 ] Vik commented on NIFI-2562: --- Checking in to see, if you can suggest any other workarounds for this issue at this point :) > PutHDFS writes corrupted data in the transparent disk encryption zone > - > > Key: NIFI-2562 > URL: https://issues.apache.org/jira/browse/NIFI-2562 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.0 >Reporter: Vik >Priority: Blocker > Labels: encryption, security > Attachments: HdfsCorrupted.jpg, NiFi-PutHDFS.jpg > > > Problem 1: UnknownHostExcepion > When NiFi is trying to ingest files into HDFS encryption zone, it was > throwing UnknownHostException > Reason: In hadoop Configuration files, like core-site.xml and hdfs-site.xml, > kms hosts were mentioned in the following format "h...@xxx1.int..com; > xxx2.int..com:16000". > Since NiFi was using old hadoop libraries (2.6.2), It could not resolve two > hosts. So instead it considered two hosts as a single host and started > throwing UnknownHostExcepion. > We tried a couple different fixes for this. > Fix 1: Changing configuration files from having property like: >hadoop.security.key.provider.path > kms://h...@.int..com; > .int..com:16000/kms > to: >hadoop.security.key.provider.path > kms://h...@.int..com:16000/kms > > Fix 2: Building NiFi nar files with hadoop version, as installed in our > system. (2.6.0-cdh5.7.0). > Steps followed: > a) Changed NiFi pom file hadoop version from 2.6.2 to 2.6.0-cdh5.7.0. > b) Run mvn clean package -DskipTests > c) Copy following nar files to /opt/nifi-dev/lib > ./nifi-nar-bundles/nifi-hadoop-bundle/nifi-hadoop-nar/target/nifi-hadoop-nar-1.0.0-SNAPSHOT.nar > ./nifi-nar-bundles/nifi-hadoop-libraries-bundle/nifi-hadoop-libraries-nar/target/nifi-hadoop-libraries-nar-1.0.0-SNAPSHOT.nar > ./nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-nar/target/nifi-hbase-nar-1.0.0-SNAPSHOT.nar > ./nifi-nar-bundles/nifi-standard-services/nifi-http-context-map-bundle/nifi-http-context-map-nar/target/nifi-http-context-map-nar-1.0.0-SNAPSHOT.nar > d) Restart NiFi with bin/nifi.sh restart > This fixes resolved the Unknown Host Exception for us but we ran into Problem > 2 mentioned below. > Problem 2: Ingesting Corrupted data into HDFS encryption zone > After resolving the UnknownHostException, NiFi was able to ingest files into > encryption zone but content of the file is corrupted. > Approaches: > Tried to simulate error with sample Java program which uses similar logic and > same library, but it was ingesting files into encryption zone without any > problem. > Checked NiFi log files to find the cause, found NiFi is making HTTP requests > to kms to decrypt keys but could not proceed further as there is no error. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #905: NIFI-2611: Fixing bugs in UnpackContent with flow fi...
Github user gresockj commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75700388
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -182,15 +182,18 @@ public void onStopped() {
public void onScheduled(ProcessContext context) throws
ProcessException {
if (fileFilter == null) {
fileFilter =
Pattern.compile(context.getProperty(FILE_FILTER).getValue());
-tarUnpacker = new TarUnpacker(fileFilter);
-zipUnpacker = new ZipUnpacker(fileFilter);
-flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
-flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
-flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
}
+}
+
+private void initPackagers(ProcessContext context) {
+tarUnpacker = new TarUnpacker(fileFilter);
+zipUnpacker = new ZipUnpacker(fileFilter);
+flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
+flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
+flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
--- End diff --
I like it -- I'll start working on it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-2611) UnpackContent cannot unpack any type of flowfile
[
https://issues.apache.org/jira/browse/NIFI-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431014#comment-15431014
]
ASF GitHub Bot commented on NIFI-2611:
--
Github user gresockj commented on a diff in the pull request:
https://github.com/apache/nifi/pull/905#discussion_r75700388
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/UnpackContent.java
---
@@ -182,15 +182,18 @@ public void onStopped() {
public void onScheduled(ProcessContext context) throws
ProcessException {
if (fileFilter == null) {
fileFilter =
Pattern.compile(context.getProperty(FILE_FILTER).getValue());
-tarUnpacker = new TarUnpacker(fileFilter);
-zipUnpacker = new ZipUnpacker(fileFilter);
-flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
-flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
-flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
}
+}
+
+private void initPackagers(ProcessContext context) {
+tarUnpacker = new TarUnpacker(fileFilter);
+zipUnpacker = new ZipUnpacker(fileFilter);
+flowFileStreamV3Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV3());
+flowFileStreamV2Unpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV2());
+flowFileTarUnpacker = new FlowFileStreamUnpacker(new
FlowFileUnpackagerV1());
--- End diff --
I like it -- I'll start working on it.
> UnpackContent cannot unpack any type of flowfile
>
>
> Key: NIFI-2611
> URL: https://issues.apache.org/jira/browse/NIFI-2611
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.7.0
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>
> Two possibly separate problems:
> *Flowfile-stream-v2 and v3*
> This may be a problem with either MergeContent's production of
> flowfile-stream v2 and v3, or with UnpackContent's inability to unpack them,
> not sure which. Here is a screen shot with how to reproduce it:
> https://ibin.co/2sCwqbFbAs3a.png
> Essentially, when you pack a flow file as flowfile-stream v2 or v3, a
> subsequent UnpackContent set to the respective type fails with the error
> "Cannot unpack {} because it does not appear to have any entries".
> *Flowfile-tar-v1*
> When selecting flowfile-tar-v1 from UnpackContent, you immediately get
> @OnScheduled error failure as soon as you start the processor, which prevents
> it from processing any incoming flow files. Here is a screenshot:
> https://ibin.co/2sCxI4iDm88t.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi pull request #908: Addressing issue when fingerprinting flows with defa...
GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/908 Addressing issue when fingerprinting flows with default values NIFI-2606: - Addressing issue when fingerprinting ReportingTasks and ControllerServices properties with default values. - Ensuring the flow is saved when templates are created and imported. - Ensuring default values are included in templates. - Fixing unit tests. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2606 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/908.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 #908 commit b753b86125531560f21f3332182be804cf940928 Author: Matt Gilman Date: 2016-08-22T15:48:22Z NIFI-2606: - Addressing issue when fingerprinting ReportingTasks and ControllerServices properties with default values. - Ensuring the flow is saved when templates are created and imported. - Ensuring default values are included in templates. - Fixing unit tests. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2606) FingerprintFactory and default property values
[ https://issues.apache.org/jira/browse/NIFI-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431054#comment-15431054 ] ASF GitHub Bot commented on NIFI-2606: -- GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/908 Addressing issue when fingerprinting flows with default values NIFI-2606: - Addressing issue when fingerprinting ReportingTasks and ControllerServices properties with default values. - Ensuring the flow is saved when templates are created and imported. - Ensuring default values are included in templates. - Fixing unit tests. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2606 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/908.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 #908 commit b753b86125531560f21f3332182be804cf940928 Author: Matt Gilman Date: 2016-08-22T15:48:22Z NIFI-2606: - Addressing issue when fingerprinting ReportingTasks and ControllerServices properties with default values. - Ensuring the flow is saved when templates are created and imported. - Ensuring default values are included in templates. - Fixing unit tests. > FingerprintFactory and default property values > -- > > Key: NIFI-2606 > URL: https://issues.apache.org/jira/browse/NIFI-2606 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > When a node joins a cluster, it checks the proposed flow (of the cluster) > against it's local flow. The proposed flow will include default property > values if a property is not explicitly set. This is accounted for when > comparing a Processor but is not for Controller Services and Reporting Tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #896: NIFI-2600: Ensure that we do not close Index Searchers prem...
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/896 +1 LGTM to me, tested with and without fixes, verified problem is resolved. Merging to master, thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2600) Provenance Repository can close Index Reader too soon
[ https://issues.apache.org/jira/browse/NIFI-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431077#comment-15431077 ] ASF GitHub Bot commented on NIFI-2600: -- Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/896 +1 LGTM to me, tested with and without fixes, verified problem is resolved. Merging to master, thanks! > Provenance Repository can close Index Reader too soon > - > > Key: NIFI-2600 > URL: https://issues.apache.org/jira/browse/NIFI-2600 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > In NIFI-2452, we addressed an issue where the Persistent Provenance Repo > closed Index Readers / Index Searchers before they should. I have found > another case in which that can happen. > Using a separate JIRA rather than re-opening the other, since NIFI-2452 has a > fix Version of both 1.0.0-BETA and 1.0.0 and 1.0.0-BETA has already been > released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2600) Provenance Repository can close Index Reader too soon
[ https://issues.apache.org/jira/browse/NIFI-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431079#comment-15431079 ] ASF subversion and git services commented on NIFI-2600: --- Commit 95b5877f5de679da689b76917d93b3ad7fc9b890 in nifi's branch refs/heads/master from [~markap14] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=95b5877 ] NIFI-2600: Ensure that we do not close Index Searchers prematurely, even if they are poisoned This closes #896 > Provenance Repository can close Index Reader too soon > - > > Key: NIFI-2600 > URL: https://issues.apache.org/jira/browse/NIFI-2600 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > In NIFI-2452, we addressed an issue where the Persistent Provenance Repo > closed Index Readers / Index Searchers before they should. I have found > another case in which that can happen. > Using a separate JIRA rather than re-opening the other, since NIFI-2452 has a > fix Version of both 1.0.0-BETA and 1.0.0 and 1.0.0-BETA has already been > released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2600) Provenance Repository can close Index Reader too soon
[ https://issues.apache.org/jira/browse/NIFI-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431085#comment-15431085 ] ASF GitHub Bot commented on NIFI-2600: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/896 > Provenance Repository can close Index Reader too soon > - > > Key: NIFI-2600 > URL: https://issues.apache.org/jira/browse/NIFI-2600 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > In NIFI-2452, we addressed an issue where the Persistent Provenance Repo > closed Index Readers / Index Searchers before they should. I have found > another case in which that can happen. > Using a separate JIRA rather than re-opening the other, since NIFI-2452 has a > fix Version of both 1.0.0-BETA and 1.0.0 and 1.0.0-BETA has already been > released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2600) Provenance Repository can close Index Reader too soon
[ https://issues.apache.org/jira/browse/NIFI-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-2600: - Resolution: Fixed Status: Resolved (was: Patch Available) > Provenance Repository can close Index Reader too soon > - > > Key: NIFI-2600 > URL: https://issues.apache.org/jira/browse/NIFI-2600 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > In NIFI-2452, we addressed an issue where the Persistent Provenance Repo > closed Index Readers / Index Searchers before they should. I have found > another case in which that can happen. > Using a separate JIRA rather than re-opening the other, since NIFI-2452 has a > fix Version of both 1.0.0-BETA and 1.0.0 and 1.0.0-BETA has already been > released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #902: NIFI-2609: Ensure that we handle URIs for Remote Process Gr...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/902 Reviewing --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2609) Issue determining appropriate site to site URL
[ https://issues.apache.org/jira/browse/NIFI-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431089#comment-15431089 ] ASF GitHub Bot commented on NIFI-2609: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/902 Reviewing > Issue determining appropriate site to site URL > -- > > Key: NIFI-2609 > URL: https://issues.apache.org/jira/browse/NIFI-2609 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Mark Payne > Fix For: 1.0.0 > > Attachments: Screen Shot 2016-08-19 at 10.15.49 AM.png > > > NiFi should be more lenient in terms of what URL is entered when creating a > RemoteProcessGroup. The user should be able to enter either > http://: or http://:/nifi without issue. Currently > the former leads to a very confusing error. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #896: NIFI-2600: Ensure that we do not close Index Searche...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/896 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2606) FingerprintFactory and default property values
[ https://issues.apache.org/jira/browse/NIFI-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431086#comment-15431086 ] Mark Payne commented on NIFI-2606: -- Reviewing... > FingerprintFactory and default property values > -- > > Key: NIFI-2606 > URL: https://issues.apache.org/jira/browse/NIFI-2606 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > When a node joins a cluster, it checks the proposed flow (of the cluster) > against it's local flow. The proposed flow will include default property > values if a property is not explicitly set. This is accounted for when > comparing a Processor but is not for Controller Services and Reporting Tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2606) FingerprintFactory and default property values
[ https://issues.apache.org/jira/browse/NIFI-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2606: -- Status: Patch Available (was: In Progress) > FingerprintFactory and default property values > -- > > Key: NIFI-2606 > URL: https://issues.apache.org/jira/browse/NIFI-2606 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > When a node joins a cluster, it checks the proposed flow (of the cluster) > against it's local flow. The proposed flow will include default property > values if a property is not explicitly set. This is accounted for when > comparing a Processor but is not for Controller Services and Reporting Tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2620) Add ability to write Row Identifier as binary in hbase using the PutHbaseCell
Andrew Psaltis created NIFI-2620: Summary: Add ability to write Row Identifier as binary in hbase using the PutHbaseCell Key: NIFI-2620 URL: https://issues.apache.org/jira/browse/NIFI-2620 Project: Apache NiFi Issue Type: Improvement Affects Versions: 0.6.1, 0.7.0, 1.0.0 Reporter: Andrew Psaltis Assignee: Andrew Psaltis Today the PutHBaseCell processor makes the assumption that all row keys are text. However, this does not work when the row key in the HBase table is binary. If the row key is specified in the binary string format, such as: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x01\x01\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x01\x00\x00\x01\x00\x00\x00\x00\x01 \x01\x01\x00\x01\x00\x01\x01\x01\x00\x00\x 00\x00\x00\x00\x01\x01\x01\x01\x00\x00\x00 \x00\x00\x00\x01\x01\x00\x01\x00\x01\x00\x 00\x01\x01\x01\x01\x00\x00\x01\x01\x01\x00 \x01\x00\x00 Which is the textual representation that the HBase CLI would return, NiFi calls getBytes on that string. Appropriately HBase will encode the '\' with the hex code: x5C, resulting in an output string that looks like: x5Cx00\x5Cx00\ ... To address this the proposed solution would be to: * Add "toBytesBinary" method to HBaseClientService similar to the ones already added [1]. * Update the PutFlowFile and PutColumn to pass around mostly byte[] and not strings that they do today. For this JIRA only support for Text and Binary will be added for the RowKey [1] https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-services/nifi-hbase_1_1_2-client-service-bundle/nifi-hbase_1_1_2-client-service/src/main/java/org/apache/nifi/hbase/HBase_1_1_2_ClientService.java#L427 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #903: NIFI-2411 ModifyBytes should use long instead of int...
Github user jskora closed the pull request at: https://github.com/apache/nifi/pull/903 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #903: NIFI-2411 ModifyBytes should use long instead of int for of...
Github user jskora commented on the issue: https://github.com/apache/nifi/pull/903 Merged into 0.x branch on commit https://github.com/apache/nifi/commit/58868abad058c143cfcc2cd9b938df579c72e1aa --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431119#comment-15431119
]
ASF GitHub Bot commented on NIFI-2411:
--
Github user jskora commented on the issue:
https://github.com/apache/nifi/pull/903
Merged into 0.x branch on commit
https://github.com/apache/nifi/commit/58868abad058c143cfcc2cd9b938df579c72e1aa
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431120#comment-15431120
]
ASF GitHub Bot commented on NIFI-2411:
--
Github user jskora closed the pull request at:
https://github.com/apache/nifi/pull/903
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi pull request #904: NIFI-2411 ModifyBytes should use long instead of int...
Github user jskora closed the pull request at: https://github.com/apache/nifi/pull/904 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431125#comment-15431125
]
ASF GitHub Bot commented on NIFI-2411:
--
Github user jskora commented on the issue:
https://github.com/apache/nifi/pull/904
Merged into master on commit
https://github.com/apache/nifi/commit/a2d3d0c2890b8a5a3433017b3077c704583b1277
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #904: NIFI-2411 ModifyBytes should use long instead of int for of...
Github user jskora commented on the issue: https://github.com/apache/nifi/pull/904 Merged into master on commit https://github.com/apache/nifi/commit/a2d3d0c2890b8a5a3433017b3077c704583b1277 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2411) ModifyBytes should use long instead of int for offsets.
[
https://issues.apache.org/jira/browse/NIFI-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431124#comment-15431124
]
ASF GitHub Bot commented on NIFI-2411:
--
Github user jskora closed the pull request at:
https://github.com/apache/nifi/pull/904
> ModifyBytes should use long instead of int for offsets.
> ---
>
> Key: NIFI-2411
> URL: https://issues.apache.org/jira/browse/NIFI-2411
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Joe Skora
>Assignee: Joe Skora
> Labels: easyfix
> Fix For: 1.0.0, 0.8.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> ModifyBytes.onTrigger() uses Java 32 bit {{int}} value for byte offsets
> limiting it to 2 Gigabytes, switching to {{long}} values will allow it to
> handle up to 15 Exabytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] nifi issue #883: NIFI-2591 - PutSQL has no handling for Binary data types
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/883 @mattyb149 Updates are in, take a look when you have a minute. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2591) PutSQL has no handling for Binary data types
[ https://issues.apache.org/jira/browse/NIFI-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431129#comment-15431129 ] ASF GitHub Bot commented on NIFI-2591: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/883 @mattyb149 Updates are in, take a look when you have a minute. > PutSQL has no handling for Binary data types > > > Key: NIFI-2591 > URL: https://issues.apache.org/jira/browse/NIFI-2591 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Peter Wicks > > PutSQL does not call out binary types for any special treatment, so they end > up being routed through stmt.setObject. > The problem is that upstream processors have formatted the binary data as a > string and the JDBC driver doesn't know what to do with a string going into a > binary field. > Investigation into the AvroToJSON processor shows that if users are trying to > load data exported from a source system as Avro Binary that Avro encodes the > binary data into ASCII (One byte per character). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #883: NIFI-2591 - PutSQL has no handling for Binary data types
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/883 Hold on that update.. looks like I got my branches crossed. I'll get it cleaned up. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2591) PutSQL has no handling for Binary data types
[ https://issues.apache.org/jira/browse/NIFI-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431132#comment-15431132 ] ASF GitHub Bot commented on NIFI-2591: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/883 Hold on that update.. looks like I got my branches crossed. I'll get it cleaned up. > PutSQL has no handling for Binary data types > > > Key: NIFI-2591 > URL: https://issues.apache.org/jira/browse/NIFI-2591 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Peter Wicks > > PutSQL does not call out binary types for any special treatment, so they end > up being routed through stmt.setObject. > The problem is that upstream processors have formatted the binary data as a > string and the JDBC driver doesn't know what to do with a string going into a > binary field. > Investigation into the AvroToJSON processor shows that if users are trying to > load data exported from a source system as Avro Binary that Avro encodes the > binary data into ASCII (One byte per character). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2621) NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond
Bryan Rosander created NIFI-2621: Summary: NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond Key: NIFI-2621 URL: https://issues.apache.org/jira/browse/NIFI-2621 Project: Apache NiFi Issue Type: Bug Reporter: Bryan Rosander Assignee: Bryan Rosander Serial numbers on certificates should be unique. CertificateUtils currently uses System.currentTimeMillis() to generate them. Proposed solution: 1. Use the current time in millis as the most significant part of the serial number 2. Shift it left 32 bits to make room in the BigInteger for an incrementor value 3. Reset the incrementor every time a the generator function is called and the millisecond is different from before -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #909: NIFI-2621 - Generating unique serial numbers for cer...
GitHub user brosander opened a pull request: https://github.com/apache/nifi/pull/909 NIFI-2621 - Generating unique serial numbers for certificates You can merge this pull request into a Git repository by running: $ git pull https://github.com/brosander/nifi NIFI-2621 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/909.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 #909 commit 52015e66396a1ac8c58de2c8818a2779754975b0 Author: Bryan Rosander Date: 2016-08-22T16:57:37Z NIFI-2621 - Generating unique serial numbers for certificates --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2621) NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond
[ https://issues.apache.org/jira/browse/NIFI-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431193#comment-15431193 ] ASF GitHub Bot commented on NIFI-2621: -- GitHub user brosander opened a pull request: https://github.com/apache/nifi/pull/909 NIFI-2621 - Generating unique serial numbers for certificates You can merge this pull request into a Git repository by running: $ git pull https://github.com/brosander/nifi NIFI-2621 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/909.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 #909 commit 52015e66396a1ac8c58de2c8818a2779754975b0 Author: Bryan Rosander Date: 2016-08-22T16:57:37Z NIFI-2621 - Generating unique serial numbers for certificates > NiFi CertificateUtils can reuse serial numbers in issued certificates if > multiple calls are made in the same millisecond > > > Key: NIFI-2621 > URL: https://issues.apache.org/jira/browse/NIFI-2621 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > Serial numbers on certificates should be unique. CertificateUtils currently > uses System.currentTimeMillis() to generate them. > Proposed solution: > 1. Use the current time in millis as the most significant part of the serial > number > 2. Shift it left 32 bits to make room in the BigInteger for an incrementor > value > 3. Reset the incrementor every time a the generator function is called and > the millisecond is different from before -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #883: NIFI-2591 - PutSQL has no handling for Binary data types
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/883 OK, good to go. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2621) NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond
[ https://issues.apache.org/jira/browse/NIFI-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431196#comment-15431196 ] Bryan Rosander commented on NIFI-2621: -- The unit test in the PR seems to indicate that this is unlikely to be a performance bottleneck. On my local machine I get the following output: [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 0 executed 46923 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 1 executed 63210 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 2 executed 66038 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 3 executed 79502 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 4 executed 82343 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 5 executed 77983 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 6 executed 70841 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 7 executed 62469 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - Generated 549309 unique serial numbers Meaning that approximately 500 calls per millisecond are going through the unique serial number generator function > NiFi CertificateUtils can reuse serial numbers in issued certificates if > multiple calls are made in the same millisecond > > > Key: NIFI-2621 > URL: https://issues.apache.org/jira/browse/NIFI-2621 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > Serial numbers on certificates should be unique. CertificateUtils currently > uses System.currentTimeMillis() to generate them. > Proposed solution: > 1. Use the current time in millis as the most significant part of the serial > number > 2. Shift it left 32 bits to make room in the BigInteger for an incrementor > value > 3. Reset the incrementor every time a the generator function is called and > the millisecond is different from before -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (NIFI-2621) NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond
[ https://issues.apache.org/jira/browse/NIFI-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431196#comment-15431196 ] Bryan Rosander edited comment on NIFI-2621 at 8/22/16 5:03 PM: --- The unit test in the PR seems to indicate that this is unlikely to be a performance bottleneck. On my local machine I get the following output: [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 0 executed 46923 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 1 executed 63210 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 2 executed 66038 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 3 executed 79502 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 4 executed 82343 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 5 executed 77983 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 6 executed 70841 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 7 executed 62469 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - Generated 549309 unique serial numbers Meaning that approximately 500 calls per millisecond are going through the unique serial number generator function was (Author: bryanrosan...@gmail.com): The unit test in the PR seems to indicate that this is unlikely to be a performance bottleneck. On my local machine I get the following output: [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 0 executed 46923 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 1 executed 63210 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 2 executed 66038 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 3 executed 79502 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 4 executed 82343 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 5 executed 77983 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 6 executed 70841 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 7 executed 62469 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - Generated 549309 unique serial numbers Meaning that approximately 500 calls per millisecond are going through the unique serial number generator function > NiFi CertificateUtils can reuse serial numbers in issued certificates if > multiple calls are made in the same millisecond > > > Key: NIFI-2621 > URL: https://issues.apache.org/jira/browse/NIFI-2621 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > Serial numbers on certificates should be unique. CertificateUtils currently > uses System.currentTimeMillis() to generate them. > Proposed solution: > 1. Use the current time in millis as the most significant part of the serial > number > 2. Shift it left 32 bits to make room in the BigInteger for an incrementor > value > 3. Reset the incrementor every time a the generator function is called and > the millisecond is different from before -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2591) PutSQL has no handling for Binary data types
[ https://issues.apache.org/jira/browse/NIFI-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431199#comment-15431199 ] ASF GitHub Bot commented on NIFI-2591: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/883 OK, good to go. > PutSQL has no handling for Binary data types > > > Key: NIFI-2591 > URL: https://issues.apache.org/jira/browse/NIFI-2591 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Peter Wicks > > PutSQL does not call out binary types for any special treatment, so they end > up being routed through stmt.setObject. > The problem is that upstream processors have formatted the binary data as a > string and the JDBC driver doesn't know what to do with a string going into a > binary field. > Investigation into the AvroToJSON processor shows that if users are trying to > load data exported from a source system as Avro Binary that Avro encodes the > binary data into ASCII (One byte per character). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #906: NIFI-2617: Instead of retrying an infinite number of times ...
Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/906 Ran through several tests with 2 & 3 node cluster. Attempted removal of nodes through disconnecting with UI (cluster did not encounter err) and through shutdown of nodes which should trigger error. Test to shutdown nodes to eliminate quorum for election resulted in logs displaying retry failure and UI displaying expected error notifying failed Cluster Coordinator election. +1 Will have this merged in shortly --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2621) NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond
[ https://issues.apache.org/jira/browse/NIFI-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Rosander updated NIFI-2621: - Description: Serial numbers on certificates should be unique. CertificateUtils currently uses System.currentTimeMillis() to generate them. Proposed solution: 1. Use the current time in millis as the most significant part of the serial number 2. Shift it left 32 bits to make room in the BigInteger for an incrementor value 3. Add the incrementor value to the BigInteger 4. Reset the incrementor every time a the generator function is called and the millisecond is different from before was: Serial numbers on certificates should be unique. CertificateUtils currently uses System.currentTimeMillis() to generate them. Proposed solution: 1. Use the current time in millis as the most significant part of the serial number 2. Shift it left 32 bits to make room in the BigInteger for an incrementor value 3. Reset the incrementor every time a the generator function is called and the millisecond is different from before > NiFi CertificateUtils can reuse serial numbers in issued certificates if > multiple calls are made in the same millisecond > > > Key: NIFI-2621 > URL: https://issues.apache.org/jira/browse/NIFI-2621 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > Serial numbers on certificates should be unique. CertificateUtils currently > uses System.currentTimeMillis() to generate them. > Proposed solution: > 1. Use the current time in millis as the most significant part of the serial > number > 2. Shift it left 32 bits to make room in the BigInteger for an incrementor > value > 3. Add the incrementor value to the BigInteger > 4. Reset the incrementor every time a the generator function is called and > the millisecond is different from before -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431203#comment-15431203 ] ASF GitHub Bot commented on NIFI-2617: -- Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/906 Ran through several tests with 2 & 3 node cluster. Attempted removal of nodes through disconnecting with UI (cluster did not encounter err) and through shutdown of nodes which should trigger error. Test to shutdown nodes to eliminate quorum for election resulted in logs displaying retry failure and UI displaying expected error notifying failed Cluster Coordinator election. +1 Will have this merged in shortly > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (NIFI-2621) NiFi CertificateUtils can reuse serial numbers in issued certificates if multiple calls are made in the same millisecond
[ https://issues.apache.org/jira/browse/NIFI-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431196#comment-15431196 ] Bryan Rosander edited comment on NIFI-2621 at 8/22/16 5:06 PM: --- The unit test in the PR seems to indicate that this is unlikely to be a performance bottleneck. On my local machine I get the following output: [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 0 executed 46923 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 1 executed 63210 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 2 executed 66038 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 3 executed 79502 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 4 executed 82343 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 5 executed 77983 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 6 executed 70841 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 7 executed 62469 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - Generated 549309 unique serial numbers Meaning that somewhere in the neighborhood (there's probably some noise from setup, delay before the thread.sleep but the magnitude should be about right) 500 calls per millisecond are going through the unique serial number generator function was (Author: bryanrosan...@gmail.com): The unit test in the PR seems to indicate that this is unlikely to be a performance bottleneck. On my local machine I get the following output: [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 0 executed 46923 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 1 executed 63210 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 2 executed 66038 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 3 executed 79502 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 4 executed 82343 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 5 executed 77983 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 6 executed 70841 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - future 7 executed 62469 times [main] INFO org.apache.nifi.security.util.CertificateUtilsTest - Generated 549309 unique serial numbers Meaning that approximately 500 calls per millisecond are going through the unique serial number generator function > NiFi CertificateUtils can reuse serial numbers in issued certificates if > multiple calls are made in the same millisecond > > > Key: NIFI-2621 > URL: https://issues.apache.org/jira/browse/NIFI-2621 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > Serial numbers on certificates should be unique. CertificateUtils currently > uses System.currentTimeMillis() to generate them. > Proposed solution: > 1. Use the current time in millis as the most significant part of the serial > number > 2. Shift it left 32 bits to make room in the BigInteger for an incrementor > value > 3. Add the incrementor value to the BigInteger > 4. Reset the incrementor every time a the generator function is called and > the millisecond is different from before -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #902: NIFI-2609: Ensure that we handle URIs for Remote Process Gr...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/902 Looks good, will merge to master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2609) Issue determining appropriate site to site URL
[ https://issues.apache.org/jira/browse/NIFI-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431221#comment-15431221 ] ASF GitHub Bot commented on NIFI-2609: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/902 Looks good, will merge to master. > Issue determining appropriate site to site URL > -- > > Key: NIFI-2609 > URL: https://issues.apache.org/jira/browse/NIFI-2609 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Mark Payne > Fix For: 1.0.0 > > Attachments: Screen Shot 2016-08-19 at 10.15.49 AM.png > > > NiFi should be more lenient in terms of what URL is entered when creating a > RemoteProcessGroup. The user should be able to enter either > http://: or http://:/nifi without issue. Currently > the former leads to a very confusing error. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #902: NIFI-2609: Ensure that we handle URIs for Remote Pro...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/902 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2609) Issue determining appropriate site to site URL
[ https://issues.apache.org/jira/browse/NIFI-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431222#comment-15431222 ] ASF subversion and git services commented on NIFI-2609: --- Commit 5fab783b50e56811cd4a51fd8cf2063da9517ec5 in nifi's branch refs/heads/master from [~markap14] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=5fab783 ] NIFI-2609: Ensure that we handle URIs for Remote Process Groups that do not have a path of /nifi or /nifi/ This closes #902. Signed-off-by: Bryan Bende > Issue determining appropriate site to site URL > -- > > Key: NIFI-2609 > URL: https://issues.apache.org/jira/browse/NIFI-2609 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Mark Payne > Fix For: 1.0.0 > > Attachments: Screen Shot 2016-08-19 at 10.15.49 AM.png > > > NiFi should be more lenient in terms of what URL is entered when creating a > RemoteProcessGroup. The user should be able to enter either > http://: or http://:/nifi without issue. Currently > the former leads to a very confusing error. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2609) Issue determining appropriate site to site URL
[ https://issues.apache.org/jira/browse/NIFI-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-2609: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Issue determining appropriate site to site URL > -- > > Key: NIFI-2609 > URL: https://issues.apache.org/jira/browse/NIFI-2609 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Mark Payne > Fix For: 1.0.0 > > Attachments: Screen Shot 2016-08-19 at 10.15.49 AM.png > > > NiFi should be more lenient in terms of what URL is entered when creating a > RemoteProcessGroup. The user should be able to enter either > http://: or http://:/nifi without issue. Currently > the former leads to a very confusing error. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2609) Issue determining appropriate site to site URL
[ https://issues.apache.org/jira/browse/NIFI-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431223#comment-15431223 ] ASF GitHub Bot commented on NIFI-2609: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/902 > Issue determining appropriate site to site URL > -- > > Key: NIFI-2609 > URL: https://issues.apache.org/jira/browse/NIFI-2609 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Mark Payne > Fix For: 1.0.0 > > Attachments: Screen Shot 2016-08-19 at 10.15.49 AM.png > > > NiFi should be more lenient in terms of what URL is entered when creating a > RemoteProcessGroup. The user should be able to enter either > http://: or http://:/nifi without issue. Currently > the former leads to a very confusing error. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #906: NIFI-2617: Instead of retrying an infinite number of...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/906 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431229#comment-15431229 ] ASF GitHub Bot commented on NIFI-2617: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/906 > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431228#comment-15431228 ] ASF subversion and git services commented on NIFI-2617: --- Commit 1fcec3747bf88d4d136cbe46e02c0f3b2677b37a in nifi's branch refs/heads/master from [~markap14] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=1fcec37 ] NIFI-2617: Instead of retrying an infinite number of times to communicate with ZooKeeper, should try only for a short period in CuratorLeaderElectionManager. This is because web requests may be blocked waiting on a determination of which node is cluster coordinator Signed-off-by: Yolanda M. Davis This closes #906 > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2617) If no ZooKeeper quorum, NiFi does not respond to some web requests
[ https://issues.apache.org/jira/browse/NIFI-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yolanda M. Davis updated NIFI-2617: --- Resolution: Resolved Status: Resolved (was: Patch Available) > If no ZooKeeper quorum, NiFi does not respond to some web requests > -- > > Key: NIFI-2617 > URL: https://issues.apache.org/jira/browse/NIFI-2617 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne > Fix For: 1.0.0 > > > If I lose a ZooKeeper quorum, some web requests never return from NiFi, > regardless of how long I wait. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #908: Addressing issue when fingerprinting flows with defa...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/908 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #908: Addressing issue when fingerprinting flows with default val...
Github user markap14 commented on the issue: https://github.com/apache/nifi/pull/908 Code looks good. Tested that the issue is addressed and that we are still able to import and use template generated in 0.x. +1 merged to master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2606) FingerprintFactory and default property values
[ https://issues.apache.org/jira/browse/NIFI-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431244#comment-15431244 ] ASF GitHub Bot commented on NIFI-2606: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/908 > FingerprintFactory and default property values > -- > > Key: NIFI-2606 > URL: https://issues.apache.org/jira/browse/NIFI-2606 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > When a node joins a cluster, it checks the proposed flow (of the cluster) > against it's local flow. The proposed flow will include default property > values if a property is not explicitly set. This is accounted for when > comparing a Processor but is not for Controller Services and Reporting Tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2606) FingerprintFactory and default property values
[ https://issues.apache.org/jira/browse/NIFI-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431241#comment-15431241 ] ASF subversion and git services commented on NIFI-2606: --- Commit 087622eadc5863cfce615dd22dc5584639146e4a in nifi's branch refs/heads/master from [~mcgilman] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=087622e ] NIFI-2606: - Addressing issue when fingerprinting ReportingTasks and ControllerServices properties with default values. - Ensuring the flow is saved when templates are created and imported. - Ensuring default values are included in templates. - Fixing unit tests. This closes #908. > FingerprintFactory and default property values > -- > > Key: NIFI-2606 > URL: https://issues.apache.org/jira/browse/NIFI-2606 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > When a node joins a cluster, it checks the proposed flow (of the cluster) > against it's local flow. The proposed flow will include default property > values if a property is not explicitly set. This is accounted for when > comparing a Processor but is not for Controller Services and Reporting Tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2606) FingerprintFactory and default property values
[ https://issues.apache.org/jira/browse/NIFI-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-2606: - Resolution: Fixed Status: Resolved (was: Patch Available) > FingerprintFactory and default property values > -- > > Key: NIFI-2606 > URL: https://issues.apache.org/jira/browse/NIFI-2606 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.0.0 > > > When a node joins a cluster, it checks the proposed flow (of the cluster) > against it's local flow. The proposed flow will include default property > values if a property is not explicitly set. This is accounted for when > comparing a Processor but is not for Controller Services and Reporting Tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
