[jira] [Commented] (NIFI-11031) Intermittent Failures in TestGenerateRecord
[
https://issues.apache.org/jira/browse/NIFI-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655632#comment-17655632
]
ASF subversion and git services commented on NIFI-11031:
Commit 4f77a17d19c3e6ab5f85d0c836dbbca6cc703711 in nifi's branch
refs/heads/main from Matt Burgess
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=4f77a17d19 ]
NIFI-11031: Fix logic error in GenerateRecord for nullPercentage
This closes #6830
Signed-off-by: David Handermann
> Intermittent Failures in TestGenerateRecord
> ---
>
> Key: NIFI-11031
> URL: https://issues.apache.org/jira/browse/NIFI-11031
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: David Handermann
>Assignee: Matt Burgess
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{TestGenerateRecord}} fails intermittently in automated builds with the
> following error:
> {noformat}
> Error:
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText
> Time elapsed: 1.035 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText(TestGenerateRecord.java:237)
> {noformat}
> The problem appears to be related to the supporting Faker service returning
> {{null}} when the code is not expecting any {{null}} values according to the
> {{Null Percentage}} property setting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11031) Intermittent Failures in TestGenerateRecord
[
https://issues.apache.org/jira/browse/NIFI-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-11031:
Fix Version/s: 1.20.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Intermittent Failures in TestGenerateRecord
> ---
>
> Key: NIFI-11031
> URL: https://issues.apache.org/jira/browse/NIFI-11031
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: David Handermann
>Assignee: Matt Burgess
>Priority: Major
> Fix For: 1.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{TestGenerateRecord}} fails intermittently in automated builds with the
> following error:
> {noformat}
> Error:
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText
> Time elapsed: 1.035 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText(TestGenerateRecord.java:237)
> {noformat}
> The problem appears to be related to the supporting Faker service returning
> {{null}} when the code is not expecting any {{null}} values according to the
> {{Null Percentage}} property setting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] exceptionfactory closed pull request #6830: NIFI-11031: Fix logic error in GenerateRecord for nullPercentage
exceptionfactory closed pull request #6830: NIFI-11031: Fix logic error in GenerateRecord for nullPercentage URL: https://github.com/apache/nifi/pull/6830 -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-10997) Ensure auditing of process group / controller service operations
[ https://issues.apache.org/jira/browse/NIFI-10997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Grey updated NIFI-10997: - Status: Patch Available (was: In Progress) > Ensure auditing of process group / controller service operations > - > > Key: NIFI-10997 > URL: https://issues.apache.org/jira/browse/NIFI-10997 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Time Spent: 1.5h > Remaining Estimate: 0h > > Process Group start / stop operation should be audited (with attribution) in > Flow Configuration History (available via hamburger menu at upper-right of > UI). Also verify other component state change operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11031) Intermittent Failures in TestGenerateRecord
[
https://issues.apache.org/jira/browse/NIFI-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Burgess updated NIFI-11031:
Status: Patch Available (was: In Progress)
> Intermittent Failures in TestGenerateRecord
> ---
>
> Key: NIFI-11031
> URL: https://issues.apache.org/jira/browse/NIFI-11031
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: David Handermann
>Assignee: Matt Burgess
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{TestGenerateRecord}} fails intermittently in automated builds with the
> following error:
> {noformat}
> Error:
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText
> Time elapsed: 1.035 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText(TestGenerateRecord.java:237)
> {noformat}
> The problem appears to be related to the supporting Faker service returning
> {{null}} when the code is not expecting any {{null}} values according to the
> {{Null Percentage}} property setting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] mattyb149 opened a new pull request, #6830: NIFI-11031: Fix logic error in GenerateRecord for nullPercentage
mattyb149 opened a new pull request, #6830: URL: https://github.com/apache/nifi/pull/6830 # Summary [NIFI-11031](https://issues.apache.org/jira/browse/NIFI-11031) This PR changes `<=` to `<` for the calculation of `nullPercentage`, this fixes an error where `null` values can show up in a record where `nullPercentage` is zero. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [x] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [x] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-11031` - [x] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-11031` ### Pull Request Formatting - [x] Pull Request based on current revision of the `main` branch - [x] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 8 - [x] JDK 11 - [ ] JDK 17 ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (NIFI-5901) Write JSON record in database
[
https://issues.apache.org/jira/browse/NIFI-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655587#comment-17655587
]
Christoph Charlet edited comment on NIFI-5901 at 1/6/23 9:43 PM:
-
Sorry - not sure if I understand this correctly: The idea is that if I have a
MapRecord, with one of the entries being a MapRecord itself, I use some kind of
transformation to convert the sub-record to a string, and then it will work?
(And do we really think that's a great strategy?)
Come to think of it: Wouldn't it then be extremely simple to have the processor
do the stringification, and the thing is solved far more elegantly?
was (Author: ccharlet):
Sorry - not sure if I understand this correctly: The idea is that if I have a
MapRecord, with one of the entries being a MapRecord itself, I use some kind of
transformation to convert the sub-record to a string, and then it will work?
(And do we really think that's a great strategy?)
> Write JSON record in database
> -
>
> Key: NIFI-5901
> URL: https://issues.apache.org/jira/browse/NIFI-5901
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Flo Rance
>Assignee: Mike Thomsen
>Priority: Minor
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> It would be good to be able to store a whole json record in databases that
> implement it (e.g. postgresql). This would require to define the field in the
> shema as json/jsonb and then let PutDatabaseRecord inserts the json value in
> the json/jsonb field.
> At the moment, it's possible to store a json/jsonb through Postgresql JDBC
> using the Java sql type 'OTHER':
> Object data = "\{...}"; // the JSON document
> PreparedStatement.setObject(1, data, java.sql.Types.OTHER);
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10887) Improve Performance of ReplaceText processor
[
https://issues.apache.org/jira/browse/NIFI-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Payne updated NIFI-10887:
--
Fix Version/s: 1.20.0
> Improve Performance of ReplaceText processor
>
>
> Key: NIFI-10887
> URL: https://issues.apache.org/jira/browse/NIFI-10887
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Labels: performance
> Fix For: 1.20.0
>
> Attachments: ReplaceText-LiteralReplace-0msRunDuration.png,
> ReplaceText-LiteralReplace-25msRunDuration.png,
> ReplaceText-LiteralReplace-AfterChanges.png,
> ReplaceText-LiteralReplace-BeforeChanges.png,
> ReplaceText-RegexReplace-AfterChanges.png,
> ReplaceText-RegexReplace-BeforeChanges.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When performing some tests with the ReplaceText processor, I found that it
> seemed to be quite a bit slower than I expected, especially when using a
> Replacement Strategy of "Literal Replace" and when using a lot of small
> FlowFiles.
> As a result, I performed some profiling and identified a few areas that could
> use some improvement:
> * When using the Literal Replace strategy, we find matches using
> {{Pattern.compile(Pattern.quote(...));}} and then using
> {{{}Pattern.matcher(...).find(){}}}. This is quite inefficient compared to
> just using {{String.indexOf(...)}} and accounted for approximately 30% of the
> time spent in the processor.
> * A significant amount of time was spent flushing the write buffer, as it
> flushes to disk when finished writing to each individual FlowFile. Even when
> we set a Run Duration > 0 ms, we flush for each FlowFile. This flush() gets
> delegated all the way down to the FileOutputStream. However, when using
> ProcessSession.append(), we intercept this with a NonFlushableOutputStream.
> We should do this when calling ProcessSession.write() as well. While it makes
> sense to flush data from the Processor layer's buffer, there's no need to
> flush past the session layer until the session is committed.
> * A decent bit of time was spent in the session's get() method calling
> {{{}final Set set =
> unacknowledgedFlowFiles.computeIfAbsent(connection.getFlowFileQueue(), k ->
> new HashSet<>());{}}}. The time here was spent in StandardFlowFileQueue's
> hashCode() method, which is the JVM default. We can easily implement
> hashCode() to just return the hashCode of the identifier, which is a String.
> This is a pre-computed hashcode so provides constant time of 0 ms (with the
> exception of the method call itself) so eliminates the expense here.
> * When using a Run Duration > 0 ms, we can hold InputStreams open by
> processing multiple FlowFiles in a given Session. This can also significantly
> improve performance. As such, we should make the default run duration 25 ms
> instead of 0 ms.
> * A common pattern with ReplaceText is to prepend text to the beginning of a
> FlowFile, or line. And then use another ReplaceText to append text to the end
> of a FlowFile, or line. We should have a strategy for "Surround" that allow
> us to both Prepend text and Append text. This will result in double the
> performance for this use case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-5901) Write JSON record in database
[
https://issues.apache.org/jira/browse/NIFI-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655587#comment-17655587
]
Christoph Charlet commented on NIFI-5901:
-
Sorry - not sure if I understand this correctly: The idea is that if I have a
MapRecord, with one of the entries being a MapRecord itself, I use some kind of
transformation to convert the sub-record to a string, and then it will work?
(And do we really think that's a great strategy?)
> Write JSON record in database
> -
>
> Key: NIFI-5901
> URL: https://issues.apache.org/jira/browse/NIFI-5901
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Flo Rance
>Assignee: Mike Thomsen
>Priority: Minor
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> It would be good to be able to store a whole json record in databases that
> implement it (e.g. postgresql). This would require to define the field in the
> shema as json/jsonb and then let PutDatabaseRecord inserts the json value in
> the json/jsonb field.
> At the moment, it's possible to store a json/jsonb through Postgresql JDBC
> using the Java sql type 'OTHER':
> Object data = "\{...}"; // the JSON document
> PreparedStatement.setObject(1, data, java.sql.Types.OTHER);
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-9894) Enhance InvokeHTTP process - Send content through body variable
[
https://issues.apache.org/jira/browse/NIFI-9894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655586#comment-17655586
]
Mark Payne commented on NIFI-9894:
--
[~exceptionfactory] I think it's a reasonable improvement to InvokeHTTP.
We already have two properties "Put Response Body In Attribute" and "Request
Body Enabled" that are true/false values.
This is very unfortunate - it would have made much more sense to have these be
values like "Response Body Destination" with values of {{{}FlowFile
Content{}}}, {{{}Attribute{}}}, {{None}} and also allowing Request Body to be
chosen as {{{}Expression Language{}}}, {{{}FlowFIle Content{}}}, or
{{{}None{}}}.
Perhaps as part of 2.0, we could consolidate these together.
> Enhance InvokeHTTP process - Send content through body variable
> ---
>
> Key: NIFI-9894
> URL: https://issues.apache.org/jira/browse/NIFI-9894
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.15.3
>Reporter: Denis Jakupovic
>Priority: Trivial
>
> Hey,
> could you please implement an attribute in the InvokeHTTP processor where the
> processor sends a "body attribute" as raw content instead of the current
> content triggering an InvokeHTTP processor.
> The process of sending JSON files through the processor currently is:
> 1. ReplaceText with content if needed
> 2. Call Invoke HTTP
> 3. Read Reponse variable or the new content created
> 3. ReplaceText with enriched content
> Yes I know in Nifi 1.16 there is are two new processor for enrichment which
> needs then to be merged again. However, by working with a lot of RESTful
> services its quite a pain always to replace the content. The data lineage and
> provenance increases a lot as well.
> imho better process in some use case:
> # InvokeHTTP with attibute as body
> # Read the "original" route instead of the response and read response adde
> attribute. (feature already available)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (NIFI-11031) Intermittent Failures in TestGenerateRecord
[
https://issues.apache.org/jira/browse/NIFI-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Burgess reassigned NIFI-11031:
---
Assignee: Matt Burgess
> Intermittent Failures in TestGenerateRecord
> ---
>
> Key: NIFI-11031
> URL: https://issues.apache.org/jira/browse/NIFI-11031
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: David Handermann
>Assignee: Matt Burgess
>Priority: Major
>
> The {{TestGenerateRecord}} fails intermittently in automated builds with the
> following error:
> {noformat}
> Error:
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText
> Time elapsed: 1.035 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText(TestGenerateRecord.java:237)
> {noformat}
> The problem appears to be related to the supporting Faker service returning
> {{null}} when the code is not expecting any {{null}} values according to the
> {{Null Percentage}} property setting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-11031) Intermittent Failures in TestGenerateRecord
David Handermann created NIFI-11031:
---
Summary: Intermittent Failures in TestGenerateRecord
Key: NIFI-11031
URL: https://issues.apache.org/jira/browse/NIFI-11031
Project: Apache NiFi
Issue Type: Bug
Components: Extensions
Reporter: David Handermann
The {{TestGenerateRecord}} fails intermittently in automated builds with the
following error:
{noformat}
Error:
org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText
Time elapsed: 1.035 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: but was:
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
org.apache.nifi.processors.standard.TestGenerateRecord.testGenerateNullableFieldsZeroNullPercentageSchemaText(TestGenerateRecord.java:237)
{noformat}
The problem appears to be related to the supporting Faker service returning
{{null}} when the code is not expecting any {{null}} values according to the
{{Null Percentage}} property setting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11029) Add Standard XML Parsing to ExtractCCDAAttributes
[
https://issues.apache.org/jira/browse/NIFI-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Burgess updated NIFI-11029:
Fix Version/s: 1.20.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add Standard XML Parsing to ExtractCCDAAttributes
> -
>
> Key: NIFI-11029
> URL: https://issues.apache.org/jira/browse/NIFI-11029
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.20.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ExtractCCDAAttributes}} Processor uses a custom {{CDAUtil}} class to
> load and parse the FlowFile {{InputStream}}. The {{CDAUtil}} class also
> includes a {{load}} method that takes a standard DOM {{Document}}. The
> Processor should be updated to use the standard {{nifi-xml-processing}}
> library for parsing the XML prior to calling {{CDAUtil.load}}.
> In addition to implementing standard XML parsing, the
> {{ExtractCCDAAttributes}} Processor should be deprecated for removal because
> the implementation relies on outdated libraries, and the extensive use of
> FlowFile attributes does not align with best practices for record-oriented
> data handling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11029) Add Standard XML Parsing to ExtractCCDAAttributes
[
https://issues.apache.org/jira/browse/NIFI-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655582#comment-17655582
]
ASF subversion and git services commented on NIFI-11029:
Commit e966336e8966cf0cbbd12a2c4f2d73a7ceb75cd8 in nifi's branch
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e966336e89 ]
NIFI-11029 Added Standard XML parsing to ExtractCCDAAttributes
- Added DeprecationNotice to ExtractCCDAAttributes
Signed-off-by: Matthew Burgess
This closes #6828
> Add Standard XML Parsing to ExtractCCDAAttributes
> -
>
> Key: NIFI-11029
> URL: https://issues.apache.org/jira/browse/NIFI-11029
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ExtractCCDAAttributes}} Processor uses a custom {{CDAUtil}} class to
> load and parse the FlowFile {{InputStream}}. The {{CDAUtil}} class also
> includes a {{load}} method that takes a standard DOM {{Document}}. The
> Processor should be updated to use the standard {{nifi-xml-processing}}
> library for parsing the XML prior to calling {{CDAUtil.load}}.
> In addition to implementing standard XML parsing, the
> {{ExtractCCDAAttributes}} Processor should be deprecated for removal because
> the implementation relies on outdated libraries, and the extensive use of
> FlowFile attributes does not align with best practices for record-oriented
> data handling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] mattyb149 closed pull request #6828: NIFI-11029 Add Standard XML parsing to ExtractCCDAAttributes
mattyb149 closed pull request #6828: NIFI-11029 Add Standard XML parsing to ExtractCCDAAttributes URL: https://github.com/apache/nifi/pull/6828 -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] mattyb149 commented on pull request #6828: NIFI-11029 Add Standard XML parsing to ExtractCCDAAttributes
mattyb149 commented on PR #6828: URL: https://github.com/apache/nifi/pull/6828#issuecomment-1374136810 +1 LGTM, thanks for the improvement! Merging to main -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655574#comment-17655574 ] Greg Konar commented on NIFI-10582: --- Template name is: *Reproduce_NiFi_Error.xml* > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, Reproduce_NiFi_Error.xml, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Konar updated NIFI-10582: -- Attachment: Reproduce_NiFi_Error.xml > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, Reproduce_NiFi_Error.xml, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nissim Shiman updated NIFI-10772:
-
Status: Patch Available (was: Open)
> Unattributable error on nifi shutdown when controller service was unable to
> be started
> --
>
> Key: NIFI-10772
> URL: https://issues.apache.org/jira/browse/NIFI-10772
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.18.0, 1.20.0
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This error occurs when nifi is unable to start a controller service that is
> supposed to be in an enabled state. On shutdown, nifi will give an error
> (stacktrace below)
> To reproduce, for example using, StandardRestrictedSSLContextService:
> Enable StandardRestrictedSSLContextService
> Shutdown nifi
> remove keystore StandardRestrictedSSLContextService relied on (or move it to
> different location on filesystem)
> start nifi
> stop nifi
> When nifi is shutdown the following uncaught/non-attributable error is in
> nifi-app.log:
> {code:java}
> 2023-01-06 15:46:41,085 ERROR [Timer-Driven Process Thread-5]
> org.apache.nifi.engine.FlowEngine Uncaught Exception in Runnable task
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2867c735
> rejected from org.apache.nifi.e
> ngine.FlowEngine@a814d7d[Shutting down, pool size = 10, active threads = 3,
> queued tasks = 0, completed tasks = 257823]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
> at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
> at
> org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> {code}
> It is unclear from the current log output as to what the underlying cause of
> it was (i.e. which controller service StandardControllerServiceNode is having
> trouble with)
> A similar non-attributable error is also seen on nifi shutdown for a
> processor that relies on this controller service.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] NissimShiman opened a new pull request, #6829: NIFI-10772 Clarify logs on shutdown where controller service and/or processor were unable to start
NissimShiman opened a new pull request, #6829: URL: https://github.com/apache/nifi/pull/6829 # Summary [NIFI-10772](https://issues.apache.org/jira/browse/NIFI-10772) This handles some uncaught exceptions seen at nifi shutdown having a vague root cause. Exceptions are caught with logging added to allow nifi admins to identify and correct underlying issue(s). # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [ ] Pull Request based on current revision of the `main` branch - [ ] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 8 - [ ] JDK 11 - [ ] JDK 17 ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655571#comment-17655571 ] Greg Konar commented on NIFI-10582: --- [~dstiegli1] Please do not close this yet. I have attached a template that will demonstrate the load issue I encountered (JSON to SQL and database references were removed as the failure occurred prior to those processors). The error appears in *Convert Delimited to JSON Format* as there are not enough fields available since the line was split. This does not occur when I pre-process all .SVG using a bash shell script and xsltproc uses ** prior to loading the files with NiFi. I would like to stop using the bash shell script workaround. > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] exceptionfactory commented on a diff in pull request #6779: NIFI-10975 Add Kubernetes Leader Election and State Provider
exceptionfactory commented on code in PR #6779:
URL: https://github.com/apache/nifi/pull/6779#discussion_r1063741104
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/StandardNiFiServiceFacade.java:
##
@@ -6261,8 +6261,8 @@ private Set getRoles(final NodeIdentifier nodeId)
{
final String nodeAddress = nodeId.getSocketAddress() + ":" +
nodeId.getSocketPort();
for (final String roleName : ClusterRoles.getAllRoles()) {
-final String leader = leaderElectionManager.getLeader(roleName);
-if (leader == null) {
+final Optional leader =
leaderElectionManager.getLeader(roleName);
Review Comment:
Thanks for catching that, I missed pushing that change through to that
comparison. Will push a correction.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] markap14 commented on a diff in pull request #6779: NIFI-10975 Add Kubernetes Leader Election and State Provider
markap14 commented on code in PR #6779:
URL: https://github.com/apache/nifi/pull/6779#discussion_r1063739074
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/StandardNiFiServiceFacade.java:
##
@@ -6261,8 +6261,8 @@ private Set getRoles(final NodeIdentifier nodeId)
{
final String nodeAddress = nodeId.getSocketAddress() + ":" +
nodeId.getSocketPort();
for (final String roleName : ClusterRoles.getAllRoles()) {
-final String leader = leaderElectionManager.getLeader(roleName);
-if (leader == null) {
+final Optional leader =
leaderElectionManager.getLeader(roleName);
Review Comment:
The change to `Optional` here means that below, in line 6269, we are
calling `leader.equals(nodeAddress)` which compares a `String` to an
`Optional` - need to ensure that we call `get()` first. As-is, the
cluster page shows the nodes are connected but doesn't show which is Cluster
Coordinator and which is primary node (though the nodes do appear to function
in those roles properly).
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (NIFI-11029) Add Standard XML Parsing to ExtractCCDAAttributes
[
https://issues.apache.org/jira/browse/NIFI-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-11029:
Status: Patch Available (was: Open)
> Add Standard XML Parsing to ExtractCCDAAttributes
> -
>
> Key: NIFI-11029
> URL: https://issues.apache.org/jira/browse/NIFI-11029
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ExtractCCDAAttributes}} Processor uses a custom {{CDAUtil}} class to
> load and parse the FlowFile {{InputStream}}. The {{CDAUtil}} class also
> includes a {{load}} method that takes a standard DOM {{Document}}. The
> Processor should be updated to use the standard {{nifi-xml-processing}}
> library for parsing the XML prior to calling {{CDAUtil.load}}.
> In addition to implementing standard XML parsing, the
> {{ExtractCCDAAttributes}} Processor should be deprecated for removal because
> the implementation relies on outdated libraries, and the extensive use of
> FlowFile attributes does not align with best practices for record-oriented
> data handling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] exceptionfactory opened a new pull request, #6828: NIFI-11029 Add Standard XML parsing to ExtractCCDAAttributes
exceptionfactory opened a new pull request, #6828: URL: https://github.com/apache/nifi/pull/6828 # Summary [NIFI-11029](https://issues.apache.org/jira/browse/NIFI-11029) Adds standard XML parsing to `ExtractCCDAAttributes` using the `nifi-xml-processing` library and includes an additional unit test for invalid documents. Additional changes include adding the `DeprecationNotice` annotation to `ExtractCCDAAttributes`, recommending that usage of the Processor should be changed to record-oriented handling. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [X] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [X] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [X] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [X] Pull Request based on current revision of the `main` branch - [X] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 8 - [ ] JDK 11 - [ ] JDK 17 ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (NIFI-11030) Refactor nifi-stateless-processor-bundle to use JUnit5
Nissim Shiman created NIFI-11030: Summary: Refactor nifi-stateless-processor-bundle to use JUnit5 Key: NIFI-11030 URL: https://issues.apache.org/jira/browse/NIFI-11030 Project: Apache NiFi Issue Type: Sub-task Reporter: Nissim Shiman Assignee: Nissim Shiman -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11029) Add Standard XML Parsing to ExtractCCDAAttributes
David Handermann created NIFI-11029:
---
Summary: Add Standard XML Parsing to ExtractCCDAAttributes
Key: NIFI-11029
URL: https://issues.apache.org/jira/browse/NIFI-11029
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Reporter: David Handermann
Assignee: David Handermann
The {{ExtractCCDAAttributes}} Processor uses a custom {{CDAUtil}} class to load
and parse the FlowFile {{InputStream}}. The {{CDAUtil}} class also includes a
{{load}} method that takes a standard DOM {{Document}}. The Processor should be
updated to use the standard {{nifi-xml-processing}} library for parsing the XML
prior to calling {{CDAUtil.load}}.
In addition to implementing standard XML parsing, the {{ExtractCCDAAttributes}}
Processor should be deprecated for removal because the implementation relies on
outdated libraries, and the extensive use of FlowFile attributes does not align
with best practices for record-oriented data handling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11019) Refactor nifi-scripting bundle to Junit 5 - Part 2
[ https://issues.apache.org/jira/browse/NIFI-11019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11019: Fix Version/s: 1.20.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Refactor nifi-scripting bundle to Junit 5 - Part 2 > -- > > Key: NIFI-11019 > URL: https://issues.apache.org/jira/browse/NIFI-11019 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Nissim Shiman >Assignee: Nissim Shiman >Priority: Major > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a continuation of NIFI-9148 for a small number of files that look > like they were not yet in main when this was done. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11019) Refactor nifi-scripting bundle to Junit 5 - Part 2
[ https://issues.apache.org/jira/browse/NIFI-11019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655526#comment-17655526 ] ASF subversion and git services commented on NIFI-11019: Commit 9252dcbc763865962377a190560232a32f24d1cd in nifi's branch refs/heads/main from Nissim Shiman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=9252dcbc76 ] NIFI-11019 Converted remaining nifi-scripting tests to JUnit 5 This closes #6824 Signed-off-by: David Handermann > Refactor nifi-scripting bundle to Junit 5 - Part 2 > -- > > Key: NIFI-11019 > URL: https://issues.apache.org/jira/browse/NIFI-11019 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Nissim Shiman >Assignee: Nissim Shiman >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > This is a continuation of NIFI-9148 for a small number of files that look > like they were not yet in main when this was done. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] exceptionfactory closed pull request #6824: NIFI-11019 Convert JUnit4 to JUnit5 - scripting processors (Part 2)
exceptionfactory closed pull request #6824: NIFI-11019 Convert JUnit4 to JUnit5 - scripting processors (Part 2) URL: https://github.com/apache/nifi/pull/6824 -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on pull request #6823: NIFI-9167 Converted remaining nifi-framework tests to JUnit 5
exceptionfactory commented on PR #6823: URL: https://github.com/apache/nifi/pull/6823#issuecomment-1373918612 Thanks for the detailed and helpful feedback @dan-s1! I pushed changes to include using the `TempDir` annotation, and also adjusted the `TestConnectionStatusAnalytics` class to remove the unnecessary casting in multiple places. -- 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (NIFI-11028) Handle controller service 'Scheduled State' after upgrade to NiFi 1.16
Zsihovszki Krisztina created NIFI-11028:
---
Summary: Handle controller service 'Scheduled State' after upgrade
to NiFi 1.16
Key: NIFI-11028
URL: https://issues.apache.org/jira/browse/NIFI-11028
Project: Apache NiFi
Issue Type: Bug
Components: NiFi Registry
Affects Versions: 1.16.0
Reporter: Zsihovszki Krisztina
It is not possible to revert local changes on an upgraded flow if the
controller services are enabled. The following error is reported: "Cannot
modify Controller Service configuration because it is currently enabled. Please
disable the Controller Service first."
The "Scheduled State" of a controller service was not stored prior to 1.16.
When NiFi is upgraded from an earlier version to 1.16, the stored "Scheduled
State" of controller services in the flow is "null", while the actual (local)
scheduled state is ENABLED/DISABLED (both is mapped to DISABLED at comparison).
When "Revert local changes" is selected, the "Scheduled State" change is noted
as a difference between the proposed and currently loaded flow.
{code:java}
Controller Service 10f21a4c-194f-34c2-8cfc-97892f73d3ec has a Scheduled State
of null in Proposed Flow but DISABLED in Currently Loaded Flow{code}
Since it's considered a local change, the controller service is not disabled
before the flow is synchronized and when synchronization takes place, the
"Cannot modify Controller Service configuration because it is currently
enabled. Please disable the Controller Service first." occurs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (NIFI-11028) Handle controller service 'Scheduled State' after upgrade to NiFi 1.16
[
https://issues.apache.org/jira/browse/NIFI-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsihovszki Krisztina reassigned NIFI-11028:
---
Assignee: Zsihovszki Krisztina
> Handle controller service 'Scheduled State' after upgrade to NiFi 1.16
> --
>
> Key: NIFI-11028
> URL: https://issues.apache.org/jira/browse/NIFI-11028
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.16.0
>Reporter: Zsihovszki Krisztina
>Assignee: Zsihovszki Krisztina
>Priority: Major
>
> It is not possible to revert local changes on an upgraded flow if the
> controller services are enabled. The following error is reported: "Cannot
> modify Controller Service configuration because it is currently enabled.
> Please disable the Controller Service first."
> The "Scheduled State" of a controller service was not stored prior to 1.16.
> When NiFi is upgraded from an earlier version to 1.16, the stored "Scheduled
> State" of controller services in the flow is "null", while the actual
> (local) scheduled state is ENABLED/DISABLED (both is mapped to DISABLED at
> comparison).
> When "Revert local changes" is selected, the "Scheduled State" change is
> noted as a difference between the proposed and currently loaded flow.
>
> {code:java}
> Controller Service 10f21a4c-194f-34c2-8cfc-97892f73d3ec has a Scheduled State
> of null in Proposed Flow but DISABLED in Currently Loaded Flow{code}
> Since it's considered a local change, the controller service is not disabled
> before the flow is synchronized and when synchronization takes place, the
> "Cannot modify Controller Service configuration because it is currently
> enabled. Please disable the Controller Service first." occurs.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] lordgamez commented on a diff in pull request #1460: MINIFICPP-1995 Add configuring path for flowfile_checkpoint directory
lordgamez commented on code in PR #1460:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1460#discussion_r1063609446
##
libminifi/include/core/logging/Logger.h:
##
@@ -72,6 +76,8 @@ inline decltype(auto) conditional_convert(const Arg& val) {
return val;
} else if constexpr (std::is_same_v().c_str()), const char*>) {
return val.c_str();
+ } else if constexpr (std::is_same_v().string()), std::string>) {
+return val.string().c_str();
Review Comment:
Good catch, updated in fb658f6abd33164157570344436dddae13700823
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655476#comment-17655476 ] Daniel Stieglitz edited comment on NIFI-10582 at 1/6/23 4:54 PM: - [~gkonar] I tested this on Linux using JDK 8 and the 1.20.0-SNAPSHOT and I cannot reproduce this error when I run the transform against both sample files 14_R01.svg and 21_R01.svg. was (Author: JIRAUSER294662): [~gkonar] I tested this on Linux with the 1.20.0-SNAPSHOT and I cannot reproduce this error when I run the transform against both sample files 14_R01.svg and 21_R01.svg. > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655509#comment-17655509
]
Nissim Shiman commented on NIFI-10772:
--
Here is the stack trace (also uncaught/unattributable) on nifi shutdown when a
processor relies on a controller service in the state mention above
{code:java}
2023-01-06 15:46:40,492 ERROR [Monitor Processor Lifecycle Thread-2]
org.apache.nifi.engine.FlowEngine Uncaught Exception in Runnable task
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@398f32ee
rejected from org.apache.nifi.engine.FlowEngine@a814d7d[Shutting down, pool
size = 10, active threads = 0, queued tasks = 3, completed tasks = 257823]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:102)
at
java.util.concurrent.ScheduledThreadPoolExecutor.submit(ScheduledThreadPoolExecutor.java:648)
at
org.apache.nifi.controller.scheduling.StandardProcessScheduler$4.scheduleTask(StandardProcessScheduler.java:350)
at
org.apache.nifi.controller.StandardProcessorNode.initiateStart(StandardProcessorNode.java:1803)
at
org.apache.nifi.controller.StandardProcessorNode.lambda$null$6(StandardProcessorNode.java:1715)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
To see this, do the following steps (similar to those in ticket description
above):
Enable StandardRestrictedSSLContextService
Create ListenHTTP processor
set processor's SSL Context Service to use StandardRestrictedSSLContextService
just enabled
Start ListenHTTP
Shutdown nifi
remove keystore StandardRestrictedSSLContextService relied on (or move it to
different location on filesystem)
start nifi
stop nifi
Two errors will be seen, one for the controller service and one for the
processor.
> Unattributable error on nifi shutdown when controller service was unable to
> be started
> --
>
> Key: NIFI-10772
> URL: https://issues.apache.org/jira/browse/NIFI-10772
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.18.0, 1.20.0
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
>
> This error occurs when nifi is unable to start a controller service that is
> supposed to be in an enabled state. On shutdown, nifi will give an error
> (stacktrace below)
> To reproduce, for example using, StandardRestrictedSSLContextService:
> Enable StandardRestrictedSSLContextService
> Shutdown nifi
> remove keystore StandardRestrictedSSLContextService relied on (or move it to
> different location on filesystem)
> start nifi
> stop nifi
> When nifi is shutdown the following uncaught/non-attributable error is in
> nifi-app.log:
> {code:java}
> 2023-01-06 15:46:41,085 ERROR [Timer-Driven Process Thread-5]
> org.apache.nifi.engine.FlowEngine Uncaught Exception in Runnable task
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2867c735
> rejected from org.apache.nifi.e
> ngine.FlowEngine@a814d7d[Shutting down, pool size = 10, active threads = 3,
> queued tasks = 0, completed tasks = 257823]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
> at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
>
[jira] [Updated] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nissim Shiman updated NIFI-10772:
-
Description:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardRestrictedSSLContextService:
Enable StandardRestrictedSSLContextService
Shutdown nifi
remove keystore StandardRestrictedSSLContextService relied on (or move it to
different location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following uncaught/non-attributable error is in
nifi-app.log:
{code:java}
2023-01-06 15:46:41,085 ERROR [Timer-Driven Process Thread-5]
org.apache.nifi.engine.FlowEngine Uncaught Exception in Runnable task
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2867c735
rejected from org.apache.nifi.e
ngine.FlowEngine@a814d7d[Shutting down, pool size = 10, active threads = 3,
queued tasks = 0, completed tasks = 257823]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was (i.e. which controller service StandardControllerServiceNode is having
trouble with)
A similar non-attributable error is also seen on nifi shutdown for a processor
that relies on this controller service.
was:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardRestrictedSSLContextService:
Enable StandardRestrictedSSLContextService
Shutdown nifi
remove keystore StandardRestrictedSSLContextService relied on (or move it to
different location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following non-attributable error is in nifi-app.log:
{code:java}
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1c5f3492
rejected from org.apache.nifi.engine.FlowEngine@1298c969[Shutting down, pool
size = 10, active threads = 1, queued tasks = 0, completed tasks = 54]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to
[jira] [Updated] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nissim Shiman updated NIFI-10772:
-
Description:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardRestrictedSSLContextService:
Enable StandardRestrictedSSLContextService
Shutdown nifi
remove keystore StandardRestrictedSSLContextService relied on (or move it to
different location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following non-attributable error is in nifi-app.log:
{code:java}
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1c5f3492
rejected from org.apache.nifi.engine.FlowEngine@1298c969[Shutting down, pool
size = 10, active threads = 1, queued tasks = 0, completed tasks = 54]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was (i.e. which controller service StandardControllerServiceNode is having
trouble with)
A similar non-attributable error is also seen on nifi shutdown for a processor
that relies on this controller service.
was:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardSSLContextService:
Enable StandardSSLContextService
Shutdown nifi
remove keystore StandardSSLContextService relied on (or move it to different
location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following non-attributable error is in nifi-app.log:
{code:java}
2023-01-06 15:46:41,085 ERROR [Timer-Driven Process Thread-5]
org.apache.nifi.engine.FlowEngine Uncaught Exception in Runnable task
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2867c735
rejected from org.apache.nifi.e
ngine.FlowEngine@a814d7d[Shutting down, pool size = 10, active threads = 3,
queued tasks = 0, completed tasks = 257823]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was
[jira] [Updated] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nissim Shiman updated NIFI-10772:
-
Description:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardSSLContextService:
Enable StandardSSLContextService
Shutdown nifi
remove keystore StandardSSLContextService relied on (or move it to different
location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following non-attributable error is in nifi-app.log:
{code:java}
2023-01-06 15:46:41,085 ERROR [Timer-Driven Process Thread-5]
org.apache.nifi.engine.FlowEngine Uncaught Exception in Runnable task
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@2867c735
rejected from org.apache.nifi.e
ngine.FlowEngine@a814d7d[Shutting down, pool size = 10, active threads = 3,
queued tasks = 0, completed tasks = 257823]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was (i.e. which controller service StandardControllerServiceNode is having
trouble with)
A similar non-attributable error is also seen on nifi shutdown for a processor
that relies on this controller service.
was:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardSSLContextService:
Enable StandardSSLContextService
Shutdown nifi
remove keystore StandardSSLContextService relied on (or move it to different
location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following non-attributable error is in nifi-app.log:
{code:java}
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1c5f3492
rejected from org.apache.nifi.engine.FlowEngine@1298c969[Shutting down, pool
size = 10, active threads = 1, queued tasks = 0, completed tasks = 54]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was (i.e. which controller
[jira] [Updated] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nissim Shiman updated NIFI-10772:
-
Affects Version/s: 1.20.0
> Unattributable error on nifi shutdown when controller service was unable to
> be started
> --
>
> Key: NIFI-10772
> URL: https://issues.apache.org/jira/browse/NIFI-10772
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.18.0, 1.20.0
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
>
> This error occurs when nifi is unable to start a controller service that is
> supposed to be in an enabled state. On shutdown, nifi will give an error
> (stacktrace below)
> To reproduce, for example using, StandardSSLContextService:
> Enable StandardSSLContextService
> Shutdown nifi
> remove keystore StandardSSLContextService relied on (or move it to different
> location on filesystem)
> start nifi
> stop nifi
> When nifi is shutdown the following non-attributable error is in nifi-app.log:
> {code:java}
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1c5f3492
> rejected from org.apache.nifi.engine.FlowEngine@1298c969[Shutting down, pool
> size = 10, active threads = 1, queued tasks = 0, completed tasks = 54]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
> at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
> at
> org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> {code}
> It is unclear from the current log output as to what the underlying cause of
> it was (i.e. which controller service StandardControllerServiceNode is having
> trouble with)
> A similar non-attributable error is also seen on nifi shutdown for a
> processor that relies on this controller service.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1473: MINIFICPP-1973 Refactor ResourceQueue
szaszm commented on code in PR #1473:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1473#discussion_r1063538202
##
libminifi/include/utils/ResourceQueue.h:
##
@@ -126,7 +137,10 @@ struct ResourceQueue::make_shared_enabler :
public ResourceQueue
-auto ResourceQueue::create(std::optional
maximum_number_of_creatable_resources, std::shared_ptr
logger) {
- return
std::make_shared(maximum_number_of_creatable_resources,
std::move(logger));
+auto
ResourceQueue::create(std::function()>
creator,
+ std::optional
maximum_number_of_creatable_resources,
+
std::optional> reset_fn,
+
std::shared_ptr logger) {
+ return std::make_shared(std::move(creator),
maximum_number_of_creatable_resources, std::move(reset_fn), std::move(logger));
Review Comment:
My bad, thanks for the clarification.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655476#comment-17655476 ] Daniel Stieglitz edited comment on NIFI-10582 at 1/6/23 3:28 PM: - [~gkonar] I tested this on Linux with the 1.20.0-SNAPSHOT and I cannot reproduce this error when I run the transform against both sample files 14_R01.svg and 21_R01.svg. was (Author: JIRAUSER294662): [~gkonar] I tested this on Linux with the 1.20.0-SNAPSHOT and I cannot reproduce this error. > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655476#comment-17655476 ] Daniel Stieglitz edited comment on NIFI-10582 at 1/6/23 3:22 PM: - [~gkonar] I tested this on Linux with the 1.20.0-SNAPSHOT and I cannot reproduce this error. was (Author: JIRAUSER294662): [~gkonar] I tested this on Linux and I cannot reproduce this error. > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655476#comment-17655476 ] Daniel Stieglitz commented on NIFI-10582: - [~gkonar] I tested this on Linux and I cannot reproduce this error. > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10582) XSLT element does not work in NiFi 1.15.3
[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655471#comment-17655471 ] Greg Konar commented on NIFI-10582: --- [~dstiegli1] Unfortunately, I do not see any stack traces in the logs that I can include. Sorry. > XSLT element does not work in NiFi 1.15.3 > --- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) >Reporter: Greg Konar >Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using ** in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10772) Unattributable error on nifi shutdown when controller service was unable to be started
[
https://issues.apache.org/jira/browse/NIFI-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nissim Shiman updated NIFI-10772:
-
Description:
This error occurs when nifi is unable to start a controller service that is
supposed to be in an enabled state. On shutdown, nifi will give an error
(stacktrace below)
To reproduce, for example using, StandardSSLContextService:
Enable StandardSSLContextService
Shutdown nifi
remove keystore StandardSSLContextService relied on (or move it to different
location on filesystem)
start nifi
stop nifi
When nifi is shutdown the following non-attributable error is in nifi-app.log:
{code:java}
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1c5f3492
rejected from org.apache.nifi.engine.FlowEngine@1298c969[Shutting down, pool
size = 10, active threads = 1, queued tasks = 0, completed tasks = 54]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was (i.e. which controller service StandardControllerServiceNode is having
trouble with)
A similar non-attributable error is also seen on nifi shutdown for a processor
that relies on this controller service.
was:
This error occurs when nifi is unable to start an controller service that is
supposed to be in an enabled state.
For example, if the StandardSSLContextService is running, but the underlying
keystore file it relies on is removed from the filesystem, nifi will be unable
to successfully start it on a nifi restart.
When nifi is shutdown the following error is in nifi-app.log:
{code}
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1c5f3492
rejected from org.apache.nifi.engine.FlowEngine@1298c969[Shutting down, pool
size = 10, active threads = 1, queued tasks = 0, completed tasks = 54]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
at org.apache.nifi.engine.FlowEngine.schedule(FlowEngine.java:87)
at
org.apache.nifi.controller.service.StandardControllerServiceNode$2.run(StandardControllerServiceNode.java:591)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
{code}
It is unclear from the current log output as to what the underlying cause of it
was (i.e. which controller service StandardControllerServiceNode is having
trouble with)
> Unattributable error on nifi shutdown when controller service was unable to
> be started
> --
>
>
[GitHub] [nifi] dan-s1 commented on a diff in pull request #6823: NIFI-9167 Converted remaining nifi-framework tests to JUnit 5
dan-s1 commented on code in PR #6823:
URL: https://github.com/apache/nifi/pull/6823#discussion_r1063479870
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/test/java/org/apache/nifi/controller/status/analytics/TestConnectionStatusAnalytics.java:
##
@@ -383,48 +360,48 @@ public void testGetNextIntervalPercentageUseBytes() {
ConnectionStatusAnalytics connectionStatusAnalytics =
getConnectionStatusAnalytics(modelMap);
Long percentage =
connectionStatusAnalytics.getNextIntervalPercentageUseBytes(connection,
flowFileEvent);
assertNotNull(percentage);
-assert (percentage == 10);
+assertEquals(10, percentage);
}
@Test
public void testGetScores() {
Date now = new Date();
-Long tomorrowMillis =
DateUtils.addDays(now,1).toInstant().toEpochMilli();
-Map>
bytesModelMap =
getModelMap("queuedBytes",.9,1000.0,tomorrowMillis.doubleValue());
-Map>
countModelMap = getModelMap("queuedCount",.9,50.0,tomorrowMillis.doubleValue());
+long tomorrowMillis =
DateUtils.addDays(now,1).toInstant().toEpochMilli();
+Map>
bytesModelMap = getModelMap("queuedBytes",.9,1000.0, (double)
tomorrowMillis);
+Map>
countModelMap = getModelMap("queuedCount",.9,50.0, (double) tomorrowMillis);
countModelMap.putAll(bytesModelMap);
ConnectionStatusAnalytics connectionStatusAnalytics =
getConnectionStatusAnalytics(countModelMap);
connectionStatusAnalytics.loadPredictions(repositoryStatusReport);
Map scores = connectionStatusAnalytics.getPredictions();
assertNotNull(scores);
assertFalse(scores.isEmpty());
-assertTrue(scores.get("nextIntervalPercentageUseCount").equals(50L));
-assertTrue(scores.get("nextIntervalBytes").equals(1000L));
+assertEquals(50L, (long) scores.get("nextIntervalPercentageUseCount"));
+assertEquals(1000L, (long) scores.get("nextIntervalBytes"));
Review Comment:
Casts are not necessary as it is coming from a Map whose values are of type
Long.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] dan-s1 commented on a diff in pull request #6823: NIFI-9167 Converted remaining nifi-framework tests to JUnit 5
dan-s1 commented on code in PR #6823:
URL: https://github.com/apache/nifi/pull/6823#discussion_r1063478024
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/test/java/org/apache/nifi/controller/status/analytics/TestConnectionStatusAnalytics.java:
##
@@ -383,48 +360,48 @@ public void testGetNextIntervalPercentageUseBytes() {
ConnectionStatusAnalytics connectionStatusAnalytics =
getConnectionStatusAnalytics(modelMap);
Long percentage =
connectionStatusAnalytics.getNextIntervalPercentageUseBytes(connection,
flowFileEvent);
assertNotNull(percentage);
-assert (percentage == 10);
+assertEquals(10, percentage);
}
@Test
public void testGetScores() {
Date now = new Date();
-Long tomorrowMillis =
DateUtils.addDays(now,1).toInstant().toEpochMilli();
-Map>
bytesModelMap =
getModelMap("queuedBytes",.9,1000.0,tomorrowMillis.doubleValue());
-Map>
countModelMap = getModelMap("queuedCount",.9,50.0,tomorrowMillis.doubleValue());
+long tomorrowMillis =
DateUtils.addDays(now,1).toInstant().toEpochMilli();
+Map>
bytesModelMap = getModelMap("queuedBytes",.9,1000.0, (double)
tomorrowMillis);
+Map>
countModelMap = getModelMap("queuedCount",.9,50.0, (double) tomorrowMillis);
Review Comment:
Instead of assigning `tomorrowMillis` as a long you could assign it as as a
Long and then call doubleValue() on it on lines 370 and 371 instead of casting.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] dan-s1 commented on a diff in pull request #6823: NIFI-9167 Converted remaining nifi-framework tests to JUnit 5
dan-s1 commented on code in PR #6823:
URL: https://github.com/apache/nifi/pull/6823#discussion_r1062980880
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/test/java/org/apache/nifi/nar/AbstractNativeLibHandlingClassLoaderTest.java:
##
@@ -61,13 +64,12 @@ public class AbstractNativeLibHandlingClassLoaderTest {
private boolean isOsMaxOsx;
private boolean isOsLinux;
-@Before
+@BeforeEach
public void setUp() throws Exception {
-initMocks(this);
tempDirectory =
Files.createTempDirectory(this.getClass().getSimpleName());
Review Comment:
Shouldn't Junit 5 `@TempDir` be used for this i.e. annotate the variable
tempDirectory with it on line 56?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] adamdebreceni commented on a diff in pull request #1460: MINIFICPP-1995 Add configuring path for flowfile_checkpoint directory
adamdebreceni commented on code in PR #1460:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1460#discussion_r1063442029
##
libminifi/include/core/logging/Logger.h:
##
@@ -72,6 +76,8 @@ inline decltype(auto) conditional_convert(const Arg& val) {
return val;
} else if constexpr (std::is_same_v().c_str()), const char*>) {
return val.c_str();
+ } else if constexpr (std::is_same_v().string()), std::string>) {
+return val.string().c_str();
Review Comment:
the `::string() const` method could return a temporary which is destroyed
before using the result of `c_str()` leaving us with UB, I think for this to be
safe, the `conditional_stringify` functions should call the `::string() const`
method, the returned temporary string is kept alive until the end of the full
expression the `conditional_stringify` is part of, which is after
`format_string` returns
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-fds] dependabot[bot] opened a new pull request, #74: Bump json5 and html-webpack-plugin
dependabot[bot] opened a new pull request, #74: URL: https://github.com/apache/nifi-fds/pull/74 Bumps [json5](https://github.com/json5/json5) to 2.2.3 and updates ancestor dependencies [json5](https://github.com/json5/json5), [json5](https://github.com/json5/json5) and [html-webpack-plugin](https://github.com/jantimon/html-webpack-plugin). These dependencies need to be updated together. Updates `json5` from 2.2.0 to 2.2.3 Release notes Sourced from https://github.com/json5/json5/releases;>json5's releases. v2.2.3 Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 Fix: Properties with the name __proto__ are added to objects and arrays. (https://github-redirect.dependabot.com/json5/json5/issues/199;>#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (https://github-redirect.dependabot.com/json5/json5/issues/295;>#295). v2.2.1 Fix: Removed dependence on minimist to patch CVE-2021-44906. (https://github-redirect.dependabot.com/json5/json5/issues/266;>#266) Changelog Sourced from https://github.com/json5/json5/blob/main/CHANGELOG.md;>json5's changelog. v2.2.3 [https://github.com/json5/json5/tree/v2.2.3;>code, https://github.com/json5/json5/compare/v2.2.2...v2.2.3;>diff] Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 [https://github.com/json5/json5/tree/v2.2.2;>code, https://github.com/json5/json5/compare/v2.2.1...v2.2.2;>diff] Fix: Properties with the name __proto__ are added to objects and arrays. (https://github-redirect.dependabot.com/json5/json5/issues/199;>#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (https://github-redirect.dependabot.com/json5/json5/issues/295;>#295). v2.2.1 [https://github.com/json5/json5/tree/v2.2.1;>code, https://github.com/json5/json5/compare/v2.2.0...v2.2.1;>diff] Fix: Removed dependence on minimist to patch CVE-2021-44906. (https://github-redirect.dependabot.com/json5/json5/issues/266;>#266) Commits https://github.com/json5/json5/commit/c3a75242772a5026a49c4017a16d9b3543b62776;>c3a7524 2.2.3 https://github.com/json5/json5/commit/94fd06d82eeed225fa172f6fb2ca27375cbd2e39;>94fd06d docs: update CHANGELOG for v2.2.3 https://github.com/json5/json5/commit/3b8cebf0c474a8b20c78bd75c89cca0c4dce84ce;>3b8cebf docs(security): use GitHub security advisories https://github.com/json5/json5/commit/f0fd9e194dde282caff114a110f4fac635f3a62c;>f0fd9e1 docs: publish a security policy https://github.com/json5/json5/commit/6a91a05fffeda16ff6b3b5008b6b340d42d31ec0;>6a91a05 docs(template): bug - bug report https://github.com/json5/json5/commit/14f8cb186e8abdfaccf6527171da7b1224374650;>14f8cb1 2.2.2 https://github.com/json5/json5/commit/10cc7ca9169b59c5e0f5afc03dbd870cd06bcc46;>10cc7ca docs: update CHANGELOG for v2.2.2 https://github.com/json5/json5/commit/7774c1097993bc3ce9f0ac4b722a32bf7d6871c8;>7774c10 fix: add proto to objects and arrays https://github.com/json5/json5/commit/edde30abd8b22facf2c06c72586b9f6edf12700d;>edde30a Readme: slight tweak to intro https://github.com/json5/json5/commit/97286f8bd542c89dcee096bc05dd28ed2dfc1e16;>97286f8 Improve example in readme Additional commits viewable in https://github.com/json5/json5/compare/v2.2.0...v2.2.3;>compare view Updates `json5` from 1.0.1 to 2.2.3 Release notes Sourced from https://github.com/json5/json5/releases;>json5's releases. v2.2.3 Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 Fix: Properties with the name __proto__ are added to objects and arrays. (https://github-redirect.dependabot.com/json5/json5/issues/199;>#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (https://github-redirect.dependabot.com/json5/json5/issues/295;>#295). v2.2.1 Fix: Removed dependence on minimist to patch CVE-2021-44906. (https://github-redirect.dependabot.com/json5/json5/issues/266;>#266) Changelog Sourced from https://github.com/json5/json5/blob/main/CHANGELOG.md;>json5's changelog. v2.2.3 [https://github.com/json5/json5/tree/v2.2.3;>code, https://github.com/json5/json5/compare/v2.2.2...v2.2.3;>diff] Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 [https://github.com/json5/json5/tree/v2.2.2;>code, https://github.com/json5/json5/compare/v2.2.1...v2.2.2;>diff] Fix:
[GitHub] [nifi-minifi-cpp] martinzink commented on a diff in pull request #1473: MINIFICPP-1973 Refactor ResourceQueue
martinzink commented on code in PR #1473:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1473#discussion_r1063430431
##
libminifi/test/unit/ResourceQueueTests.cpp:
##
@@ -76,20 +81,39 @@ TEST_CASE("Resource limitation is not set to the resource
queue", "[utils::Resou
}
TEST_CASE("resource returns when it goes out of scope",
"[utils::ResourceQueue]") {
- auto queue = utils::ResourceQueue::create(std::nullopt, nullptr);
+ using std::chrono::steady_clock;
+ auto queue = utils::ResourceQueue::create([]{
return
std::make_unique(steady_clock::time_point::min()); });
+ {
+auto resource = queue->getResource();
+CHECK(*resource == steady_clock::time_point::min());
+*resource = steady_clock::now();
+ }
+ {
+auto resource = queue->getResource();
+CHECK(*resource != steady_clock::time_point::min());
+ }
+}
+
+TEST_CASE("resource resets when it goes out of scope",
"[utils::ResourceQueue]") {
+ using std::chrono::steady_clock;
+ auto queue = utils::ResourceQueue::create([]{
return
std::make_unique(steady_clock::time_point::min()); },
+
std::nullopt,
+
[](steady_clock::time_point& resource){ resource =
steady_clock::time_point::max();});
Review Comment:
Good idea, I've changed this and also included some additional checks aswell
in
https://github.com/apache/nifi-minifi-cpp/pull/1473/commits/5279824fbde23389279cce46b2859f979d93044f
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] martinzink commented on a diff in pull request #1473: MINIFICPP-1973 Refactor ResourceQueue
martinzink commented on code in PR #1473:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1473#discussion_r1063421130
##
libminifi/include/utils/ResourceQueue.h:
##
@@ -126,7 +137,10 @@ struct ResourceQueue::make_shared_enabler :
public ResourceQueue
-auto ResourceQueue::create(std::optional
maximum_number_of_creatable_resources, std::shared_ptr
logger) {
- return
std::make_shared(maximum_number_of_creatable_resources,
std::move(logger));
+auto
ResourceQueue::create(std::function()>
creator,
+ std::optional
maximum_number_of_creatable_resources,
+
std::optional> reset_fn,
+
std::shared_ptr logger) {
+ return std::make_shared(std::move(creator),
maximum_number_of_creatable_resources, std::move(reset_fn), std::move(logger));
Review Comment:
Unfortunetly this cannot be simplified due to
> According to the C++17 Standard (10.3.3 The using declaration):
> 19 A synonym created by a using-declaration has the usual
accessibility for a member-declaration. A using-declarator that names a
constructor does not create a synonym; instead, the additional constructors are
accessible if they would be accessible when used to construct an object of the
corresponding base class, and the accessibility of the using-declaration is
ignored.
I've also created a smaller example in godbolt to double check it
https://godbolt.org/z/rfzsPcT6s
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] dependabot[bot] opened a new pull request, #6827: Bump json5 and html-webpack-plugin in /nifi-registry/nifi-registry-core/nifi-registry-web-ui/src/main
dependabot[bot] opened a new pull request, #6827: URL: https://github.com/apache/nifi/pull/6827 Bumps [json5](https://github.com/json5/json5) to 2.2.3 and updates ancestor dependencies [json5](https://github.com/json5/json5), [json5](https://github.com/json5/json5) and [html-webpack-plugin](https://github.com/jantimon/html-webpack-plugin). These dependencies need to be updated together. Updates `json5` from 2.2.0 to 2.2.3 Release notes Sourced from https://github.com/json5/json5/releases;>json5's releases. v2.2.3 Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 Fix: Properties with the name __proto__ are added to objects and arrays. (https://github-redirect.dependabot.com/json5/json5/issues/199;>#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (https://github-redirect.dependabot.com/json5/json5/issues/295;>#295). v2.2.1 Fix: Removed dependence on minimist to patch CVE-2021-44906. (https://github-redirect.dependabot.com/json5/json5/issues/266;>#266) Changelog Sourced from https://github.com/json5/json5/blob/main/CHANGELOG.md;>json5's changelog. v2.2.3 [https://github.com/json5/json5/tree/v2.2.3;>code, https://github.com/json5/json5/compare/v2.2.2...v2.2.3;>diff] Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 [https://github.com/json5/json5/tree/v2.2.2;>code, https://github.com/json5/json5/compare/v2.2.1...v2.2.2;>diff] Fix: Properties with the name __proto__ are added to objects and arrays. (https://github-redirect.dependabot.com/json5/json5/issues/199;>#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (https://github-redirect.dependabot.com/json5/json5/issues/295;>#295). v2.2.1 [https://github.com/json5/json5/tree/v2.2.1;>code, https://github.com/json5/json5/compare/v2.2.0...v2.2.1;>diff] Fix: Removed dependence on minimist to patch CVE-2021-44906. (https://github-redirect.dependabot.com/json5/json5/issues/266;>#266) Commits https://github.com/json5/json5/commit/c3a75242772a5026a49c4017a16d9b3543b62776;>c3a7524 2.2.3 https://github.com/json5/json5/commit/94fd06d82eeed225fa172f6fb2ca27375cbd2e39;>94fd06d docs: update CHANGELOG for v2.2.3 https://github.com/json5/json5/commit/3b8cebf0c474a8b20c78bd75c89cca0c4dce84ce;>3b8cebf docs(security): use GitHub security advisories https://github.com/json5/json5/commit/f0fd9e194dde282caff114a110f4fac635f3a62c;>f0fd9e1 docs: publish a security policy https://github.com/json5/json5/commit/6a91a05fffeda16ff6b3b5008b6b340d42d31ec0;>6a91a05 docs(template): bug - bug report https://github.com/json5/json5/commit/14f8cb186e8abdfaccf6527171da7b1224374650;>14f8cb1 2.2.2 https://github.com/json5/json5/commit/10cc7ca9169b59c5e0f5afc03dbd870cd06bcc46;>10cc7ca docs: update CHANGELOG for v2.2.2 https://github.com/json5/json5/commit/7774c1097993bc3ce9f0ac4b722a32bf7d6871c8;>7774c10 fix: add proto to objects and arrays https://github.com/json5/json5/commit/edde30abd8b22facf2c06c72586b9f6edf12700d;>edde30a Readme: slight tweak to intro https://github.com/json5/json5/commit/97286f8bd542c89dcee096bc05dd28ed2dfc1e16;>97286f8 Improve example in readme Additional commits viewable in https://github.com/json5/json5/compare/v2.2.0...v2.2.3;>compare view Updates `json5` from 1.0.1 to 2.2.3 Release notes Sourced from https://github.com/json5/json5/releases;>json5's releases. v2.2.3 Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 Fix: Properties with the name __proto__ are added to objects and arrays. (https://github-redirect.dependabot.com/json5/json5/issues/199;>#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (https://github-redirect.dependabot.com/json5/json5/issues/295;>#295). v2.2.1 Fix: Removed dependence on minimist to patch CVE-2021-44906. (https://github-redirect.dependabot.com/json5/json5/issues/266;>#266) Changelog Sourced from https://github.com/json5/json5/blob/main/CHANGELOG.md;>json5's changelog. v2.2.3 [https://github.com/json5/json5/tree/v2.2.3;>code, https://github.com/json5/json5/compare/v2.2.2...v2.2.3;>diff] Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (https://github-redirect.dependabot.com/json5/json5/issues/299;>#299) v2.2.2 [https://github.com/json5/json5/tree/v2.2.2;>code, https://github.com/json5/json5/compare/v2.2.1...v2.2.2;>diff] Fix:
[GitHub] [nifi-minifi-cpp] martinzink commented on a diff in pull request #1473: MINIFICPP-1973 Refactor ResourceQueue
martinzink commented on code in PR #1473:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1473#discussion_r1063401291
##
extensions/splunk/PutSplunkHTTP.cpp:
##
@@ -40,32 +40,26 @@ void PutSplunkHTTP::initialize() {
setSupportedRelationships(relationships());
}
-void PutSplunkHTTP::onSchedule(const std::shared_ptr&
context, const std::shared_ptr& sessionFactory) {
- SplunkHECProcessor::onSchedule(context, sessionFactory);
- client_queue_ =
utils::ResourceQueue::create(getMaxConcurrentTasks(),
logger_);
-}
-
namespace {
std::optional getContentType(core::ProcessContext& context, const
core::FlowFile& flow_file) {
return context.getProperty(PutSplunkHTTP::ContentType) | utils::orElse
([_file] {return flow_file.getAttribute("mime.type");});
}
-std::string getEndpoint(core::ProcessContext& context, const
gsl::not_null>& flow_file, curl::HTTPClient&
client) {
+std::string getEndpoint(core::ProcessContext& context, curl::HTTPClient&
client) {
std::stringstream endpoint;
endpoint << "/services/collector/raw";
std::vector parameters;
- std::string prop_value;
- if (context.getProperty(PutSplunkHTTP::SourceType, prop_value, flow_file)) {
-parameters.push_back("sourcetype=" + client.escape(prop_value));
+ if (auto source_type = context.getProperty(PutSplunkHTTP::SourceType)) {
+parameters.push_back("sourcetype=" + client.escape(*source_type));
}
- if (context.getProperty(PutSplunkHTTP::Source, prop_value, flow_file)) {
-parameters.push_back("source=" + client.escape(prop_value));
+ if (auto source = context.getProperty(PutSplunkHTTP::Source)) {
+parameters.push_back("source=" + client.escape(*source));
}
- if (context.getProperty(PutSplunkHTTP::Host, prop_value, flow_file)) {
-parameters.push_back("host=" + client.escape(prop_value));
+ if (auto host = context.getProperty(PutSplunkHTTP::Host)) {
+parameters.push_back("host=" + client.escape(*host));
}
- if (context.getProperty(PutSplunkHTTP::Index, prop_value, flow_file)) {
-parameters.push_back("index=" + client.escape(prop_value));
+ if (auto index = context.getProperty(PutSplunkHTTP::Index)) {
+parameters.push_back("index=" + client.escape(*index));
Review Comment:
Yes, these parameters influence the url which we are uploading to and we
only have a single connection so it shouldnt depend on the incoming flowfile
only the properties of the processor.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] adamdebreceni commented on a diff in pull request #1458: MINIFICPP-1991 - Remove unused ControllerServiceProvider methods
adamdebreceni commented on code in PR #1458:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1458#discussion_r1063394152
##
extensions/http-curl/tests/ControllerServiceIntegrationTests.cpp:
##
@@ -108,27 +108,28 @@ int main(int argc, char **argv) {
assert(ssl_client->getCACertificate().length() > 0);
// now let's disable one of the controller services.
std::shared_ptr cs_id =
controller->getControllerServiceNode("ID");
- const auto checkCsIdEnabledMatchesDisabledFlag = [_id] { return !disabled
== cs_id->enabled(); };
assert(cs_id != nullptr);
- {
-std::lock_guard lock(control_mutex);
-controller->enableControllerService(cs_id);
-disabled = false;
- }
- std::shared_ptr mock_cont =
controller->getControllerServiceNode("MockItLikeIts1995");
- assert(verifyEventHappenedInPollTime(std::chrono::seconds(4),
checkCsIdEnabledMatchesDisabledFlag));
- {
-std::lock_guard lock(control_mutex);
-controller->disableReferencingServices(mock_cont);
-disabled = true;
- }
- assert(verifyEventHappenedInPollTime(std::chrono::seconds(2),
checkCsIdEnabledMatchesDisabledFlag));
- {
-std::lock_guard lock(control_mutex);
-controller->enableReferencingServices(mock_cont);
-disabled = false;
- }
- assert(verifyEventHappenedInPollTime(std::chrono::seconds(2),
checkCsIdEnabledMatchesDisabledFlag));
+ // TODO(adebreceni): MINIFICPP-1992
Review Comment:
thank you for adding it
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] adamdebreceni commented on a diff in pull request #1458: MINIFICPP-1991 - Remove unused ControllerServiceProvider methods
adamdebreceni commented on code in PR #1458:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1458#discussion_r1063392329
##
libminifi/include/core/ProcessGroup.h:
##
@@ -231,7 +231,7 @@ class ProcessGroup : public CoreComponent {
void verify() const;
protected:
- void startProcessingProcessors(const
std::shared_ptr& timeScheduler, const
std::shared_ptr , const
std::shared_ptr ); // NOLINT
+ void startProcessingProcessors(TimerDrivenSchedulingAgent& timeScheduler,
EventDrivenSchedulingAgent& eventScheduler, CronDrivenSchedulingAgent&
cronScheduler); // NOLINT
Review Comment:
removed it
--
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.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] lordgamez opened a new pull request, #1486: MINIFICPP-2026 Make isRunning member functions const
lordgamez opened a new pull request, #1486: URL: https://github.com/apache/nifi-minifi-cpp/pull/1486 https://issues.apache.org/jira/browse/MINIFICPP-2026 --- 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 main)? - [ ] 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 GitHub Actions CI results 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. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MINIFICPP-2026) Make isRunning member functions constant
Gábor Gyimesi created MINIFICPP-2026: Summary: Make isRunning member functions constant Key: MINIFICPP-2026 URL: https://issues.apache.org/jira/browse/MINIFICPP-2026 Project: Apache NiFi MiNiFi C++ Issue Type: Improvement Reporter: Gábor Gyimesi Assignee: Gábor Gyimesi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINIFICPP-1992) ControllerServiceNode should enable its dependencies
[
https://issues.apache.org/jira/browse/MINIFICPP-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655360#comment-17655360
]
Ferenc Gerlits commented on MINIFICPP-1992:
---
There is a TODO in {{ControllerServiceIntegrationTests.cpp}} which should be
fixed as part of this task.
> ControllerServiceNode should enable its dependencies
>
>
> Key: MINIFICPP-1992
> URL: https://issues.apache.org/jira/browse/MINIFICPP-1992
> Project: Apache NiFi MiNiFi C++
> Issue Type: Improvement
>Reporter: Adam Debreceni
>Priority: Major
>
> Linked Services in a ControllerService should be enabled before being able to
> enable the service itself. Similarly disabling a service should first disable
> all its dependents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINIFICPP-1940) Remove unused parameter from FlowConfiguration constructor
[ https://issues.apache.org/jira/browse/MINIFICPP-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gábor Gyimesi updated MINIFICPP-1940: - Fix Version/s: 0.14.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Remove unused parameter from FlowConfiguration constructor > -- > > Key: MINIFICPP-1940 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1940 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Gábor Gyimesi >Assignee: Gábor Gyimesi >Priority: Minor > Labels: MiNiFi-CPP-Hygiene > Fix For: 0.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
