[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [Fix bug pull request|https://github.com/apache/nifi/pull/3551] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [Fix bug pull request|https://github.com/apache/nifi/pull/3550] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > Time Spent: 1h > Remaining Estimate: 0h > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [Fix bug pull request|https://github.com/apache/nifi/pull/3551] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] ivan1221 commented on issue #3551: NIFI-6395: Thread-safety bug fixed and added new flag property to han…
ivan1221 commented on issue #3551: NIFI-6395: Thread-safety bug fixed and added new flag property to han… URL: https://github.com/apache/nifi/pull/3551#issuecomment-505721119 This fixes a bug in the countText processor and adds a new property to handle the way to adjust the counters. PR: NIFI-6395 https://issues.apache.org/jira/browse/NIFI-6395 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] ivan1221 opened a new pull request #3551: NIFI-6395: Thread-safety bug fixed and added new flag property to han…
ivan1221 opened a new pull request #3551: NIFI-6395: Thread-safety bug fixed
and added new flag property to han…
URL: https://github.com/apache/nifi/pull/3551
…dle the way to adjust the counters
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug NIFI-._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `master`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] ivan1221 closed pull request #3550: NIFI-6395: Thread-safety bug fixed, new flag property to handle the w…
ivan1221 closed pull request #3550: NIFI-6395: Thread-safety bug fixed, new flag property to handle the w… URL: https://github.com/apache/nifi/pull/3550 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [Fix bug pull request|https://github.com/apache/nifi/pull/3550] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [Fix bug pull request|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > Time Spent: 0.5h > Remaining Estimate: 0h > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [Fix bug pull request|https://github.com/apache/nifi/pull/3550] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Comment: was deleted (was: [https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a|http://example.com]) > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > Time Spent: 0.5h > Remaining Estimate: 0h > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [Fix bug pull request|https://github.com/apache/nifi/pull/3550] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Status: Patch Available (was: Open) > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > Time Spent: 0.5h > Remaining Estimate: 0h > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [Fix bug pull > request|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] ivan1221 commented on issue #3550: NIFI-6395: Thread-safety bug fixed, new flag property to handle the w…
ivan1221 commented on issue #3550: NIFI-6395: Thread-safety bug fixed, new flag property to handle the w… URL: https://github.com/apache/nifi/pull/3550#issuecomment-505714305 This fixes a bug in the countText processor and adds a new property to handle the way to adjust the counters. PR: NIFI-6395 https://issues.apache.org/jira/browse/NIFI-6395 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] ivan1221 opened a new pull request #3550: NIFI-6395: Thread-safety bug fixed, new flag property to handle the w…
ivan1221 opened a new pull request #3550: NIFI-6395: Thread-safety bug fixed,
new flag property to handle the w…
URL: https://github.com/apache/nifi/pull/3550
…ay to adjust the counters
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug NIFI-._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `master`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] ivan1221 closed pull request #3549: NIFI-6395: Thread-safety bug fixed, new flag property to handle the way to adjus…
ivan1221 closed pull request #3549: NIFI-6395: Thread-safety bug fixed, new flag property to handle the way to adjus… URL: https://github.com/apache/nifi/pull/3549 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] ivan1221 commented on issue #3549: Thread-safety bug fixed, new flag property to handle the way to adjus…
ivan1221 commented on issue #3549: Thread-safety bug fixed, new flag property to handle the way to adjus… URL: https://github.com/apache/nifi/pull/3549#issuecomment-505699587 Jira: PR: NIFI-6395 https://issues.apache.org/jira/browse/NIFI-6395 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Status: Open (was: Patch Available) > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [Fix bug pull > request|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [Fix bug pull request|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [FIX BUG HERE|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [Fix bug pull > request|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. I propose the following solution: [FIX BUG HERE|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. [FIX BUG HERE|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > I propose the following solution: > [FIX BUG > HERE|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. FIX: [FIX|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. FIX: [https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a|http://example.com] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > FIX: > [FIX|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. [FIX|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. FIX: [FIX|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > [FIX|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. [FIX BUG HERE|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. [FIX|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > [FIX BUG > HERE|https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Description: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. FIX: [https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a|http://example.com] was: The processor counters fail to execute multiple threads. The programming is not safe since they are not atomic operations. They are using a volatile instance variable accessed by multiple threads when onTrigger is called. The solution is to declare those local variables to onTrigger. Perform several tests with millions of records and the counter does not work correctly when it is executed with more than one task. The problem is in the declaration of these instance variables: private *volatile int* lineCount; private *volatile int* lineNonEmptyCount; private *volatile int* wordCount; private *volatile int* characterCount; This is not safe to perform atomic operations on these variables. As a result the counters register less amount of lines when executed with multiple threads. > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. > FIX: > [https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a|http://example.com] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-6395) CountText processor is not thread safe - concurrency error
[ https://issues.apache.org/jira/browse/NIFI-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván Ezequiel Rodriguez updated NIFI-6395: -- Status: Patch Available (was: Open) [https://github.com/apache/nifi/pull/3549/commits/86c6ef7ce84089055f26aca68ea996c6735f7c0a|http://example.com] > CountText processor is not thread safe - concurrency error > -- > > Key: NIFI-6395 > URL: https://issues.apache.org/jira/browse/NIFI-6395 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.9.2 > Environment: software platform >Reporter: Iván Ezequiel Rodriguez >Priority: Major > Labels: concurrency, count, error, processor, text, thread-safe > > The processor counters fail to execute multiple threads. The programming is > not safe since they are not atomic operations. They are using a volatile > instance variable accessed by multiple threads when onTrigger is called. The > solution is to declare those local variables to onTrigger. Perform several > tests with millions of records and the counter does not work correctly when > it is executed with more than one task. > The problem is in the declaration of these instance variables: > private *volatile int* lineCount; > private *volatile int* lineNonEmptyCount; > private *volatile int* wordCount; > private *volatile int* characterCount; > This is not safe to perform atomic operations on these variables. As a result > the counters register less amount of lines when executed with multiple > threads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] ivan1221 commented on issue #3549: Thread-safety bug fixed, new flag property to handle the way to adjus…
ivan1221 commented on issue #3549: Thread-safety bug fixed, new flag property to handle the way to adjus… URL: https://github.com/apache/nifi/pull/3549#issuecomment-505695541 this fixes a bug in the countText processor and adds a new property to handle the way to adjust the counters This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] ivan1221 opened a new pull request #3549: Thread-safety bug fixed, new flag property to handle the way to adjus…
ivan1221 opened a new pull request #3549: Thread-safety bug fixed, new flag
property to handle the way to adjus…
URL: https://github.com/apache/nifi/pull/3549
…t the counters
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug NIFI-._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `master`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297456028
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-security/src/main/java/org/apache/nifi/web/security/spring/LoginIdentityProviderFactoryBean.java
##
@@ -219,16 +217,14 @@ private LoginIdentityProviderConfigurationContext
loadLoginIdentityProviderConfi
}
private String decryptValue(String cipherText, String encryptionScheme)
throws SensitivePropertyProtectionException {
-initializeSensitivePropertyProvider(encryptionScheme);
+initializeSensitivePropertyProvider(encryptionScheme);
return SENSITIVE_PROPERTY_PROVIDER.unprotect(cipherText);
}
private static void initializeSensitivePropertyProvider(String
encryptionScheme) throws SensitivePropertyProtectionException {
-if (SENSITIVE_PROPERTY_PROVIDER == null ||
!SENSITIVE_PROPERTY_PROVIDER.getIdentifierKey().equalsIgnoreCase(encryptionScheme))
{
+if (SENSITIVE_PROPERTY_PROVIDER == null) {
try {
-String keyHex = getMasterKey();
-SENSITIVE_PROPERTY_PROVIDER_FACTORY = new
AESSensitivePropertyProviderFactory(keyHex);
-SENSITIVE_PROPERTY_PROVIDER =
SENSITIVE_PROPERTY_PROVIDER_FACTORY.getProvider();
+SENSITIVE_PROPERTY_PROVIDER =
StandardSensitivePropertyProvider.fromKey(getMasterKey(), encryptionScheme);
Review comment:
I think we should add this type of test, but I'm not sure how to expose the
AWS test classes across packages. I'll open the a ticket to track this for now.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] ijokarumawak commented on a change in pull request #3541: NIFI-6387 Implemented RetryFlowFile
ijokarumawak commented on a change in pull request #3541: NIFI-6387 Implemented
RetryFlowFile
URL: https://github.com/apache/nifi/pull/3541#discussion_r297453127
##
File path:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RetryFlowFile.java
##
@@ -0,0 +1,225 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.annotation.behavior.DynamicProperty;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.ReadsAttribute;
+import org.apache.nifi.annotation.behavior.SideEffectFree;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.configuration.DefaultSettings;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.expression.ExpressionLanguageScope;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+@Tags({"Retry", "FlowFile"})
+@CapabilityDescription("FlowFiles passed to this Processor have a 'Retry
Attribute' value checked against a " +
+"configured 'Maximum Retries' value. If the current attribute value is
below the configured maximum, the " +
+"FlowFile is passed to a retry relationship. The FlowFile may or may
not be penalized in that condition. " +
+"If the FlowFile's attribute value exceeds the configured maximum, the
FlowFile will be passed to a " +
+"'retries_exceeded' relationship. WARNING: If the incoming FlowFile
has a non-numeric value in the " +
+"configured 'Retry Attribute' attribute, it will be reset to '1'. You
may choose to fail the FlowFile " +
+"instead of performing the reset. Additional dynamic properties can be
defined for any attributes you " +
+"wish to add to the FlowFiles transferred to 'retries_exceeded'. These
attributes support attribute " +
+"expression language.")
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@SupportsBatching
+@SideEffectFree
+@DefaultSettings(penaltyDuration = "2 min")
+@ReadsAttribute(attribute = "Retry Attribute",
+description = "Will read the attribute or attribute expression
language result as defined in 'Retry Attribute'")
+@WritesAttribute(attribute = "Retry Attribute",
+description = "User defined retry attribute is updated with the
current retry count")
+@DynamicProperty(name = "Exceeded FlowFile Attribute Key",
+value = "The value of the attribute added to the FlowFile",
+description = "One or more dynamic properties can be used to add
attributes to FlowFiles passed to " +
+"the 'retries_exceeded' relationship",
+expressionLanguageScope = ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+public class RetryFlowFile extends AbstractProcessor {
+private List properties;
+private Set relationships;
+private String retryAttribute;
+private Integer maximumRetries;
+private Boolean penalizeRetried;
+private Boolean failOnOverwrite;
+
+public static final PropertyDescriptor RETRY_ATTRIBUTE = new
PropertyDescriptor.Builder()
+.name("Retry Attribute")
+.description("The name of the attribute that contains the current
retry count for the FlowFile. " +
+"WARNING: If the name matches an attribute already on the
FlowFile
[GitHub] [nifi] ijokarumawak commented on a change in pull request #3541: NIFI-6387 Implemented RetryFlowFile
ijokarumawak commented on a change in pull request #3541: NIFI-6387 Implemented
RetryFlowFile
URL: https://github.com/apache/nifi/pull/3541#discussion_r297453014
##
File path:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RetryFlowFile.java
##
@@ -0,0 +1,225 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.annotation.behavior.DynamicProperty;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.ReadsAttribute;
+import org.apache.nifi.annotation.behavior.SideEffectFree;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.configuration.DefaultSettings;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.expression.ExpressionLanguageScope;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+@Tags({"Retry", "FlowFile"})
Review comment:
I don't have strong opinion on this actually, and there's no convention I'm
aware of. Just felt that tagging with "FlowFile" may not help characterizing
the processor or distinguishing it from others. I'll follow your decision :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297412191 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/nifi-groovyx-processors/pom.xml ## @@ -38,8 +38,11 @@ org.codehaus.groovy -groovy-all -2.4.12 +groovy-json + + Review comment: I think the best way to handle these dependencies is to list the needed dependencies necessary to compile the modules in the `nifi-groovyx/scripting-processors` POMs as `compile` scope, so that the build and tests will work. In the NARs' POMs all Groovy sub-modules brought in previously by `groovy-all` would be listed so they're available on the classpath via the NarClassLoader. This will keep the `nifi-groovyx/scripting-processors` compile and test phase dependencies minimal, but enable the processor to use the other Groovy sub-modules at runtime. I'll push an update with these changes by tomorrow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MINIFICPP-810) add docker verify to travis
[ https://issues.apache.org/jira/browse/MINIFICPP-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872760#comment-16872760 ] Mr TheSegfault commented on MINIFICPP-810: -- [~bakaid] I unassigned this to give someone else a chance to take a peek since this has proved instrumental time and time again. By no means does that mean you aren't welcome to tackle it if you have time. Thanks! > add docker verify to travis > --- > > Key: MINIFICPP-810 > URL: https://issues.apache.org/jira/browse/MINIFICPP-810 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-933) Raw site to site TLS bug went unnoticed in 0.6.0
[ https://issues.apache.org/jira/browse/MINIFICPP-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-933: - Summary: Raw site to site TLS bug went unnoticed in 0.6.0 (was: TLS bug went unnoticed) > Raw site to site TLS bug went unnoticed in 0.6.0 > > > Key: MINIFICPP-933 > URL: https://issues.apache.org/jira/browse/MINIFICPP-933 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.6.0, 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > TLS bug went unnoticed until we introduced jemalloc found while running > jemalloc stats and running windows tests. unit tests do not cause the problem > generally but jemalloc and valgrind show the issue pretty easily. HTTP site > to site isn't impacted, only Raw Site To Site. Because this is a memory issue > it doesn't always fail but the error is clearly there in the code. > The initial problem first identified through building windows tests for > MINIFICPP-796; however docker tests proved instrumental in finding it. I > confirmed on a running instance. HTTP site to site does not use this code > path, so it is not impacted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-933) TLS bug went unnoticed
[ https://issues.apache.org/jira/browse/MINIFICPP-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-933: - Description: TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem generally but jemalloc and valgrind show the issue pretty easily. HTTP site to site isn't impacted, only Raw Site To Site. Because this is a memory issue it doesn't always fail but the error is clearly there in the code. The initial problem first identified through building windows tests for MINIFICPP-796; however docker tests proved instrumental in finding it. I confirmed on a running instance. HTTP site to site does not use this code path, so it is not impacted. was: TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem generally but jemalloc and valgrind show the issue pretty easily. HTTP site to site isn't impacted, only Raw Site To Site. This was first identified through running docker tests, then confirmed on a running instance. HTTP site to site does not use this code path, so it is not impacted. > TLS bug went unnoticed > -- > > Key: MINIFICPP-933 > URL: https://issues.apache.org/jira/browse/MINIFICPP-933 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.6.0, 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > TLS bug went unnoticed until we introduced jemalloc found while running > jemalloc stats and running windows tests. unit tests do not cause the problem > generally but jemalloc and valgrind show the issue pretty easily. HTTP site > to site isn't impacted, only Raw Site To Site. Because this is a memory issue > it doesn't always fail but the error is clearly there in the code. > The initial problem first identified through building windows tests for > MINIFICPP-796; however docker tests proved instrumental in finding it. I > confirmed on a running instance. HTTP site to site does not use this code > path, so it is not impacted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-810) add docker verify to travis
[ https://issues.apache.org/jira/browse/MINIFICPP-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872756#comment-16872756 ] Mr TheSegfault commented on MINIFICPP-810: -- Ensure we add test https back into the fray. . > add docker verify to travis > --- > > Key: MINIFICPP-810 > URL: https://issues.apache.org/jira/browse/MINIFICPP-810 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297412191 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/nifi-groovyx-processors/pom.xml ## @@ -38,8 +38,11 @@ org.codehaus.groovy -groovy-all -2.4.12 +groovy-json + + Review comment: I think the best way to handle these dependencies is to list the needed deps necessary to compile the modules in the `nifi-*-processors` POMs as `compile` scope, so that the build and tests will work. In the NARs' POMs all groovy sub-modules brought in previously by `groovy-all` would be listed so they're available on the classpath via the NarClassLoader. This will keep the `nifi-*-processors` compile and test phase dependencies minimal, but enable the processor to use the other Groovy sub-modules at runtime. I'll push an update with these changes by tomorrow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (MINIFICPP-810) add docker verify to travis
[ https://issues.apache.org/jira/browse/MINIFICPP-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault reassigned MINIFICPP-810: Assignee: (was: Daniel Bakai) > add docker verify to travis > --- > > Key: MINIFICPP-810 > URL: https://issues.apache.org/jira/browse/MINIFICPP-810 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-933) TLS bug went unnoticed
[ https://issues.apache.org/jira/browse/MINIFICPP-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-933: - Description: TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem generally but jemalloc and valgrind show the issue pretty easily. HTTP site to site isn't impacted, only Raw Site To Site. This was first identified through running docker tests, then confirmed on a running instance. HTTP site to site does not use this code path, so it is not impacted. was:TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem generally but jemalloc and valgrind show the issue pretty easily. HTTP site to site isn't impacted, only Raw Site To Site. > TLS bug went unnoticed > -- > > Key: MINIFICPP-933 > URL: https://issues.apache.org/jira/browse/MINIFICPP-933 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.6.0, 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > TLS bug went unnoticed until we introduced jemalloc found while running > jemalloc stats and running windows tests. unit tests do not cause the problem > generally but jemalloc and valgrind show the issue pretty easily. HTTP site > to site isn't impacted, only Raw Site To Site. > > This was first identified through running docker tests, then confirmed on a > running instance. HTTP site to site does not use this code path, so it is not > impacted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297408746 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/nifi-groovyx-processors/pom.xml ## @@ -38,8 +38,11 @@ org.codehaus.groovy -groovy-all -2.4.12 +groovy-json + + Review comment: Most likely, all of the modules brought in by `groovy-all` will be included here. To pare down the default modules, I agree; I think we'll have to wait until NiFi 2.0. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297408246 ## File path: nifi-nar-bundles/nifi-scripting-bundle/pom.xml ## @@ -67,15 +67,27 @@ 1.10.0-SNAPSHOT provided + org.codehaus.groovy -groovy-all -2.4.15 - +groovy-json +2.5.4 +compile + + Review comment: Similar to the `nifi-groovyx-bundle` and `nifi-groovyx-processors` concerns, `nifi-scripting-bundle` and `nifi-scripting-processors` will be kept in sync regarding the inclusion of other modules that were included when `groovy-all` was used. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MINIFICPP-933) TLS bug went unnoticed
[ https://issues.apache.org/jira/browse/MINIFICPP-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-933: - Description: TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem generally but jemalloc and valgrind show the issue pretty easily. HTTP site to site isn't impacted, only Raw Site To Site. (was: TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem) > TLS bug went unnoticed > -- > > Key: MINIFICPP-933 > URL: https://issues.apache.org/jira/browse/MINIFICPP-933 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.6.0, 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > TLS bug went unnoticed until we introduced jemalloc found while running > jemalloc stats and running windows tests. unit tests do not cause the problem > generally but jemalloc and valgrind show the issue pretty easily. HTTP site > to site isn't impacted, only Raw Site To Site. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] phrocker opened a new pull request #597: MINIFICPP-933: Fix raw site to site with secure comms
phrocker opened a new pull request #597: MINIFICPP-933: Fix raw site to site with secure comms URL: https://github.com/apache/nifi-minifi-cpp/pull/597 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MINIFICPP-933) TLS bug went unnoticed
[ https://issues.apache.org/jira/browse/MINIFICPP-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-933: - Description: TLS bug went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem (was: TLS bug introduced in late 0.6.0 went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem) > TLS bug went unnoticed > -- > > Key: MINIFICPP-933 > URL: https://issues.apache.org/jira/browse/MINIFICPP-933 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.6.0, 0.7.0 > > > TLS bug went unnoticed until we introduced jemalloc found while running > jemalloc stats and running windows tests. unit tests do not cause the problem -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-933) TLS bug went unnoticed
[ https://issues.apache.org/jira/browse/MINIFICPP-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-933: - Summary: TLS bug went unnoticed (was: TLS bug introduced in late 0.6.0 went unnoticed) > TLS bug went unnoticed > -- > > Key: MINIFICPP-933 > URL: https://issues.apache.org/jira/browse/MINIFICPP-933 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.6.0, 0.7.0 > > > TLS bug introduced in late 0.6.0 went unnoticed until we introduced jemalloc > found while running jemalloc stats and running windows tests. unit tests do > not cause the problem -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297401925
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-properties-loader/src/main/java/org/apache/nifi/properties/sensitive/ProtectedNiFiProperties.java
##
@@ -510,22 +448,21 @@ private boolean isProviderAvailable(String
protectionScheme) {
*/
private String unprotectValue(String key, String retrievedValue) {
// Checks if the key is sensitive and marked as protected
-if (isPropertyProtected(key)) {
-final String protectionScheme = getProperty(getProtectionKey(key));
+if (!isPropertyProtected(key)) {
+return retrievedValue;
+}
+final String protectionScheme = getProperty(getProtectionKey(key));
-// No provider registered for this scheme, so just return the value
-if (!isProviderAvailable(protectionScheme)) {
-logger.warn("No provider available for {} so passing the
protected {} value back", protectionScheme, key);
-return retrievedValue;
-}
+if (protectionScheme.equals("unknown")) {
+return retrievedValue;
+}
-try {
-SensitivePropertyProvider sensitivePropertyProvider =
getSensitivePropertyProvider(protectionScheme);
-return sensitivePropertyProvider.unprotect(retrievedValue);
-} catch (SensitivePropertyProtectionException e) {
-throw new SensitivePropertyProtectionException("Error
unprotecting value for " + key, e.getCause());
-}
+// try and make one to unprotect, and if that fails...
Review comment:
Added static method
`StandardSensitivePropertyProvider#hasProviderFor(scheme)`, updated this call,
and added logging at this call site.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Created] (MINIFICPP-933) TLS bug introduced in late 0.6.0 went unnoticed
Mr TheSegfault created MINIFICPP-933: Summary: TLS bug introduced in late 0.6.0 went unnoticed Key: MINIFICPP-933 URL: https://issues.apache.org/jira/browse/MINIFICPP-933 Project: Apache NiFi MiNiFi C++ Issue Type: Bug Reporter: Mr TheSegfault Assignee: Mr TheSegfault Fix For: 0.7.0, 0.6.0 TLS bug introduced in late 0.6.0 went unnoticed until we introduced jemalloc found while running jemalloc stats and running windows tests. unit tests do not cause the problem -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] MikeThomsen commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
MikeThomsen commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297400372 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/nifi-groovyx-processors/pom.xml ## @@ -38,8 +38,11 @@ org.codehaus.groovy -groovy-all -2.4.12 +groovy-json + + Review comment: Depending on the module, I think that falls within the scope of our general policy against breaking compatibility on processor functionality abruptly. It's one thing to drop groovy-ant or something like that from groovy-all, but I think we might really inconvenience people who use some of the modules I mentioned. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297397950 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/pom.xml ## @@ -39,8 +39,14 @@ org.codehaus.groovy -groovy-all -2.4.11 +groovy-json Review comment: Changes to `nifi-groovyx-bundle/pom.xml` will be kept in sync with the decision regarding [this comment](https://github.com/apache/nifi/pull/3547#discussion_r297397319). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297397319 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/nifi-groovyx-processors/pom.xml ## @@ -38,8 +38,11 @@ org.codehaus.groovy -groovy-all -2.4.12 +groovy-json + + Review comment: `groovy-json` is already a compile-scoped dependency. Since the current version of `nifi-groovyx-processors` establishes a dependency on `groovy-all`, I'm tempted to list all of groovy's sub-modules in the pom to maintain compatibility with existing flows that use these processors. The other option is to mention in the migration notes, for the version in which this change is released, that the user should add the groovy submodules needed via the `Additional classpath` property of the `ExecuteGroovyScript` processor configuration. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
jtstorck commented on a change in pull request #3547: [WIP] NIFI-5254 Update
Groovy dependecies to version 2.5.4
URL: https://github.com/apache/nifi/pull/3547#discussion_r297391018
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-properties-loader/src/test/groovy/org/apache/nifi/properties/AESSensitivePropertyProviderTest.groovy
##
@@ -86,7 +86,7 @@ class AESSensitivePropertyProviderTest extends
GroovyTestCase {
if (Cipher.getMaxAllowedKeyLength("AES") < keySize) {
throw new IllegalArgumentException("The JCE unlimited
strength cryptographic jurisdiction policies are not installed, so the max key
size is 128 bits")
}
-return KEY_256_HEX[0..<(keySize / 4)]
+return KEY_256_HEX[0..
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297380497 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/pom.xml ## @@ -0,0 +1,40 @@ + + +http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> +4.0.0 + + +org.apache.nifi +nifi-nar-bundles +1.6.0 Review comment: Same here for version `1.10.0-SNAPSHOT` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a
Processor to write the contents of a FlowFile to OpenTSDB
URL: https://github.com/apache/nifi/pull/2635#discussion_r297380206
##
File path:
nifi-nar-bundles/nifi-opentsdb-bundle/nifi-opentsdb-processors/src/main/java/org/apache/nifi/processors/opentsdb/PutOpenTSDBHttp.java
##
@@ -0,0 +1,183 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.opentsdb;
+
+import com.alibaba.fastjson.JSONArray;
+import com.alibaba.fastjson.JSONObject;
+import okhttp3.*;
+import org.apache.commons.io.IOUtils;
+import org.apache.nifi.annotation.behavior.EventDriven;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processors.AbstractOkHttpProcessor;
+
+import java.io.IOException;
+import java.net.MalformedURLException;
+import java.net.URL;
+import java.util.*;
+
+import static org.apache.commons.lang3.StringUtils.trimToEmpty;
+
+
+/**
+ * Description: Put OpenTSDB Http
+ *
+ * @author bright
+ */
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@EventDriven
+@Tags({"OpenTSDB", "put", "http"})
Review comment:
Maybe add `timeseries` or something as tag(s)?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297377981 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/.gitignore ## @@ -0,0 +1,22 @@ +# Mac Review comment: I'm not sure we want to track this file, there's a top-level `.gitignore` that should suffice. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297379371 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/nifi-opentsdb-nar/src/main/resources/META-INF/NOTICE ## @@ -0,0 +1,41 @@ +nifi-elasticsearch-nar Review comment: Copy-paste typo here, should be `nifi-opentsdb-nar` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297378618 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/LICENSE ## @@ -0,0 +1,201 @@ + Apache License Review comment: A `LICENSE` in the NAR module is all you need here, this file can be removed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297379836 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/nifi-opentsdb-processors/src/main/java/org/apache/nifi/processors/opentsdb/PutOpenTSDBHttp.java ## @@ -0,0 +1,183 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.nifi.processors.opentsdb; + +import com.alibaba.fastjson.JSONArray; +import com.alibaba.fastjson.JSONObject; +import okhttp3.*; Review comment: Please run the Maven build with the `-Pcontrib-check` profile activated, it will find Checkstyle errors like star imports. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297377702 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/README.md ## @@ -0,0 +1,59 @@ +# nifi-opentsdb-bundle Review comment: This is great for the GitHub repo but would be even better in an `additionalDetails.html` page so users could access this documentation from their NiFi instance. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB
mattyb149 commented on a change in pull request #2635: NIFI-5071 Create a Processor to write the contents of a FlowFile to OpenTSDB URL: https://github.com/apache/nifi/pull/2635#discussion_r297378255 ## File path: nifi-nar-bundles/nifi-opentsdb-bundle/nifi-opentsdb-nar/pom.xml ## @@ -0,0 +1,48 @@ + + +http://maven.apache.org/POM/4.0.0; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> +4.0.0 + + +nifi-opentsdb-bundle +org.apache.nifi +1.6.0 Review comment: Please update all NiFi dependencies to use version `1.10.0-SNAPSHOT`, they will be automatically updated to `1.10.0` upon release. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NIFI-6398) ReplaceText - Replace First
David Mollitor created NIFI-6398: Summary: ReplaceText - Replace First Key: NIFI-6398 URL: https://issues.apache.org/jira/browse/NIFI-6398 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: David Mollitor Add the option for 'replace all' or 'replace first' strategy. https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceFirst-java.lang.String-java.lang.String- https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceAll-java.lang.String-java.lang.String- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297377451
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-properties-loader/src/main/java/org/apache/nifi/properties/sensitive/ProtectedNiFiProperties.java
##
@@ -510,22 +448,21 @@ private boolean isProviderAvailable(String
protectionScheme) {
*/
private String unprotectValue(String key, String retrievedValue) {
// Checks if the key is sensitive and marked as protected
-if (isPropertyProtected(key)) {
-final String protectionScheme = getProperty(getProtectionKey(key));
+if (!isPropertyProtected(key)) {
+return retrievedValue;
+}
+final String protectionScheme = getProperty(getProtectionKey(key));
-// No provider registered for this scheme, so just return the value
-if (!isProviderAvailable(protectionScheme)) {
-logger.warn("No provider available for {} so passing the
protected {} value back", protectionScheme, key);
-return retrievedValue;
-}
+if (protectionScheme.equals("unknown")) {
+return retrievedValue;
+}
-try {
-SensitivePropertyProvider sensitivePropertyProvider =
getSensitivePropertyProvider(protectionScheme);
-return sensitivePropertyProvider.unprotect(retrievedValue);
-} catch (SensitivePropertyProtectionException e) {
-throw new SensitivePropertyProtectionException("Error
unprotecting value for " + key, e.getCause());
-}
+// try and make one to unprotect, and if that fails...
+try {
+return
StandardSensitivePropertyProvider.fromKey(defaultKeyHex).unprotect(retrievedValue);
Review comment:
Good catch; updated.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (NIFI-5087) ConvertJSONToSQL creates invalid SQL for PostgreSQL dates
[ https://issues.apache.org/jira/browse/NIFI-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872688#comment-16872688 ] Matt Burgess commented on NIFI-5087: Can you give more details about this, such as an example of the input date and the generated timestamp literal? > ConvertJSONToSQL creates invalid SQL for PostgreSQL dates > - > > Key: NIFI-5087 > URL: https://issues.apache.org/jira/browse/NIFI-5087 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: Ubuntu >Reporter: Matt Forrester >Priority: Minor > > Given an ISO-8601 date and a PG Timestamp field, the ConvertJSONToSQL > processor creates SQL which looks correct but does not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] scottyaslan commented on issue #3536: NIFI-6380: Introduced the notion of Parameters and Parameter Contexts…
scottyaslan commented on issue #3536: NIFI-6380: Introduced the notion of Parameters and Parameter Contexts… URL: https://github.com/apache/nifi/pull/3536#issuecomment-505595501 I am a +1 at this point. Thanks for the contribution @markap14 ! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MINIFICPP-932) Bootsrap incorrectly enforces NSS even when we are statically linking libressl
[ https://issues.apache.org/jira/browse/MINIFICPP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872620#comment-16872620 ] Mr TheSegfault edited comment on MINIFICPP-932 at 6/25/19 6:54 PM: --- I'll piggy back this to MINIFICPP-796 since it's simple and helps me test this PR was (Author: phrocker): I'll piggy back this to MINIFICPP-796 since it's simple > Bootsrap incorrectly enforces NSS even when we are statically linking libressl > -- > > Key: MINIFICPP-932 > URL: https://issues.apache.org/jira/browse/MINIFICPP-932 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > > This causes us to connect through libressl as we should. We likely should not > rely on the curl command to make this determination when we are statically > building libressl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MINIFICPP-932) Bootsrap incorrectly enforces NSS even when we are statically linking libressl
[ https://issues.apache.org/jira/browse/MINIFICPP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault reassigned MINIFICPP-932: Assignee: Mr TheSegfault > Bootsrap incorrectly enforces NSS even when we are statically linking libressl > -- > > Key: MINIFICPP-932 > URL: https://issues.apache.org/jira/browse/MINIFICPP-932 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > > This causes us to connect through libressl as we should. We likely should not > rely on the curl command to make this determination when we are statically > building libressl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFICPP-932) Bootsrap incorrectly enforces NSS even when we are statically linking libressl
[ https://issues.apache.org/jira/browse/MINIFICPP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872620#comment-16872620 ] Mr TheSegfault commented on MINIFICPP-932: -- I'll piggy back this to MINIFICPP-796 since it's simple > Bootsrap incorrectly enforces NSS even when we are statically linking libressl > -- > > Key: MINIFICPP-932 > URL: https://issues.apache.org/jira/browse/MINIFICPP-932 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > > This causes us to connect through libressl as we should. We likely should not > rely on the curl command to make this determination when we are statically > building libressl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-932) Bootsrap incorrectly enforces NSS even when we are statically linking libressl
[ https://issues.apache.org/jira/browse/MINIFICPP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-932: - Description: This causes us to connect through libressl as we should. We likely should not rely on the curl command to make this determination when we are statically building libressl (was: This causes us to connect through libressl as we should.) > Bootsrap incorrectly enforces NSS even when we are statically linking libressl > -- > > Key: MINIFICPP-932 > URL: https://issues.apache.org/jira/browse/MINIFICPP-932 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Priority: Blocker > Fix For: 0.7.0 > > > This causes us to connect through libressl as we should. We likely should not > rely on the curl command to make this determination when we are statically > building libressl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-932) Bootsrap incorrectly enforces NSS even when we are statically linking libressl
Mr TheSegfault created MINIFICPP-932: Summary: Bootsrap incorrectly enforces NSS even when we are statically linking libressl Key: MINIFICPP-932 URL: https://issues.apache.org/jira/browse/MINIFICPP-932 Project: Apache NiFi MiNiFi C++ Issue Type: Bug Reporter: Mr TheSegfault Fix For: 0.7.0 This causes us to connect through libressl as we should. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297332886
##
File path:
nifi-toolkit/nifi-toolkit-encrypt-config/src/main/groovy/org/apache/nifi/properties/ConfigEncryptionTool.groovy
##
@@ -1568,7 +1572,7 @@ class ConfigEncryptionTool {
// If the tool is not going to encrypt NiFiProperties
and the existing file is already encrypted, encrypt and update the new
sensitive props key
if (!tool.handlingNiFiProperties &&
existingNiFiPropertiesAreEncrypted) {
-AESSensitivePropertyProvider spp = new
AESSensitivePropertyProvider(tool.keyHex)
+SensitivePropertyProvider spp =
StandardSensitivePropertyProvider.fromKey(tool.keyHex)
Review comment:
I renamed `keyHex` to `keyOrKeyId` and `migrationKeyHex` to
`migrationKeyOrKeyId`. Similarly adjusted method parameter names, and various
variable names in the class.
However, when I tried to rename either of the methods `getKey` and
`getMigrationKey`, the tests hang. Not sure where the behavior is coming from;
even adding (not renaming) a similar method produces the hangs.
There is still plenty of internal hex-string handling, and I'll revisit
those as time allows. If we still can't resolve all of that, I'll open that
secondary jira ticket.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] markap14 commented on a change in pull request #3544: NIFI-6028: Updates to ignore changes between local version of a flow …
markap14 commented on a change in pull request #3544: NIFI-6028: Updates to
ignore changes between local version of a flow …
URL: https://github.com/apache/nifi/pull/3544#discussion_r297325413
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/util/FlowDifferenceFilters.java
##
@@ -113,4 +117,145 @@ public static boolean
isIgnorableVersionedFlowCoordinateChange(final FlowDiffere
return false;
}
+
+
+public static boolean isNewPropertyWithDefaultValue(final FlowDifference
fd, final FlowManager flowManager) {
+if (fd.getDifferenceType() != DifferenceType.PROPERTY_ADDED) {
+return false;
+}
+
+final VersionedComponent componentB = fd.getComponentB();
+
+if (componentB instanceof InstantiatedVersionedProcessor) {
+final InstantiatedVersionedProcessor instantiatedProcessor =
(InstantiatedVersionedProcessor) componentB;
+final ProcessorNode processorNode =
flowManager.getProcessorNode(instantiatedProcessor.getInstanceId());
+return isNewPropertyWithDefaultValue(fd, processorNode);
+} else if (componentB instanceof
InstantiatedVersionedControllerService) {
+final InstantiatedVersionedControllerService
instantiatedControllerService = (InstantiatedVersionedControllerService)
componentB;
+final ControllerServiceNode controllerService =
flowManager.getControllerServiceNode(instantiatedControllerService.getInstanceId());
+return isNewPropertyWithDefaultValue(fd, controllerService);
+}
+
+return false;
+}
+
+private static boolean isNewPropertyWithDefaultValue(final FlowDifference
fd, final ProcessorNode processorNode) {
Review comment:
D'oh, good point! Will push a new commit that takes advantage of this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Resolved] (NIFIREG-287) FlowDifference object should include property name when a property is added/removed
[ https://issues.apache.org/jira/browse/NIFIREG-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman resolved NIFIREG-287. - Resolution: Fixed Fix Version/s: 0.5.0 > FlowDifference object should include property name when a property is > added/removed > --- > > Key: NIFIREG-287 > URL: https://issues.apache.org/jira/browse/NIFIREG-287 > Project: NiFi Registry > Issue Type: Bug >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 0.5.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When a FlowDifference object is created, it does not populate the 'fieldName' > of the FlowDifference. This means that consumers of the FlowDifference object > are unable to determine which property was added/removed/modified -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-registry] mcgilman commented on issue #201: NIFIREG-287: For Flow Difference objects of type PROPERTY_MODIFIED, P…
mcgilman commented on issue #201: NIFIREG-287: For Flow Difference objects of type PROPERTY_MODIFIED, P… URL: https://github.com/apache/nifi-registry/pull/201#issuecomment-505552188 Thanks @markap14! This has been merged to master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi-registry] asfgit closed pull request #201: NIFIREG-287: For Flow Difference objects of type PROPERTY_MODIFIED, P…
asfgit closed pull request #201: NIFIREG-287: For Flow Difference objects of type PROPERTY_MODIFIED, P… URL: https://github.com/apache/nifi-registry/pull/201 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] mcgilman commented on a change in pull request #3544: NIFI-6028: Updates to ignore changes between local version of a flow …
mcgilman commented on a change in pull request #3544: NIFI-6028: Updates to
ignore changes between local version of a flow …
URL: https://github.com/apache/nifi/pull/3544#discussion_r297312170
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/util/FlowDifferenceFilters.java
##
@@ -113,4 +117,145 @@ public static boolean
isIgnorableVersionedFlowCoordinateChange(final FlowDiffere
return false;
}
+
+
+public static boolean isNewPropertyWithDefaultValue(final FlowDifference
fd, final FlowManager flowManager) {
+if (fd.getDifferenceType() != DifferenceType.PROPERTY_ADDED) {
+return false;
+}
+
+final VersionedComponent componentB = fd.getComponentB();
+
+if (componentB instanceof InstantiatedVersionedProcessor) {
+final InstantiatedVersionedProcessor instantiatedProcessor =
(InstantiatedVersionedProcessor) componentB;
+final ProcessorNode processorNode =
flowManager.getProcessorNode(instantiatedProcessor.getInstanceId());
+return isNewPropertyWithDefaultValue(fd, processorNode);
+} else if (componentB instanceof
InstantiatedVersionedControllerService) {
+final InstantiatedVersionedControllerService
instantiatedControllerService = (InstantiatedVersionedControllerService)
componentB;
+final ControllerServiceNode controllerService =
flowManager.getControllerServiceNode(instantiatedControllerService.getInstanceId());
+return isNewPropertyWithDefaultValue(fd, controllerService);
+}
+
+return false;
+}
+
+private static boolean isNewPropertyWithDefaultValue(final FlowDifference
fd, final ProcessorNode processorNode) {
Review comment:
This method appears to be overloaded below. However, the parameter that
differs shares a common ancestor interface. I _think_ we can update the args to
use a `ComponentNode` and remove the duplicated code.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] markap14 closed pull request #3548: NIFI-5856: When exporting a flow that references a Controller Service…
markap14 closed pull request #3548: NIFI-5856: When exporting a flow that references a Controller Service… URL: https://github.com/apache/nifi/pull/3548 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi-registry] markap14 closed pull request #202: NIFIREG-288: Introduced notion of a VersionedControllerServiceReference
markap14 closed pull request #202: NIFIREG-288: Introduced notion of a VersionedControllerServiceReference URL: https://github.com/apache/nifi-registry/pull/202 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297304708
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-properties-loader/src/test/groovy/org/apache/nifi/properties/NiFiPropertiesLoaderGroovyTest.groovy
##
@@ -119,6 +115,7 @@ class NiFiPropertiesLoaderGroovyTest extends
GroovyTestCase {
assert niFiPropertiesLoader.@keyHex == KEY_HEX
}
+@Ignore // functionality / test should move to
StandardSensitivePropertyProvider class
Review comment:
Migrated test from `NiFiPropertiesLoaderGroovyTest.groovy` to
`StandardSensitivePropertyProviderIT.groovy`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297296598
##
File path:
nifi-toolkit/nifi-toolkit-encrypt-config/src/main/groovy/org/apache/nifi/properties/ConfigEncryptionTool.groovy
##
@@ -1091,7 +1095,7 @@ class ConfigEncryptionTool {
encryptedProperties.setProperty(key,
plainProperties.getProperty(key))
}
NiFiProperties mergedProperties = new
StandardNiFiProperties(encryptedProperties)
-logger.info("Final result: ${mergedProperties.size()} keys including
${ProtectedNiFiProperties.countProtectedProperties(mergedProperties)} protected
keys")
+logger.info("Final result: ${mergedProperties.size()} keys including
${ProtectedNiFiProperties.countProtectedProperties(mergedProperties, keyHex)}
protected keys")
Review comment:
I removed the unnecessary key parameter; the method passes an empty string
along to the ctor, which produces a null SPP, which provides the count as
expected.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [nifi] natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS KMS SPP. Refactors SSPP.
natural commented on a change in pull request #3542: NIFI-6363 Integrates AWS
KMS SPP. Refactors SSPP.
URL: https://github.com/apache/nifi/pull/3542#discussion_r297287519
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-properties-loader/src/main/java/org/apache/nifi/properties/sensitive/StandardSensitivePropertyProvider.java
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.properties.sensitive;
+
+import org.apache.nifi.properties.sensitive.aes.AESSensitivePropertyProvider;
+import
org.apache.nifi.properties.sensitive.aws.kms.AWSKMSSensitivePropertyProvider;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * This class hides the various SPP subclass construction from clients.
+ *
+ */
+public class StandardSensitivePropertyProvider {
+private static final Logger logger =
LoggerFactory.getLogger(StandardSensitivePropertyProvider.class);
+
+/**
+ * Creates a {@link SensitivePropertyProvider} suitable for a given key.
+ *
+ * If no provider recognizes a key, this implementation still returns an
{@link AESSensitivePropertyProvider} with
+ * the supplied key.
+ *
+ * @param hex provider encryption key
+ * @param options array of string options
+ * @return concrete instance of SensitivePropertyProvider
+ */
+public static SensitivePropertyProvider fromKey(String hex, String...
options) {
Review comment:
I've removed the `options` vararg parameter and replaced it with a single
string param `scheme`, and adjusted the implementations and call sites to match.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (NIFI-1624) ExtractText - Add option to Throw Failure if Text is greater than Capture Group
[ https://issues.apache.org/jira/browse/NIFI-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randy Bovay updated NIFI-1624: -- Affects Version/s: 1.5.0 1.6.0 1.7.0 1.8.0 1.9.0 > ExtractText - Add option to Throw Failure if Text is greater than Capture > Group > --- > > Key: NIFI-1624 > URL: https://issues.apache.org/jira/browse/NIFI-1624 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 0.4.1, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0 >Reporter: Randy Bovay >Priority: Major > > ExtractText allows us to specify the "Maximum Capture Group Length" > Occasionally I will get a text string that is greater than what I've > specified. > In these unexpected situations, I would LIKE to route this to something that > can handle it, or throw an error so I can look into why this is larger than > expected. > The ask is to make the behavior configurable on LengthExceededBehavior. With > options of 'truncate' or 'failure'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] phrocker edited a comment on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate…
phrocker edited a comment on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate… URL: https://github.com/apache/nifi-minifi-cpp/pull/515#issuecomment-505504602 @arpadboda In my opinion Base64 encoding the underlying data is a great way to tackle the problem. As long as the API allows them to get/set these as binary data ( or handles the translation ). then I think that's a great idea. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MINIFICPP-931) NiFi properties that don't allow receiving site to site data will block MiNiFi process from stopping
Mr TheSegfault created MINIFICPP-931: Summary: NiFi properties that don't allow receiving site to site data will block MiNiFi process from stopping Key: MINIFICPP-931 URL: https://issues.apache.org/jira/browse/MINIFICPP-931 Project: Apache NiFi MiNiFi C++ Issue Type: Bug Reporter: Mr TheSegfault This occurs because our code is locked in TLS trap ( apparently ), capturing signals that we would otherwise use. These actually may respond to the minifi.sh script, but we can't ctrl+c if running manually -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] phrocker commented on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate…
phrocker commented on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate… URL: https://github.com/apache/nifi-minifi-cpp/pull/515#issuecomment-505504602 @arpadboda Base64 encoding the underlying data is fine, I think, as long as the API allows them to get/set these as binary data. I think that's a good idea. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (MINIFICPP-903) cleanup root cmake
[ https://issues.apache.org/jira/browse/MINIFICPP-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri resolved MINIFICPP-903. --- Resolution: Fixed > cleanup root cmake > -- > > Key: MINIFICPP-903 > URL: https://issues.apache.org/jira/browse/MINIFICPP-903 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This is an extension of MINIFICPP-570 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] asfgit closed pull request #578: MINIFICPP-903 and MINIFICPP-570 ( Partial ): Remove compression downl…
asfgit closed pull request #578: MINIFICPP-903 and MINIFICPP-570 ( Partial ): Remove compression downl… URL: https://github.com/apache/nifi-minifi-cpp/pull/578 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NIFI-6397) UI - isolate webpack loaders used specifically for code coverage purposes
Robert Fellows created NIFI-6397: Summary: UI - isolate webpack loaders used specifically for code coverage purposes Key: NIFI-6397 URL: https://issues.apache.org/jira/browse/NIFI-6397 Project: Apache NiFi Issue Type: Task Components: FDS Reporter: Robert Fellows Assignee: Robert Fellows The jsDev and tsDev loaders are mis-named. They should be renamed to jsCoverage and tsCoverage. Also, these loaders should specify a different directory for their usage of the cache-loader to avoid conflicts with normal webpack configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFIREG-289) UI - isolate webpack loaders used specifically for code coverage purposes
Robert Fellows created NIFIREG-289: -- Summary: UI - isolate webpack loaders used specifically for code coverage purposes Key: NIFIREG-289 URL: https://issues.apache.org/jira/browse/NIFIREG-289 Project: NiFi Registry Issue Type: Task Reporter: Robert Fellows Assignee: Robert Fellows The jsDev and tsDev loaders are mis-named. They should be renamed to jsCoverage and tsCoverage. Also, these loaders should specify a different directory for their usage of the cache-loader to avoid conflicts with normal webpack configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-minifi-cpp] arpadboda commented on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate…
arpadboda commented on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate… URL: https://github.com/apache/nifi-minifi-cpp/pull/515#issuecomment-505487733 @phrocker : what you say in aspect of Redis for eg. makes sense, however I think that's already messed up. Attributes are handled as UTF strings on S2S, so when transferring them, we handle them as strings, which means cutting at the first 0 byte. Even if we fix that I'm unsure whether we would achieve the behaviour we want or not given NiFi handles attributes as strings, too. To deal with binary formats I think I would prefer to offer base64 encoding for attribute settings and keep the internal representation (and network representation) as string. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NIFI-5856) Add capability to assign available matching controller services to processors during import from registry
[ https://issues.apache.org/jira/browse/NIFI-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872376#comment-16872376 ] Mark Payne commented on NIFI-5856: -- Created a PR for this. However, it will require a release of NiFi Registry before it can be merged to master, since it makes use of changes to the data model that are implemented in NIFIREG-288. > Add capability to assign available matching controller services to processors > during import from registry > - > > Key: NIFI-5856 > URL: https://issues.apache.org/jira/browse/NIFI-5856 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Ed Berezitsky >Assignee: Mark Payne >Priority: Major > Labels: SDLC > Fix For: 1.10.0 > > Time Spent: 10m > Remaining Estimate: 0h > > As a user I would like to reduce manual configuration of components after > importing flows from NIFI registry. > Use cases: > * a component uses controller service(s) defined in a scope of *parent* (or > higher) level (e.g. record-based processors, DB pools, etc) can have > controllers assigned by default, if ID registered is not available (versioned > from another NIFI instance) > * a controller service that is in a scope of imported flow uses another > controller in a scope of *parent* (or higher) level (e.g. Record > readers/writer using schema registry). > Current state: > * a lookup for a controller service is done by ID. If ID is not found, a > controller won't be assigned and property of a processor/controller will stay > blank and will require manual configuration/selection > Specifications/Requirements: > * Change current behavior to enable default assignment of controller > services to processor/controller property in case desired controller service > cannot be found by ID. > * in order to reduce wrong automatic assignments, both type and name of a > controller service should be considered. > * Since names aren't unique, have a NIFI property to specify strict and > nonstrict policy for multi-match: > ** strict mode will restrict automatic assignment of controller service, and > property in the processor/controller will stay blank (as per current > specification). > ** nonstrict mode will allow any of matching controllers to be assigned > (first found). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5856) Add capability to assign available matching controller services to processors during import from registry
[ https://issues.apache.org/jira/browse/NIFI-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5856: - Assignee: Mark Payne Status: Patch Available (was: Open) > Add capability to assign available matching controller services to processors > during import from registry > - > > Key: NIFI-5856 > URL: https://issues.apache.org/jira/browse/NIFI-5856 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Ed Berezitsky >Assignee: Mark Payne >Priority: Major > Labels: SDLC > Fix For: 1.10.0 > > Time Spent: 10m > Remaining Estimate: 0h > > As a user I would like to reduce manual configuration of components after > importing flows from NIFI registry. > Use cases: > * a component uses controller service(s) defined in a scope of *parent* (or > higher) level (e.g. record-based processors, DB pools, etc) can have > controllers assigned by default, if ID registered is not available (versioned > from another NIFI instance) > * a controller service that is in a scope of imported flow uses another > controller in a scope of *parent* (or higher) level (e.g. Record > readers/writer using schema registry). > Current state: > * a lookup for a controller service is done by ID. If ID is not found, a > controller won't be assigned and property of a processor/controller will stay > blank and will require manual configuration/selection > Specifications/Requirements: > * Change current behavior to enable default assignment of controller > services to processor/controller property in case desired controller service > cannot be found by ID. > * in order to reduce wrong automatic assignments, both type and name of a > controller service should be considered. > * Since names aren't unique, have a NIFI property to specify strict and > nonstrict policy for multi-match: > ** strict mode will restrict automatic assignment of controller service, and > property in the processor/controller will stay blank (as per current > specification). > ** nonstrict mode will allow any of matching controllers to be assigned > (first found). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] markap14 opened a new pull request #3548: NIFI-5856: When exporting a flow that references a Controller Service…
markap14 opened a new pull request #3548: NIFI-5856: When exporting a flow that
references a Controller Service…
URL: https://github.com/apache/nifi/pull/3548
…, also include the VersionedControllerServiceReference in the
VersionedPropertyDescriptor. When importing/updating a flow, if a Controller
Service that is inherited is referenced, attempt to find any one
ControllerService that gets inherited whose Type, Bundle, and and Name match
the reference and if found link to that Controller Service.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug NIFI-._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `master`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (NIFI-5856) Add capability to assign available matching controller services to processors during import from registry
[ https://issues.apache.org/jira/browse/NIFI-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-5856: - Fix Version/s: 1.10.0 > Add capability to assign available matching controller services to processors > during import from registry > - > > Key: NIFI-5856 > URL: https://issues.apache.org/jira/browse/NIFI-5856 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Ed Berezitsky >Priority: Major > Labels: SDLC > Fix For: 1.10.0 > > Time Spent: 10m > Remaining Estimate: 0h > > As a user I would like to reduce manual configuration of components after > importing flows from NIFI registry. > Use cases: > * a component uses controller service(s) defined in a scope of *parent* (or > higher) level (e.g. record-based processors, DB pools, etc) can have > controllers assigned by default, if ID registered is not available (versioned > from another NIFI instance) > * a controller service that is in a scope of imported flow uses another > controller in a scope of *parent* (or higher) level (e.g. Record > readers/writer using schema registry). > Current state: > * a lookup for a controller service is done by ID. If ID is not found, a > controller won't be assigned and property of a processor/controller will stay > blank and will require manual configuration/selection > Specifications/Requirements: > * Change current behavior to enable default assignment of controller > services to processor/controller property in case desired controller service > cannot be found by ID. > * in order to reduce wrong automatic assignments, both type and name of a > controller service should be considered. > * Since names aren't unique, have a NIFI property to specify strict and > nonstrict policy for multi-match: > ** strict mode will restrict automatic assignment of controller service, and > property in the processor/controller will stay blank (as per current > specification). > ** nonstrict mode will allow any of matching controllers to be assigned > (first found). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFIREG-288) When a property references a Controller Service, store information about that service in registry
[ https://issues.apache.org/jira/browse/NIFIREG-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFIREG-288: --- Fix Version/s: 0.5.0 > When a property references a Controller Service, store information about that > service in registry > - > > Key: NIFIREG-288 > URL: https://issues.apache.org/jira/browse/NIFIREG-288 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 0.5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When a Processor or a Controller Service references another Controller > Service, the exported flow contains the UUID of that Controller Service. Upon > import, this allows NiFi to connect that processor/service with the > referenced Controller Service. > However, if that Controller Service is inherited from outside of the flow > that is versioned, there is no information about that service, such as Name, > Type, or Bundle. If NiFi were to have that information, it could marry up the > reference to an existing Controller Service. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi-registry] markap14 opened a new pull request #202: NIFIREG-288: Introduced notion of a VersionedControllerServiceReference
markap14 opened a new pull request #202: NIFIREG-288: Introduced notion of a VersionedControllerServiceReference URL: https://github.com/apache/nifi-registry/pull/202 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NIFIREG-288) When a property references a Controller Service, store information about that service in registry
Mark Payne created NIFIREG-288: -- Summary: When a property references a Controller Service, store information about that service in registry Key: NIFIREG-288 URL: https://issues.apache.org/jira/browse/NIFIREG-288 Project: NiFi Registry Issue Type: Improvement Reporter: Mark Payne Assignee: Mark Payne When a Processor or a Controller Service references another Controller Service, the exported flow contains the UUID of that Controller Service. Upon import, this allows NiFi to connect that processor/service with the referenced Controller Service. However, if that Controller Service is inherited from outside of the flow that is versioned, there is no information about that service, such as Name, Type, or Bundle. If NiFi were to have that information, it could marry up the reference to an existing Controller Service. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] travisneeley commented on a change in pull request #3541: NIFI-6387 Implemented RetryFlowFile
travisneeley commented on a change in pull request #3541: NIFI-6387 Implemented
RetryFlowFile
URL: https://github.com/apache/nifi/pull/3541#discussion_r297199115
##
File path:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RetryFlowFile.java
##
@@ -0,0 +1,225 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.annotation.behavior.DynamicProperty;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.ReadsAttribute;
+import org.apache.nifi.annotation.behavior.SideEffectFree;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.configuration.DefaultSettings;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.expression.ExpressionLanguageScope;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+@Tags({"Retry", "FlowFile"})
+@CapabilityDescription("FlowFiles passed to this Processor have a 'Retry
Attribute' value checked against a " +
+"configured 'Maximum Retries' value. If the current attribute value is
below the configured maximum, the " +
+"FlowFile is passed to a retry relationship. The FlowFile may or may
not be penalized in that condition. " +
+"If the FlowFile's attribute value exceeds the configured maximum, the
FlowFile will be passed to a " +
+"'retries_exceeded' relationship. WARNING: If the incoming FlowFile
has a non-numeric value in the " +
+"configured 'Retry Attribute' attribute, it will be reset to '1'. You
may choose to fail the FlowFile " +
+"instead of performing the reset. Additional dynamic properties can be
defined for any attributes you " +
+"wish to add to the FlowFiles transferred to 'retries_exceeded'. These
attributes support attribute " +
+"expression language.")
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@SupportsBatching
+@SideEffectFree
+@DefaultSettings(penaltyDuration = "2 min")
+@ReadsAttribute(attribute = "Retry Attribute",
+description = "Will read the attribute or attribute expression
language result as defined in 'Retry Attribute'")
+@WritesAttribute(attribute = "Retry Attribute",
+description = "User defined retry attribute is updated with the
current retry count")
+@DynamicProperty(name = "Exceeded FlowFile Attribute Key",
+value = "The value of the attribute added to the FlowFile",
+description = "One or more dynamic properties can be used to add
attributes to FlowFiles passed to " +
+"the 'retries_exceeded' relationship",
+expressionLanguageScope = ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+public class RetryFlowFile extends AbstractProcessor {
+private List properties;
+private Set relationships;
+private String retryAttribute;
+private Integer maximumRetries;
+private Boolean penalizeRetried;
+private Boolean failOnOverwrite;
+
+public static final PropertyDescriptor RETRY_ATTRIBUTE = new
PropertyDescriptor.Builder()
+.name("Retry Attribute")
+.description("The name of the attribute that contains the current
retry count for the FlowFile. " +
+"WARNING: If the name matches an attribute already on the
FlowFile
[GitHub] [nifi] travisneeley commented on a change in pull request #3541: NIFI-6387 Implemented RetryFlowFile
travisneeley commented on a change in pull request #3541: NIFI-6387 Implemented
RetryFlowFile
URL: https://github.com/apache/nifi/pull/3541#discussion_r297198480
##
File path:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RetryFlowFile.java
##
@@ -0,0 +1,225 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.annotation.behavior.DynamicProperty;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.ReadsAttribute;
+import org.apache.nifi.annotation.behavior.SideEffectFree;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.configuration.DefaultSettings;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.expression.ExpressionLanguageScope;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+@Tags({"Retry", "FlowFile"})
+@CapabilityDescription("FlowFiles passed to this Processor have a 'Retry
Attribute' value checked against a " +
+"configured 'Maximum Retries' value. If the current attribute value is
below the configured maximum, the " +
+"FlowFile is passed to a retry relationship. The FlowFile may or may
not be penalized in that condition. " +
+"If the FlowFile's attribute value exceeds the configured maximum, the
FlowFile will be passed to a " +
+"'retries_exceeded' relationship. WARNING: If the incoming FlowFile
has a non-numeric value in the " +
+"configured 'Retry Attribute' attribute, it will be reset to '1'. You
may choose to fail the FlowFile " +
+"instead of performing the reset. Additional dynamic properties can be
defined for any attributes you " +
+"wish to add to the FlowFiles transferred to 'retries_exceeded'. These
attributes support attribute " +
+"expression language.")
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@SupportsBatching
+@SideEffectFree
+@DefaultSettings(penaltyDuration = "2 min")
+@ReadsAttribute(attribute = "Retry Attribute",
+description = "Will read the attribute or attribute expression
language result as defined in 'Retry Attribute'")
+@WritesAttribute(attribute = "Retry Attribute",
+description = "User defined retry attribute is updated with the
current retry count")
+@DynamicProperty(name = "Exceeded FlowFile Attribute Key",
+value = "The value of the attribute added to the FlowFile",
+description = "One or more dynamic properties can be used to add
attributes to FlowFiles passed to " +
+"the 'retries_exceeded' relationship",
+expressionLanguageScope = ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+public class RetryFlowFile extends AbstractProcessor {
+private List properties;
+private Set relationships;
+private String retryAttribute;
+private Integer maximumRetries;
+private Boolean penalizeRetried;
+private Boolean failOnOverwrite;
+
+public static final PropertyDescriptor RETRY_ATTRIBUTE = new
PropertyDescriptor.Builder()
+.name("Retry Attribute")
+.description("The name of the attribute that contains the current
retry count for the FlowFile. " +
+"WARNING: If the name matches an attribute already on the
FlowFile
[GitHub] [nifi] travisneeley commented on a change in pull request #3541: NIFI-6387 Implemented RetryFlowFile
travisneeley commented on a change in pull request #3541: NIFI-6387 Implemented
RetryFlowFile
URL: https://github.com/apache/nifi/pull/3541#discussion_r297198220
##
File path:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/RetryFlowFile.java
##
@@ -0,0 +1,225 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.standard;
+
+import org.apache.nifi.annotation.behavior.DynamicProperty;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.ReadsAttribute;
+import org.apache.nifi.annotation.behavior.SideEffectFree;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.configuration.DefaultSettings;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.expression.ExpressionLanguageScope;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+@Tags({"Retry", "FlowFile"})
Review comment:
Not specifically. I would imagine since the action of the Processor revolves
around the state of a particular FlowFile that it could be added to the tag
list. I'll omit if that's convention
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MINIFICPP-930) Add expression language support to Controller Services
[ https://issues.apache.org/jira/browse/MINIFICPP-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872354#comment-16872354 ] Mr TheSegfault commented on MINIFICPP-930: -- Of note is that Controller Services do have access to minifi.properties and properties defined by said controller service, but no way to evaluate those properties using EL ( if it is built ). > Add expression language support to Controller Services > -- > > Key: MINIFICPP-930 > URL: https://issues.apache.org/jira/browse/MINIFICPP-930 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Daniel Bakai >Priority: Minor > > Controller Services should probably have EL capabilities. Currently there is > no concept of ConfigurationConcept – but this has the same effective > interface as a ProcessContext. The annotations in NiFi make it easy to > schedule these elements, but we can simply do this in the controller services > prior to being enabled. > Probably a pretty low priority since Controller Services aren't written very > frequently in MiNiFi C++ – but there is also a gap in that properties could > be defined that support EL without the ability to execute them. We should > fill this gap on a time frame that makes sense . > > While this was a previously known gap I've forgotten about this myself which > implies we probably would be doing a disservice to developers and users who > expect this capability. > Initially identified by [~bakaid] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-930) Add expression language to Controller Services
[ https://issues.apache.org/jira/browse/MINIFICPP-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-930: - Description: Controller Services should probably have EL capabilities. Currently there is no concept of ConfigurationConcept – but this has the same effective interface as a ProcessContext. The annotations in NiFi make it easy to schedule these elements, but we can simply do this in the controller services prior to being enabled. Probably a pretty low priority since Controller Services aren't written very frequently in MiNiFi C++ – but there is also a gap in that properties could be defined that support EL without the ability to execute them. We should fill this gap on a time frame that makes sense . While this was a previously known gap I've forgotten about this myself which implies we probably would be doing a disservice to developers and users who expect this capability. Initially identified by [~bakaid] was: Controller Services should probably have EL capabilities. Currently there is no concept of ConfigurationConcept – but this has the same effective interface as a ProcessContext. The annotations in NiFi make it easy to schedule these elements, but we can simply do this in the controller services prior to being enabled. Probably a pretty low priority since Controller Services aren't written very frequently in MiNiFi C++ – but there is also a gap in that properties could be defined that support EL without the ability to execute them. We should fill this gap on a time frame that makes sense. Initially identified by [~bakaid] > Add expression language to Controller Services > -- > > Key: MINIFICPP-930 > URL: https://issues.apache.org/jira/browse/MINIFICPP-930 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Daniel Bakai >Priority: Minor > > Controller Services should probably have EL capabilities. Currently there is > no concept of ConfigurationConcept – but this has the same effective > interface as a ProcessContext. The annotations in NiFi make it easy to > schedule these elements, but we can simply do this in the controller services > prior to being enabled. > Probably a pretty low priority since Controller Services aren't written very > frequently in MiNiFi C++ – but there is also a gap in that properties could > be defined that support EL without the ability to execute them. We should > fill this gap on a time frame that makes sense . > > While this was a previously known gap I've forgotten about this myself which > implies we probably would be doing a disservice to developers and users who > expect this capability. > Initially identified by [~bakaid] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-930) Add expression language support to Controller Services
[ https://issues.apache.org/jira/browse/MINIFICPP-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-930: - Summary: Add expression language support to Controller Services (was: Add expression language to Controller Services) > Add expression language support to Controller Services > -- > > Key: MINIFICPP-930 > URL: https://issues.apache.org/jira/browse/MINIFICPP-930 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Daniel Bakai >Priority: Minor > > Controller Services should probably have EL capabilities. Currently there is > no concept of ConfigurationConcept – but this has the same effective > interface as a ProcessContext. The annotations in NiFi make it easy to > schedule these elements, but we can simply do this in the controller services > prior to being enabled. > Probably a pretty low priority since Controller Services aren't written very > frequently in MiNiFi C++ – but there is also a gap in that properties could > be defined that support EL without the ability to execute them. We should > fill this gap on a time frame that makes sense . > > While this was a previously known gap I've forgotten about this myself which > implies we probably would be doing a disservice to developers and users who > expect this capability. > Initially identified by [~bakaid] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-930) Add expression language to Controller Services
Mr TheSegfault created MINIFICPP-930: Summary: Add expression language to Controller Services Key: MINIFICPP-930 URL: https://issues.apache.org/jira/browse/MINIFICPP-930 Project: Apache NiFi MiNiFi C++ Issue Type: Improvement Reporter: Daniel Bakai Controller Services should probably have EL capabilities. Currently there is no concept of ConfigurationConcept – but this has the same effective interface as a ProcessContext. The annotations in NiFi make it easy to schedule these elements, but we can simply do this in the controller services prior to being enabled. Probably a pretty low priority since Controller Services aren't written very frequently in MiNiFi C++ – but there is also a gap in that properties could be defined that support EL without the ability to execute them. We should fill this gap on a time frame that makes sense. Initially identified by [~bakaid] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [nifi] mcgilman commented on issue #3544: NIFI-6028: Updates to ignore changes between local version of a flow …
mcgilman commented on issue #3544: NIFI-6028: Updates to ignore changes between local version of a flow … URL: https://github.com/apache/nifi/pull/3544#issuecomment-505437791 Will review... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi-registry] mcgilman commented on issue #201: NIFIREG-287: For Flow Difference objects of type PROPERTY_MODIFIED, P…
mcgilman commented on issue #201: NIFIREG-287: For Flow Difference objects of type PROPERTY_MODIFIED, P… URL: https://github.com/apache/nifi-registry/pull/201#issuecomment-505429896 Will review... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi-minifi-cpp] phrocker commented on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate…
phrocker commented on issue #515: MINIFICPP-646 - Re-evaluate passing attributes. Potentially deprecate… URL: https://github.com/apache/nifi-minifi-cpp/pull/515#issuecomment-505381602 @arpadboda Value needn't be null terminated, especially given the sink and source where nanofi may exist; however, I don't actually have a strong opinion on that for this PR -- especially if @bakaid and @msharee9 agree with that approach. NiFi is not the penultimate input/output of NanoFi code -- but as we evolve we can live in the confines of that decision for attributes. Think of the input/output of nanofi edge controller units as being site to site, kafka, mqtt, pipe, and file ( and maybe redis eventually ). In any of these cases attributes can be of an intermediate form. That means that attributes could carry binary data ( hence why they were initially not typed and instead a bag of keys and values -- I think this is how redis stores them internally ). I think you can draw a line in the sand that attributes are null terminated and require that another mechanism be built. This may alleviate your concerns about having non textual data in the attributes -- so then we can simply create a follow on to store intermediate data that are attributes of the data that are binary. The initial API facilitated C strings that were null terminated and arbitrary binary data. If you feel separating these concerns is important we can make a follow on ticket for the release that references 646. I can certainly see the value in isolating those APIs. I don't have a super strong opinion on how you structure this "struct" -- as long as we have a way to ultimately carry attributes that are not null terminated. if you think it helps to add API calls for something like "add_binary_attribute", then I'm okay with that. I don't really foresee a great deal of cost with ownership as you present it. Since we own that data structure and if it were opaque as @bakaid suggests, then we can realloc more safely. All code that uses the variants of the API defined in the last release should compile in this minor release. How everything is represented internally is up to you. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] MikeThomsen commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
MikeThomsen commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297102814 ## File path: nifi-nar-bundles/nifi-groovyx-bundle/pom.xml ## @@ -39,8 +39,14 @@ org.codehaus.groovy -groovy-all -2.4.11 +groovy-json Review comment: See previous comment. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [nifi] MikeThomsen commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4
MikeThomsen commented on a change in pull request #3547: [WIP] NIFI-5254 Update Groovy dependecies to version 2.5.4 URL: https://github.com/apache/nifi/pull/3547#discussion_r297103059 ## File path: nifi-nar-bundles/nifi-scripting-bundle/pom.xml ## @@ -67,15 +67,27 @@ 1.10.0-SNAPSHOT provided + org.codehaus.groovy -groovy-all -2.4.15 - +groovy-json +2.5.4 +compile + + Review comment: See previous comment about other missing modules. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
