Re: [PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
EndzeitBegins commented on PR #8144: URL: https://github.com/apache/nifi/pull/8144#issuecomment-1846712547 Looks good to me. I followed all the changed links and they're still working. If found some other places in the codebase where older Java versions are mentioned. Maybe we want to update those places as well. However, I'm not sure 21 is required there as well. - [ ] [README.md of nifi-assembly](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-assembly/README.md?plain=1#L71) - [ ] [README.md of minify-assembly](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/minifi/minifi-assembly/README.md?plain=1#L42) - [ ] [README.md of minify-c2-assembly](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/minifi/minifi-c2/minifi-c2-assembly/README.md?plain=1#L29) - [ ] [Admin guide of NiFi registry](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-registry/nifi-registry-core/nifi-registry-docs/src/main/asciidoc/administration-guide.adoc#L26) - [ ] [Admin guide of minify](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/minifi/minifi-docs/src/main/markdown/System_Admin_Guide.md?plain=1#L385) - [ ] [README.md of nifi-registry-assembly](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-registry/nifi-registry-assembly/README.md?plain=1#L28) - [ ] [NiFi in depth contains a keytool example using Java 1.8](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-docs/src/main/asciidoc/nifi-in-depth.adoc#L116) - [ ] [README.md of nifi-registry-web-api](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-registry/nifi-registry-core/nifi-registry-web-api/src/test/resources/keys/README.md?plain=1#L63) I also found some code places with workarounds to be compatible with older Java versions. I think some of those could be removed now, though may be out of scope for this ticket / PR. - [ ] [AllowListClassLoader](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-stateless/nifi-stateless-bootstrap/src/main/java/org/apache/nifi/stateless/bootstrap/AllowListClassLoader.java#L105) - [ ] [KeyStoreUtilsTest](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-security-utils/src/test/java/org/apache/nifi/security/util/KeyStoreUtilsTest.java#L184) -- 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
Re: [PR] Redesign Dec 2023 [nifi-site]
james-elliott closed pull request #77: Redesign Dec 2023 URL: https://github.com/apache/nifi-site/pull/77 -- 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
[PR] Redesign Dec 2023 [nifi-site]
james-elliott opened a new pull request, #77: URL: https://github.com/apache/nifi-site/pull/77 This is a first draft of a continuation of work started by @exceptionfactory. It is a complete overhaul of the look and feel of the NiFi public site. There are major visual changes, and some minor structural and content changes. -- 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-12493) Update Documentation References to Java 21
[ https://issues.apache.org/jira/browse/NIFI-12493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12493: Status: Patch Available (was: Open) > Update Documentation References to Java 21 > -- > > Key: NIFI-12493 > URL: https://issues.apache.org/jira/browse/NIFI-12493 > Project: Apache NiFi > Issue Type: Improvement > Components: Documentation Website >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Several documentation guides and comments various components should be > updated to reference Java 21 as it is the minimum required version for NiFi > 2.0.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
exceptionfactory opened a new pull request, #8144: URL: https://github.com/apache/nifi/pull/8144 # Summary [NIFI-12493](https://issues.apache.org/jira/browse/NIFI-12493) Updates documentation references to indicate that Java 21 is the minimum required version. Additional changes include removing the need to download Apache Maven and instead referencing the Apache Maven Wrapper command. # 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 21 ### 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
[PR] [NIFI-12437] - Summary [nifi]
rfellows opened a new pull request, #8143: URL: https://github.com/apache/nifi/pull/8143 * Processors Status Snapshot Listing * initial processors status snapshot table * sorting * goto processor * multi-valued sort for processors status listing summary * add filtering to the processors status snapshot tab of the summary * created a re-usable summary-table-filter componennt * moved status history to common location * status history * status history chart * resize * display insufficient data message if there isn't enough data to render the history # Summary [NIFI-0](https://issues.apache.org/jira/browse/NIFI-0) # 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 21 ### 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-12493) Update Documentation References to Java 21
David Handermann created NIFI-12493: --- Summary: Update Documentation References to Java 21 Key: NIFI-12493 URL: https://issues.apache.org/jira/browse/NIFI-12493 Project: Apache NiFi Issue Type: Improvement Components: Documentation Website Reporter: David Handermann Assignee: David Handermann Fix For: 2.0.0 Several documentation guides and comments various components should be updated to reference Java 21 as it is the minimum required version for NiFi 2.0.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12481) UI error when listing registry clients and not authorized
[
https://issues.apache.org/jira/browse/NIFI-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Gilman reassigned NIFI-12481:
--
Assignee: Matt Gilman
> UI error when listing registry clients and not authorized
> -
>
> Key: NIFI-12481
> URL: https://issues.apache.org/jira/browse/NIFI-12481
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Bryan Bende
>Assignee: Matt Gilman
>Priority: Major
>
> Currently the authorization for registry clients is based on READ to
> /controller (this is a separate issue that should be addressed).
> Steps:
> * Run a secure instance locally
> * Use initial admin to create a registry client
> * Remove initial admin from controller policies
> * Create a new PG and choose Import from Registry
> * Notice nothing happens
> UI Error in dev tools:
> {code:java}
> nf-canvas-all.js?2.0.0-SNAPSHOT:47 Uncaught TypeError: Cannot read properties
> of undefined (reading 'name')
> at Object. (nf-canvas-all.js?2.0.0-SNAPSHOT:47:3678)
> at Function.each (jquery.min.js:2:3003)
> at b.each (jquery.each.js:1:96)
> at Object. (nf-canvas-all.js?2.0.0-SNAPSHOT:47:3610)
> at c (jquery.min.js:2:28447)
> at Object.fireWith [as resolveWith] (jquery.min.js:2:29192)
> at l (jquery.min.js:2:80176)
> at XMLHttpRequest. (jquery.min.js:2:82630) {code}
> The issue is that the listing of registry clients will optionally fill in the
> DTO in the entity based on the user's permissions for the entity, but the
> permissions are always based on /controller, so if they don't have
> /controller the DTO will be null.
> The UI should still be able to load a screen with an empty list of registry
> clients.
> cc [~mcgilman]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12481) UI error when listing registry clients and not authorized
[
https://issues.apache.org/jira/browse/NIFI-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1779#comment-1779
]
Matt Gilman edited comment on NIFI-12481 at 12/7/23 9:54 PM:
-
The stack trace with non-minified source
{code:java}
Uncaught TypeError: Cannot read properties of undefined (reading 'name')
at nf-flow-version.js?2.0.0-SNAPSHOT:203:40
at Array.sort ()
at Object. (nf-flow-version.js?2.0.0-SNAPSHOT:202:47)
at c (jquery.min.js:2:28447)
at Object.fireWith [as resolveWith] (jquery.min.js:2:29192)
at l (jquery.min.js:2:80176)
at XMLHttpRequest. (jquery.min.js:2:82630) {code}
Sounds like we want to filter out any registry clients where the user lacks
read permissions. We technically already handle the case where there are no
registry clients. We can update this to fall back to the existing behavior once
the unauthorized registry clients have been filtered out.
was (Author: mcgilman):
The stack trace with non-minified source
{code:java}
Uncaught TypeError: Cannot read properties of undefined (reading 'name')
at nf-flow-version.js?2.0.0-SNAPSHOT:203:40
at Array.sort ()
at Object. (nf-flow-version.js?2.0.0-SNAPSHOT:202:47)
at c (jquery.min.js:2:28447)
at Object.fireWith [as resolveWith] (jquery.min.js:2:29192)
at l (jquery.min.js:2:80176)
at XMLHttpRequest. (jquery.min.js:2:82630) {code}
> UI error when listing registry clients and not authorized
> -
>
> Key: NIFI-12481
> URL: https://issues.apache.org/jira/browse/NIFI-12481
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Bryan Bende
>Priority: Major
>
> Currently the authorization for registry clients is based on READ to
> /controller (this is a separate issue that should be addressed).
> Steps:
> * Run a secure instance locally
> * Use initial admin to create a registry client
> * Remove initial admin from controller policies
> * Create a new PG and choose Import from Registry
> * Notice nothing happens
> UI Error in dev tools:
> {code:java}
> nf-canvas-all.js?2.0.0-SNAPSHOT:47 Uncaught TypeError: Cannot read properties
> of undefined (reading 'name')
> at Object. (nf-canvas-all.js?2.0.0-SNAPSHOT:47:3678)
> at Function.each (jquery.min.js:2:3003)
> at b.each (jquery.each.js:1:96)
> at Object. (nf-canvas-all.js?2.0.0-SNAPSHOT:47:3610)
> at c (jquery.min.js:2:28447)
> at Object.fireWith [as resolveWith] (jquery.min.js:2:29192)
> at l (jquery.min.js:2:80176)
> at XMLHttpRequest. (jquery.min.js:2:82630) {code}
> The issue is that the listing of registry clients will optionally fill in the
> DTO in the entity based on the user's permissions for the entity, but the
> permissions are always based on /controller, so if they don't have
> /controller the DTO will be null.
> The UI should still be able to load a screen with an empty list of registry
> clients.
> cc [~mcgilman]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12481) UI error when listing registry clients and not authorized
[
https://issues.apache.org/jira/browse/NIFI-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1779#comment-1779
]
Matt Gilman commented on NIFI-12481:
The stack trace with non-minified source
{code:java}
Uncaught TypeError: Cannot read properties of undefined (reading 'name')
at nf-flow-version.js?2.0.0-SNAPSHOT:203:40
at Array.sort ()
at Object. (nf-flow-version.js?2.0.0-SNAPSHOT:202:47)
at c (jquery.min.js:2:28447)
at Object.fireWith [as resolveWith] (jquery.min.js:2:29192)
at l (jquery.min.js:2:80176)
at XMLHttpRequest. (jquery.min.js:2:82630) {code}
> UI error when listing registry clients and not authorized
> -
>
> Key: NIFI-12481
> URL: https://issues.apache.org/jira/browse/NIFI-12481
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Bryan Bende
>Priority: Major
>
> Currently the authorization for registry clients is based on READ to
> /controller (this is a separate issue that should be addressed).
> Steps:
> * Run a secure instance locally
> * Use initial admin to create a registry client
> * Remove initial admin from controller policies
> * Create a new PG and choose Import from Registry
> * Notice nothing happens
> UI Error in dev tools:
> {code:java}
> nf-canvas-all.js?2.0.0-SNAPSHOT:47 Uncaught TypeError: Cannot read properties
> of undefined (reading 'name')
> at Object. (nf-canvas-all.js?2.0.0-SNAPSHOT:47:3678)
> at Function.each (jquery.min.js:2:3003)
> at b.each (jquery.each.js:1:96)
> at Object. (nf-canvas-all.js?2.0.0-SNAPSHOT:47:3610)
> at c (jquery.min.js:2:28447)
> at Object.fireWith [as resolveWith] (jquery.min.js:2:29192)
> at l (jquery.min.js:2:80176)
> at XMLHttpRequest. (jquery.min.js:2:82630) {code}
> The issue is that the listing of registry clients will optionally fill in the
> DTO in the entity based on the user's permissions for the entity, but the
> permissions are always based on /controller, so if they don't have
> /controller the DTO will be null.
> The UI should still be able to load a screen with an empty list of registry
> clients.
> cc [~mcgilman]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12478) Return Message Type as body for JMS Object Messages
[
https://issues.apache.org/jira/browse/NIFI-12478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Payne updated NIFI-12478:
--
Fix Version/s: 2.0.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Return Message Type as body for JMS Object Messages
> ---
>
> Key: NIFI-12478
> URL: https://issues.apache.org/jira/browse/NIFI-12478
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 2.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The ConsumeJMS Processor supports receiving multiple types of JMS messages
> and implements different serialization strategies for each type of message.
> The JMS ObjectMessage Type provides a generic wrapper around an opaque Java
> Object without any further information. The ConsumeJMS Processor currently
> writes the bytes of an Object using Java Object serialization, which presents
> several issues. Java Object serialization is not compatible with services
> outside of Java, it writes the exact version of the Java Object, and it can
> reference classes that may not be present on the receiving system. This can
> lead to unexpected errors when receiving JMS messages in the context of a
> NiFi Processor. Instead of reporting the message as an error, the message
> metadata could still be useful in some flows. Using the Message Type of
> {{ObjectMessage}} as the output bytes enables this edge case scenario,
> although any system designed to interoperate with NiFi should use other types
> of JMS messages to enable subsequent handling in other Processors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12478 Return Message Type as body for JMS Object Messages [nifi]
markap14 commented on PR #8131: URL: https://github.com/apache/nifi/pull/8131#issuecomment-1846155801 Thanks @exceptionfactory I agree it's dangerous to enable using an ObjectMessage and serializing the bytes like that. I'm not really sure what exactly else to do with such a message. This approach at least ensures that the message doesn't disappear, as it passes *something* on with metadata, etc. Will merge 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-12478) Return Message Type as body for JMS Object Messages
[
https://issues.apache.org/jira/browse/NIFI-12478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794440#comment-17794440
]
ASF subversion and git services commented on NIFI-12478:
Commit f73888e7dd4b0df37f5845bc318a7ad85f22d75d in nifi's branch
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=f73888e7dd ]
NIFI-12478 Return Message Type as body for JMS Object Messages (#8131)
> Return Message Type as body for JMS Object Messages
> ---
>
> Key: NIFI-12478
> URL: https://issues.apache.org/jira/browse/NIFI-12478
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ConsumeJMS Processor supports receiving multiple types of JMS messages
> and implements different serialization strategies for each type of message.
> The JMS ObjectMessage Type provides a generic wrapper around an opaque Java
> Object without any further information. The ConsumeJMS Processor currently
> writes the bytes of an Object using Java Object serialization, which presents
> several issues. Java Object serialization is not compatible with services
> outside of Java, it writes the exact version of the Java Object, and it can
> reference classes that may not be present on the receiving system. This can
> lead to unexpected errors when receiving JMS messages in the context of a
> NiFi Processor. Instead of reporting the message as an error, the message
> metadata could still be useful in some flows. Using the Message Type of
> {{ObjectMessage}} as the output bytes enables this edge case scenario,
> although any system designed to interoperate with NiFi should use other types
> of JMS messages to enable subsequent handling in other Processors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12478 Return Message Type as body for JMS Object Messages [nifi]
markap14 merged PR #8131: URL: https://github.com/apache/nifi/pull/8131 -- 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-12486) Registry Clients
[ https://issues.apache.org/jira/browse/NIFI-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-12486: --- Status: Patch Available (was: In Progress) > Registry Clients > > > Key: NIFI-12486 > URL: https://issues.apache.org/jira/browse/NIFI-12486 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add support for registry clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794426#comment-17794426 ] Lars Francke commented on NIFI-6515: Ah! Thank you for pointing me at that issue. I managed to miss that, very interesting. That indeed looks like it's very very close. I'll have to dig deeper into that. > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794417#comment-17794417 ] Pierre Villard edited comment on NIFI-6515 at 12/7/23 8:08 PM: --- As a FYI, this is kind of what is being done in NIFI-12241 [https://github.com/apache/nifi/pull/7893] was (Author: pvillard): As a FYI, this is find of what is being done in NIFI-12241 [https://github.com/apache/nifi/pull/7893] > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794417#comment-17794417 ] Pierre Villard edited comment on NIFI-6515 at 12/7/23 8:08 PM: --- As a FYI, this is find of what is being done in NIFI-12241 [https://github.com/apache/nifi/pull/7893] was (Author: pvillard): As a FYI, this is exactly what is being done in NIFI-12241 [https://github.com/apache/nifi/pull/7893] > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794417#comment-17794417 ] Pierre Villard commented on NIFI-6515: -- As a FYI, this is exactly what is being done in NIFI-12241 [https://github.com/apache/nifi/pull/7893] > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794416#comment-17794416 ] Bryan Bende commented on NIFI-6515: --- [~larsfrancke] I think that concept could work, assuming there is a straight forward way to calculate the splits of the parquet file. Then the flow could be something like: ListXyz -> GenerateParquetSplits (or something) -> FetchParquet (modified to optionally read only a split) This way the Fetch could be even more parallelized and produce smaller flow files sooner. > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12435) Update QuestDB to 7.3.7
[ https://issues.apache.org/jira/browse/NIFI-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12435: Status: Patch Available (was: Open) > Update QuestDB to 7.3.7 > --- > > Key: NIFI-12435 > URL: https://issues.apache.org/jira/browse/NIFI-12435 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: David Handermann >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Update QuestDB to 7.3.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12435) Update QuestDB to 7.3.7
[ https://issues.apache.org/jira/browse/NIFI-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann reassigned NIFI-12435: --- Assignee: David Handermann (was: Mike R) > Update QuestDB to 7.3.7 > --- > > Key: NIFI-12435 > URL: https://issues.apache.org/jira/browse/NIFI-12435 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: David Handermann >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Update QuestDB to 7.3.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12435) Update QuestDB to 7.3.7
[ https://issues.apache.org/jira/browse/NIFI-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12435: Priority: Minor (was: Major) > Update QuestDB to 7.3.7 > --- > > Key: NIFI-12435 > URL: https://issues.apache.org/jira/browse/NIFI-12435 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: David Handermann >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Update QuestDB to 7.3.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12435) Update QuestDB to 7.3.7
[ https://issues.apache.org/jira/browse/NIFI-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12435: Summary: Update QuestDB to 7.3.7 (was: Update QuestDB to 7.3.5) > Update QuestDB to 7.3.7 > --- > > Key: NIFI-12435 > URL: https://issues.apache.org/jira/browse/NIFI-12435 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Update QuestDB to 7.3.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794399#comment-17794399 ] Lars Francke commented on NIFI-6515: Thanks [~bbende], my analysis was probably flawed. What we see is the processor reading a file, it takes ~20-30min and then a single output FlowFile appears (which in our case was over 100GB in size), it might very well be that internally it reads a single thing at a time but as a user I first see output after a big delay. I'd like to be able to process records as soon as the file has been opened. I understood this issue to be about that but - as you can see - my understanding of how the NiFi internals work is not the best (anymore) :) I'm happy to withdraw my earlier commend and would then open a new issue when I have time to work on it. I also had a brief conversation with [~joewitt] on Slack about this where he basically recommended finding splitpoints in a file before processing it: ??I do recommend finding out if it is possible to seek to a certain offset when pull Parquet data. If you can do that then what could be done is a component between the List* processor and FetchParquet which splits the thing to List with offsets. Then FetchParquet can understand the offset and grab just the portion it is assigned. That would be safe and more scalable. I just dont know if the concept of offsets is real here. If it is - game on?? > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794395#comment-17794395 ] Pierre Villard commented on NIFI-12236: --- Thanks David, this is definitely a nice improvement and will make things much better. > Improving fault tolerancy of the QuestDB backed metrics repository > -- > > Key: NIFI-12236 > URL: https://issues.apache.org/jira/browse/NIFI-12236 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Based on the related discussion on the dev email list, the QuestDB handling > of the metrics repository needs to be improved to have better fault tolerance > in order to be possible to use as a viable option for default metrics data > store. This should primarily focus on handling unexpeted database events like > corrupted database or loss of space on the disk. Any issues should be handled > with an attempt to keep the database service healthy but in case of that is > impossible, the priority is to keep NiFi and the core services running, even > with the price of metrics collection / presentation outage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794392#comment-17794392 ] David Handermann commented on NIFI-12236: - To help move things forward, I created a separate Jira issue NIFI-12492 for moving QuestDB to its own NAR and submitted a pull request for review. I realize that moving the components around would require rebasing the changes, but the goal is to address one of the concerns about continued maintenance of the QuestDB implementation. With the StatusHistoryRepository as an existing extension point, having a separate NAR makes it much easier to iterate and improve the implementation without changes to the framework itself. I was able to incorporate upgrading from QuestDB 7.2 to 7.3.7 for NIFI-12435, as the differences were minimal. The move to a separate NAR did not require any code changes, other than the minor adjustments for updating to QuestDB 7.3.7. Although not wanting to slow progress on the more fundamental improvements, moving the implementation to a separate NAR should address some general concerns and provide a better path forward. > Improving fault tolerancy of the QuestDB backed metrics repository > -- > > Key: NIFI-12236 > URL: https://issues.apache.org/jira/browse/NIFI-12236 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Based on the related discussion on the dev email list, the QuestDB handling > of the metrics repository needs to be improved to have better fault tolerance > in order to be possible to use as a viable option for default metrics data > store. This should primarily focus on handling unexpeted database events like > corrupted database or loss of space on the disk. Any issues should be handled > with an attempt to keep the database service healthy but in case of that is > impossible, the priority is to keep NiFi and the core services running, even > with the price of metrics collection / presentation outage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-12492 Move QuestDB Status Repository to Separate NAR [nifi]
exceptionfactory opened a new pull request, #8141: URL: https://github.com/apache/nifi/pull/8141 # Summary [NIFI-12492](https://issues.apache.org/jira/browse/NIFI-12492) Moves the QuestDB implementation of the Status History Repository from `nifi-framework-core` to a new `nifi-framework-questdb-nar` bundle for improved maintainability. This also provides a clear separation for the 8 MB QuestDB library from the standard framework NAR. The changes introduce a new `nifi-framework-status-history-shared` module, which is limited to API dependencies that can be shared between the standard volatile implementation and the QuestDB implementation. The change introduces a new `include-questdb` build profile for the `nifi-framework-questdb-nar` and also upgrades QuestDB from 7.2 to 7.3.7, addressing [NIFI-12435](https://issues.apache.org/jira/browse/NIFI-12435). # 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 21 ### 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-6515) FetchParquet max FlowFile size
[ https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794388#comment-17794388 ] Bryan Bende commented on NIFI-6515: --- [~larsfrancke] I don't think FetchParquet should be reading the whole file into memory, it should be reading one record at a time and writing it to the output stream of the flow file. I think the original reason for this Jira was to able to parallelize the processing after this processor so that you don't have to do another SplitRecord after this which would require re-reading the whole 23GB again. > FetchParquet max FlowFile size > -- > > Key: NIFI-6515 > URL: https://issues.apache.org/jira/browse/NIFI-6515 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Gilman >Priority: Major > > FetchParquet cannot transfer out multiple FlowFiles. We should introduce a > new property to set the size of the outgoing FlowFile and then transfer as > many FlowFiles as needed based on the fetched data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12492) Refactor QuestDB Status Repository to Separate NAR
David Handermann created NIFI-12492:
---
Summary: Refactor QuestDB Status Repository to Separate NAR
Key: NIFI-12492
URL: https://issues.apache.org/jira/browse/NIFI-12492
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework, Extensions
Reporter: David Handermann
Assignee: David Handermann
The Embedded QuestDB Status History Repository provides an implementation that
supports persistent storage of component metrics. The current implementation is
packaged together with the default implementation in
{{{}nifi-framework-core{}}}.
Based on recent discussions regarding maintenance and improvements to QuestDB,
moving the implementation to a separate NAR would streamline the standard
framework NAR and also make it easier to improve the QuestDB implementation.
There are several shared components that should be moved to a common JAR
module, which both the QuestDB and volatile implementations can use as needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12480: Updated MapRecord's toString() method to use the Serializ… [nifi]
markap14 commented on code in PR #8132:
URL: https://github.com/apache/nifi/pull/8132#discussion_r1419434681
##
nifi-nar-bundles/nifi-extension-utils/nifi-record-utils/nifi-json-record-utils/src/main/java/org/apache/nifi/json/WriteJsonResult.java:
##
@@ -173,9 +175,12 @@ private void writeRecord(final Record record, final
RecordSchema writeSchema, fi
final SerializedForm form = serializedForm.get();
if (form.getMimeType().equals(getMimeType()) &&
record.getSchema().equals(writeSchema)) {
final Object serialized = form.getSerialized();
-if (serialized instanceof String) {
-generator.writeRawValue((String) serialized);
-return;
+if (serialized instanceof final String serializedString) {
+final boolean serializedPretty =
serializedString.contains("\n");
+if (serializedPretty == this.prettyPrint) {
Review Comment:
These are not equivalent. I'm not checking if they are both true - I am
checking if they are equal.
--
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
Re: [PR] NIFI-12480: Updated MapRecord's toString() method to use the Serializ… [nifi]
markap14 commented on code in PR #8132:
URL: https://github.com/apache/nifi/pull/8132#discussion_r1419434303
##
nifi-commons/nifi-record/src/main/java/org/apache/nifi/serialization/record/MapRecord.java:
##
@@ -681,22 +752,18 @@ private RecordField getUpdatedRecordField(final
RecordField field) {
}
final DataType mergedDataType =
RecordFieldType.CHOICE.getChoiceDataType(updatedPossibleTypes);
-return new RecordField(field.getFieldName(), mergedDataType,
field.getDefaultValue(), field.getAliases(), field.isNullable());
+return new RecordField(specField.getFieldName(), mergedDataType,
specField.getDefaultValue(), specField.getAliases(), specField.isNullable());
}
-return field;
+return specField;
}
private boolean isSimpleType(final RecordFieldType fieldType) {
-switch (fieldType) {
-case ARRAY:
-case RECORD:
-case MAP:
-case CHOICE:
-return false;
-}
+return switch (fieldType) {
+case ARRAY, RECORD, MAP, CHOICE -> false;
+default -> true;
+};
Review Comment:
No, I have no plans to backport.
--
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
Re: [PR] NIFI-12479 Add pg-export to toolkit CLI [nifi]
pvillard31 commented on code in PR #8137: URL: https://github.com/apache/nifi/pull/8137#discussion_r1419385542 ## nifi-docs/src/main/asciidoc/toolkit-guide.adoc: ## @@ -290,21 +291,21 @@ For example, typing tab at an empty prompt should display possible commands for Typing "nifi " and then a tab will show the sub-commands for NiFi: #> nifi - cluster-summary export-param-contextlist-users pg-set-param-context - connect-nodeget-nodemerge-param-context pg-set-var - create-param-contextget-nodes offload-node pg-start - create-reg-client get-param-context pg-change-version pg-status - create-reporting-task get-policy pg-create-service pg-stop - create-service get-reg-client-id pg-create-service set-param - create-user get-reporting-task pg-disable-services start-reporting-tasks - create-user-group get-reporting-tasks pg-enable-services stop-reporting-tasks - current-userget-root-id pg-get-all-versions update-policy - delete-node get-service pg-get-param-context update-reg-client - delete-paramget-servicespg-get-services update-user-group - delete-param-contextimport-param-contextpg-get-vars delete-reporting-task - disable-serviceslist-param-contexts pg-get-version + cluster-summary export-param-contextlist-users pg-list + connect-nodeget-nodemerge-param-context pg-set-param-context + create-param-contextget-nodes offload-node pg-set-var + create-reg-client get-param-context pg-change-version pg-start + create-reporting-task get-policy pg-create-service pg-status + create-service get-reg-client-id pg-create-service pg-stop + create-user get-reporting-task pg-disable-services set-param + create-user-group get-reporting-tasks pg-enable-services start-reporting-tasks + current-userget-root-id pg-get-all-versions stop-reporting-tasks + delete-node get-service pg-get-param-context update-policy + delete-paramget-servicespg-get-services update-reg-client + delete-param-contextimport-param-contextpg-get-vars update-user-group + disable-serviceslist-param-contexts pg-get-version delete-reporting-task disconnect-node list-reg-clientspg-import - enable-services list-user-groupspg-list + enable-services list-user-groupspg-export Review Comment: It appears that we've not been good at keeping this list accurate (I take the blame as some of the commands I recently added in the CLI are not in this list). Do you mind taking the opportunity of this PR to have this listing fixed? This is the list of commands I see right now with the CLI: commands: demo quick-import nifi current-user nifi cluster-summary nifi connect-node nifi delete-node nifi disconnect-node nifi get-root-id nifi get-node nifi get-nodes nifi offload-node nifi list-reg-clients nifi create-reg-client nifi update-reg-client nifi get-reg-client-id nifi pg-import nifi pg-connect nifi pg-start nifi pg-stop nifi pg-create nifi pg-get-version nifi pg-stop-version-control nifi pg-change-version nifi pg-get-all-versions nifi pg-list nifi pg-status nifi pg-get-services nifi pg-create-service nifi pg-enable-services nifi pg-disable-services nifi pg-get-param-context nifi pg-set-param-context nifi pg-replace nifi pg-export nifi get-services nifi get-service nifi create-service nifi enable-services nifi disable-services nifi get-reporting-tasks nifi get-reporting-task nifi create-reporting-task nifi delete-reporting-task nifi start-reporting-tasks nifi stop-reporting-tasks nifi export-reporting-tasks nifi export-reporting-task nifi import-reporting-tasks nifi list-users nifi create-user nifi list-user-groups nifi create-user-group nifi update-user-group nifi get-policy nifi update-policy nifi list-param-contexts nifi get-param-context nifi create-param-context nifi delete-param-context nifi set-inherited-param-contexts nifi remove-inherited-param-contexts nifi set-param
Re: [PR] NIFI-12445: Provenance Event Listing [nifi]
rfellows commented on code in PR #8133:
URL: https://github.com/apache/nifi/pull/8133#discussion_r1419226579
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi/src/app/pages/provenance/ui/provenance-event-listing/provenance-event-table/provenance-event-table.component.ts:
##
@@ -0,0 +1,193 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import { AfterViewInit, Component, EventEmitter, Input, Output, ViewChild }
from '@angular/core';
+import { MatTableDataSource, MatTableModule } from '@angular/material/table';
+import { MatSort, MatSortModule } from '@angular/material/sort';
+import { TextTip } from
'../../../../../ui/common/tooltips/text-tip/text-tip.component';
+import { BulletinsTip } from
'../../../../../ui/common/tooltips/bulletins-tip/bulletins-tip.component';
+import { ValidationErrorsTip } from
'../../../../../ui/common/tooltips/validation-errors-tip/validation-errors-tip.component';
+import { NiFiCommon } from '../../../../../service/nifi-common.service';
+import { MatFormFieldModule } from '@angular/material/form-field';
+import { MatInputModule } from '@angular/material/input';
+import { MatOptionModule } from '@angular/material/core';
+import { MatSelectModule } from '@angular/material/select';
+import { FormBuilder, FormGroup, ReactiveFormsModule } from '@angular/forms';
+import { NgForOf, NgIf } from '@angular/common';
+import { debounceTime } from 'rxjs';
+import { ProvenanceEvent, ProvenanceEventSummary } from
'../../../../../state/shared';
+import { RouterLink } from '@angular/router';
+
+@Component({
+selector: 'provenance-event-table',
+standalone: true,
+templateUrl: './provenance-event-table.component.html',
+imports: [
+MatTableModule,
+MatSortModule,
+MatFormFieldModule,
+MatInputModule,
+MatOptionModule,
+MatSelectModule,
+ReactiveFormsModule,
+NgForOf,
+NgIf,
+RouterLink
+],
+styleUrls: ['./provenance-event-table.component.scss',
'../../../../../../assets/styles/listing-table.scss']
+})
+export class ProvenanceEventTable implements AfterViewInit {
+@Input() set events(events: ProvenanceEventSummary[]) {
+this.dataSource = new
MatTableDataSource(events);
+this.dataSource.sort = this.sort;
+this.dataSource.filterPredicate = (data: ProvenanceEventSummary,
filter: string) => {
+const filterArray = filter.split('|');
+const filterTerm = filterArray[0];
+const filterColumn = filterArray[1];
+
+if (filterColumn === this.filterColumnOptions[0]) {
+return
data.componentName.toLowerCase().indexOf(filterTerm.toLowerCase()) >= 0;
+} else if (filterColumn === this.filterColumnOptions[1]) {
+return
data.componentType.toLowerCase().indexOf(filterTerm.toLowerCase()) >= 0;
+} else {
+return
data.eventType.toLowerCase().indexOf(filterTerm.toLowerCase()) >= 0;
+}
+};
+this.totalCount = events.length;
+this.filteredCount = events.length;
+
+// apply any filtering to the new data
+const filterTerm = this.filterForm.get('filterTerm')?.value;
+if (filterTerm?.length > 0) {
+const filterColumn = this.filterForm.get('filterColumn')?.value;
+this.applyFilter(filterTerm, filterColumn);
+}
+}
Review Comment:
We should support an initial sort and initial sort direction as inputs as
well. The data is sorted initially, but the UI doesn't reflect that on initial
load. These would then get set as `[matSortActive]` and `[matSortDirection]` on
the `matTable`. You can see an example in the counters table.
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi/src/app/pages/provenance/ui/provenance-event-listing/provenance-event-listing.component.html:
##
@@ -0,0 +1,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
Review Comment:
The logic for `isInitialLoading` is really `isLoading`. This
Re: [PR] NIFI-12480: Updated MapRecord's toString() method to use the Serializ… [nifi]
joewitt commented on code in PR #8132:
URL: https://github.com/apache/nifi/pull/8132#discussion_r1419340178
##
nifi-commons/nifi-record/src/main/java/org/apache/nifi/serialization/record/MapRecord.java:
##
@@ -681,22 +752,18 @@ private RecordField getUpdatedRecordField(final
RecordField field) {
}
final DataType mergedDataType =
RecordFieldType.CHOICE.getChoiceDataType(updatedPossibleTypes);
-return new RecordField(field.getFieldName(), mergedDataType,
field.getDefaultValue(), field.getAliases(), field.isNullable());
+return new RecordField(specField.getFieldName(), mergedDataType,
specField.getDefaultValue(), specField.getAliases(), specField.isNullable());
}
-return field;
+return specField;
}
private boolean isSimpleType(final RecordFieldType fieldType) {
-switch (fieldType) {
-case ARRAY:
-case RECORD:
-case MAP:
-case CHOICE:
-return false;
-}
+return switch (fieldType) {
+case ARRAY, RECORD, MAP, CHOICE -> false;
+default -> true;
+};
Review Comment:
We absolutely should adopt language niceties as we go forward and hopefully
backport considerations don't cause us to avoid that. Backports are fair game
where it makes sense but should happen with specific PRs and this will be
increasingly true as we go forward.
--
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-12489) Upgrade Apache POI to 5.2.5
[ https://issues.apache.org/jira/browse/NIFI-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794369#comment-17794369 ] ASF subversion and git services commented on NIFI-12489: Commit 843a1016540836767c2125f7dd13b3cc8c6620df in nifi's branch refs/heads/support/nifi-1.x from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=843a101654 ] NIFI-12489 Upgraded Apache POI from 5.2.4 to 5.2.5 Signed-off-by: Pierre Villard This closes #8140. > Upgrade Apache POI to 5.2.5 > --- > > Key: NIFI-12489 > URL: https://issues.apache.org/jira/browse/NIFI-12489 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 1.25.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache POI [5.2.5|https://poi.apache.org/changes.html#5.2.5] contains several > transitive dependency updates, most of which are already upgraded through > dependency management, but Apache POI should be upgraded to maintain version > parity. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12489) Upgrade Apache POI to 5.2.5
[ https://issues.apache.org/jira/browse/NIFI-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12489: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Apache POI to 5.2.5 > --- > > Key: NIFI-12489 > URL: https://issues.apache.org/jira/browse/NIFI-12489 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 1.25.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache POI [5.2.5|https://poi.apache.org/changes.html#5.2.5] contains several > transitive dependency updates, most of which are already upgraded through > dependency management, but Apache POI should be upgraded to maintain version > parity. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12489) Upgrade Apache POI to 5.2.5
[ https://issues.apache.org/jira/browse/NIFI-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794367#comment-17794367 ] ASF subversion and git services commented on NIFI-12489: Commit b9dbcab1606b16070353c8f37a3e47ac0ae5e1e2 in nifi's branch refs/heads/main from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=b9dbcab160 ] NIFI-12489 Upgraded Apache POI from 5.2.4 to 5.2.5 Signed-off-by: Pierre Villard This closes #8140. > Upgrade Apache POI to 5.2.5 > --- > > Key: NIFI-12489 > URL: https://issues.apache.org/jira/browse/NIFI-12489 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 1.25.0, 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Apache POI [5.2.5|https://poi.apache.org/changes.html#5.2.5] contains several > transitive dependency updates, most of which are already upgraded through > dependency management, but Apache POI should be upgraded to maintain version > parity. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12489 Upgrade Apache POI from 5.2.4 to 5.2.5 [nifi]
asfgit closed pull request #8140: NIFI-12489 Upgrade Apache POI from 5.2.4 to 5.2.5 URL: https://github.com/apache/nifi/pull/8140 -- 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
Re: [PR] NIFI-12480: Updated MapRecord's toString() method to use the Serializ… [nifi]
dan-s1 commented on code in PR #8132:
URL: https://github.com/apache/nifi/pull/8132#discussion_r1419272655
##
nifi-commons/nifi-record/src/main/java/org/apache/nifi/serialization/record/MapRecord.java:
##
@@ -335,14 +336,68 @@ private boolean valuesEqual(final Map
thisValues, final Map serializedForm = getSerializedForm();
+if (serializedForm.isEmpty()) {
+return "MapRecord[" + values + "]";
+}
+
+final Object serialized = serializedForm.get().getSerialized();
+return serialized == null ? "MapRecord[" + values + "]" :
serialized.toString();
}
@Override
public Optional getSerializedForm() {
+if (serializedForm.isEmpty()) {
+return Optional.empty();
+}
+
+if (isSerializedFormReset()) {
+return Optional.empty();
+}
Review Comment:
```suggestion
if (serializedForm.isEmpty() || isSerializedFormReset()) {
return Optional.empty();
}
```
##
nifi-nar-bundles/nifi-extension-utils/nifi-record-utils/nifi-json-record-utils/src/main/java/org/apache/nifi/json/WriteJsonResult.java:
##
@@ -173,9 +175,12 @@ private void writeRecord(final Record record, final
RecordSchema writeSchema, fi
final SerializedForm form = serializedForm.get();
if (form.getMimeType().equals(getMimeType()) &&
record.getSchema().equals(writeSchema)) {
final Object serialized = form.getSerialized();
-if (serialized instanceof String) {
-generator.writeRawValue((String) serialized);
-return;
+if (serialized instanceof final String serializedString) {
+final boolean serializedPretty =
serializedString.contains("\n");
+if (serializedPretty == this.prettyPrint) {
Review Comment:
`==` is not common for boolean logic
```suggestion
if (serializedPretty && this.prettyPrint) {
```
##
nifi-commons/nifi-record/src/main/java/org/apache/nifi/serialization/record/MapRecord.java:
##
@@ -681,22 +752,18 @@ private RecordField getUpdatedRecordField(final
RecordField field) {
}
final DataType mergedDataType =
RecordFieldType.CHOICE.getChoiceDataType(updatedPossibleTypes);
-return new RecordField(field.getFieldName(), mergedDataType,
field.getDefaultValue(), field.getAliases(), field.isNullable());
+return new RecordField(specField.getFieldName(), mergedDataType,
specField.getDefaultValue(), specField.getAliases(), specField.isNullable());
}
-return field;
+return specField;
}
private boolean isSimpleType(final RecordFieldType fieldType) {
-switch (fieldType) {
-case ARRAY:
-case RECORD:
-case MAP:
-case CHOICE:
-return false;
-}
+return switch (fieldType) {
+case ARRAY, RECORD, MAP, CHOICE -> false;
+default -> true;
+};
Review Comment:
This switch statement style is from later versions of Java, is the fix in
this PR not going to be backported at all?
--
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-11167) Add Excel Record Reader
[ https://issues.apache.org/jira/browse/NIFI-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794361#comment-17794361 ] Philipp Korniets commented on NIFI-11167: - [~dstiegli1] [NIFI-12491|https://issues.apache.org/jira/browse/NIFI-12491] > Add Excel Record Reader > --- > > Key: NIFI-11167 > URL: https://issues.apache.org/jira/browse/NIFI-11167 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: David Handermann >Assignee: Daniel Stieglitz >Priority: Minor > Fix For: 2.0.0-M1, 1.23.0 > > Attachments: CSVRecordSetWriter_configuration.png, > ExcelReaderConfiguration.png, QueryRecord_configuration.png, Test > ExcelReader.xlsx, Test Sheet-formula.xlsx, image-2023-11-28-18-22-07-446.png, > image-2023-11-29-15-51-08-386.png, resulting.csv, screenshot-1.png > > Time Spent: 10h 10m > Remaining Estimate: 0h > > A new Excel Record Reader should be implemented to support reading XSLX > spreadsheet rows as NiFi Records. This Reader will enable integration with > various record-oriented components, obviating the need for the narrowly > focused ConvertExcelToCSVProcessor. The initial version of the Excel Reader > should not support the legacy binary XLS format. > The ExcelReader should use a library that supports reading from a stream of > rows to avoid consuming large amounts of heap memory during processing. > The ExcelReader should support configurable properties to read selected > sheets. With Excel supporting typed field values, some amount of field type > mapping will be required. Additional input filtering properties should not be > implemented as existing Processors like QueryRecord support a wide variety of > filtering and projection use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12491) ExcelReader - new Schema Access strategy: Use String Fields From Header
[ https://issues.apache.org/jira/browse/NIFI-12491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Korniets updated NIFI-12491: Affects Version/s: 1.23.2 > ExcelReader - new Schema Access strategy: Use String Fields From Header > --- > > Key: NIFI-12491 > URL: https://issues.apache.org/jira/browse/NIFI-12491 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.23.2 >Reporter: Philipp Korniets >Priority: Major > > ExcelReader needs an ability similar to CSVReader to "Use String Fields From > Header" as a Schema Access Strategy. > Current implementation has: > 1. Use Schema Name/Schema Text - this option relies on the order of the > columns. Possible issues - order of the columns change, but types dont. This > cause further calculations to be erroneous. > 2. Infer Schema - replaces real column names with column_1,column_2 etc - > this again loses the "context" of the column and forces us to rely on how > columns are ordered. > Any workarounds make workflow more complicated. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-11308 Adding expression language function to return nifi version [nifi]
mosermw commented on code in PR #8101:
URL: https://github.com/apache/nifi/pull/8101#discussion_r1419318447
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarClassLoaders.java:
##
@@ -74,6 +74,7 @@ private InitContext(
this.jettyBundle = jettyBundle;
this.serverInstance = serverInstance;
this.bundles = bundles;
+System.setProperty("nifi.version",
frameworkBundle.getBundleDetails().getCoordinate().getVersion());
Review Comment:
Could we name this system property `nifi.framework.version`? This is more
specific and may avoid confusion with generic system properties that are not
related to NiFi.
--
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-12491) ExcelReader - new Schema Access strategy: Use String Fields From Header
Philipp Korniets created NIFI-12491: --- Summary: ExcelReader - new Schema Access strategy: Use String Fields From Header Key: NIFI-12491 URL: https://issues.apache.org/jira/browse/NIFI-12491 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: Philipp Korniets ExcelReader needs an ability similar to CSVReader to "Use String Fields From Header" as a Schema Access Strategy. Current implementation has: 1. Use Schema Name/Schema Text - this option relies on the order of the columns. Possible issues - order of the columns change, but types dont. This cause further calculations to be erroneous. 2. Infer Schema - replaces real column names with column_1,column_2 etc - this again loses the "context" of the column and forces us to rely on how columns are ordered. Any workarounds make workflow more complicated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11167) Add Excel Record Reader
[ https://issues.apache.org/jira/browse/NIFI-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794323#comment-17794323 ] Philipp Korniets commented on NIFI-11167: - Thanks a lot [~dstiegli1]!! Appreciate your help with that. > Add Excel Record Reader > --- > > Key: NIFI-11167 > URL: https://issues.apache.org/jira/browse/NIFI-11167 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: David Handermann >Assignee: Daniel Stieglitz >Priority: Minor > Fix For: 2.0.0-M1, 1.23.0 > > Attachments: CSVRecordSetWriter_configuration.png, > ExcelReaderConfiguration.png, QueryRecord_configuration.png, Test > ExcelReader.xlsx, Test Sheet-formula.xlsx, image-2023-11-28-18-22-07-446.png, > image-2023-11-29-15-51-08-386.png, resulting.csv, screenshot-1.png > > Time Spent: 10h 10m > Remaining Estimate: 0h > > A new Excel Record Reader should be implemented to support reading XSLX > spreadsheet rows as NiFi Records. This Reader will enable integration with > various record-oriented components, obviating the need for the narrowly > focused ConvertExcelToCSVProcessor. The initial version of the Excel Reader > should not support the legacy binary XLS format. > The ExcelReader should use a library that supports reading from a stream of > rows to avoid consuming large amounts of heap memory during processing. > The ExcelReader should support configurable properties to read selected > sheets. With Excel supporting typed field values, some amount of field type > mapping will be required. Additional input filtering properties should not be > implemented as existing Processors like QueryRecord support a wide variety of > filtering and projection use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794320#comment-17794320 ] David Handermann commented on NIFI-12236: - Regarding the particular point of moving QuestDB support to a separate NAR, it is important to note that the StatusHistoryRepository is already an extension point, so it is open to custom implementations. That highlights the importance of avoiding API changes for this specific implementation. That also means moving the QuestDB implementation to a separate NAR should be straightforward. On that point in particular, I would be willing to move the existing implementation to a separate NAR, which would help keep these changes more focused. > Improving fault tolerancy of the QuestDB backed metrics repository > -- > > Key: NIFI-12236 > URL: https://issues.apache.org/jira/browse/NIFI-12236 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Based on the related discussion on the dev email list, the QuestDB handling > of the metrics repository needs to be improved to have better fault tolerance > in order to be possible to use as a viable option for default metrics data > store. This should primarily focus on handling unexpeted database events like > corrupted database or loss of space on the disk. Any issues should be handled > with an attempt to keep the database service healthy but in case of that is > impossible, the priority is to keep NiFi and the core services running, even > with the price of metrics collection / presentation outage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12490) Graceful shutdown of MiNiFi docker
Ferenc Kis created NIFI-12490: - Summary: Graceful shutdown of MiNiFi docker Key: NIFI-12490 URL: https://issues.apache.org/jira/browse/NIFI-12490 Project: Apache NiFi Issue Type: Improvement Components: MiNiFi Affects Versions: 2.0.0-M1 Reporter: Ferenc Kis Assignee: Ferenc Kis Currently when the MiNiFi docker image receives the SIGTERM signal the application is simply killed which may lead to potential data loss. MiNiFi should gracefully shut down for this signal similarily what is used in NiFi. Example: nifi-docker/dockerhub/sh/start.sh -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11167) Add Excel Record Reader
[ https://issues.apache.org/jira/browse/NIFI-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794319#comment-17794319 ] Daniel Stieglitz commented on NIFI-11167: - [~iiojj2] I can understand why you may want that feature. Can you please submit a ticket for this? Thanks! > Add Excel Record Reader > --- > > Key: NIFI-11167 > URL: https://issues.apache.org/jira/browse/NIFI-11167 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: David Handermann >Assignee: Daniel Stieglitz >Priority: Minor > Fix For: 2.0.0-M1, 1.23.0 > > Attachments: CSVRecordSetWriter_configuration.png, > ExcelReaderConfiguration.png, QueryRecord_configuration.png, Test > ExcelReader.xlsx, Test Sheet-formula.xlsx, image-2023-11-28-18-22-07-446.png, > image-2023-11-29-15-51-08-386.png, resulting.csv, screenshot-1.png > > Time Spent: 10h 10m > Remaining Estimate: 0h > > A new Excel Record Reader should be implemented to support reading XSLX > spreadsheet rows as NiFi Records. This Reader will enable integration with > various record-oriented components, obviating the need for the narrowly > focused ConvertExcelToCSVProcessor. The initial version of the Excel Reader > should not support the legacy binary XLS format. > The ExcelReader should use a library that supports reading from a stream of > rows to avoid consuming large amounts of heap memory during processing. > The ExcelReader should support configurable properties to read selected > sheets. With Excel supporting typed field values, some amount of field type > mapping will be required. Additional input filtering properties should not be > implemented as existing Processors like QueryRecord support a wide variety of > filtering and projection use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794312#comment-17794312 ] Joe Witt edited comment on NIFI-12236 at 12/7/23 3:42 PM: -- Regarding defaults - thank you. API Changes: These should get the highest degree of scrutiny by reviewers and the most effort and thought by authors. At this stage I do not understand the intention for the change. It appears that concern is shared. If there is a non-API/specific to this implementation option that should be pursued instead. Suggestion about the nar: I am not aware of other cases where the optional implementation of a thing is the lighter option in terms of dependencies path. In this case the optional implementation (QuestDB backed stats) is the heavier one in terms of dependency/operations. By suggesting it be in its own nar I am not of the view it is a lot more work to be clear. I could be wrong. But the more work consideration is also not a strong one. The 'it is already in there...' argument is better since well - that is true. I'm just asking that the effort to do that be strongly considered because then those who would not use this option don't have to carry the component into deployment nor the potential vulnerabilities the libraries might bring. But those that want it are good to go and can use it. If it is baked into the framework nar this is not an option. As evidence of my concern regarding the vulnerability it does give pause that the version of QuestDB was not considered in this PR to this point. Keeping dependencies up to date is *everyones* responsibility. The NiFi 2.0 line is by the way super wildly close to being entirely free of static coding practice and dependency vulnerabilities (excluding hadoop related components) which is in itself a miracle. Please ensure the dependencies in this PR are up to date. On that note do we know what QuestDB version changes mean in terms of breaking changes, changes that might require users to do something to keep their state, etc..? I ask because we learned our lessons the hard way here with H2. H2 served us extremely well over the years but eventually it created some very complicated compelling events. Anyway - I dont want to come off like this thing can't happen. The root idea of this I think we all agree is useful. There is some debate on whether this implementation approach is desirable vs another but even that does not matter. He who does the work for a given implementation ultimately wins. What I am asking then though is please make that implementation as narrow and specific as possible to give others choice on whether they are exposed to it. That is the heart of the replies I am making. Thanks was (Author: joewitt): Regarding defaults - thank you. API Changes: These should get the highest degree of scrutiny by reviewers and the most effort and thought by authors. At this stage I do not understand the intention for the change. It appears that concern is shared. If there is a non-API/specific to this implementation option that should be pursued instead. Suggestion about the nar: I am not aware of other cases where the optional implementation of a thing is the light in terms of dependencies path. In this case the optional implementation (QuestDB backed stats) is the heavier one in terms of dependency/operations. By suggesting it be in its own nar I am not of the view it is a lot more work to be clear. I could be wrong. But the more work consideration is also not a strong one. The 'it is already in there...' argument is better since well - that is true. I'm just asking that the effort to do that be strongly considered because then those who would not use this option don't have to carry the component into deployment nor the potential vulnerabilities the libraries might bring. But those that want it are good to go and can use it. If it is baked into the framework nar this is not an option. As evidence of my concern regarding the vulnerability it does give pause that the version of QuestDB was not considered in this PR to this point. Keeping dependencies up to date is *everyones* responsibility. The NiFi 2.0 line is by the way super wildly close to being entirely free of static coding practice and dependency vulnerabilities (excluding hadoop related components) which is in itself a miracle. Please ensure the dependencies in this PR are up to date. On that note do we know what QuestDB version changes mean in terms of breaking changes, changes that might require users to do something to keep their state, etc..? I ask because we learned our lessons the hard way here with H2. H2 served us extremely well over the years but eventually it created some very complicated compelling events. Anyway - I dont want to come off like this thing can't happen. The root idea of this
[jira] [Commented] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794312#comment-17794312 ] Joe Witt commented on NIFI-12236: - Regarding defaults - thank you. API Changes: These should get the highest degree of scrutiny by reviewers and the most effort and thought by authors. At this stage I do not understand the intention for the change. It appears that concern is shared. If there is a non-API/specific to this implementation option that should be pursued instead. Suggestion about the nar: I am not aware of other cases where the optional implementation of a thing is the light in terms of dependencies path. In this case the optional implementation (QuestDB backed stats) is the heavier one in terms of dependency/operations. By suggesting it be in its own nar I am not of the view it is a lot more work to be clear. I could be wrong. But the more work consideration is also not a strong one. The 'it is already in there...' argument is better since well - that is true. I'm just asking that the effort to do that be strongly considered because then those who would not use this option don't have to carry the component into deployment nor the potential vulnerabilities the libraries might bring. But those that want it are good to go and can use it. If it is baked into the framework nar this is not an option. As evidence of my concern regarding the vulnerability it does give pause that the version of QuestDB was not considered in this PR to this point. Keeping dependencies up to date is *everyones* responsibility. The NiFi 2.0 line is by the way super wildly close to being entirely free of static coding practice and dependency vulnerabilities (excluding hadoop related components) which is in itself a miracle. Please ensure the dependencies in this PR are up to date. On that note do we know what QuestDB version changes mean in terms of breaking changes, changes that might require users to do something to keep their state, etc..? I ask because we learned our lessons the hard way here with H2. H2 served us extremely well over the years but eventually it created some very complicated compelling events. Anyway - I dont want to come off like this thing can't happen. The root idea of this I think we all agree is useful. There is some debate on whether this implementation approach is desirable vs another but even that does not matter. He who does the work for a given implementation ultimately wins. What I am asking then though is please make that implementation as narrow and specific as possible to give others choice on whether they are exposed to it. That is the heart of the replies I am making. Thanks > Improving fault tolerancy of the QuestDB backed metrics repository > -- > > Key: NIFI-12236 > URL: https://issues.apache.org/jira/browse/NIFI-12236 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Based on the related discussion on the dev email list, the QuestDB handling > of the metrics repository needs to be improved to have better fault tolerance > in order to be possible to use as a viable option for default metrics data > store. This should primarily focus on handling unexpeted database events like > corrupted database or loss of space on the disk. Any issues should be handled > with an attempt to keep the database service healthy but in case of that is > impossible, the priority is to keep NiFi and the core services running, even > with the price of metrics collection / presentation outage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12489) Upgrade Apache POI to 5.2.5
[ https://issues.apache.org/jira/browse/NIFI-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12489: Status: Patch Available (was: Open) > Upgrade Apache POI to 5.2.5 > --- > > Key: NIFI-12489 > URL: https://issues.apache.org/jira/browse/NIFI-12489 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 1.25.0, 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Apache POI [5.2.5|https://poi.apache.org/changes.html#5.2.5] contains several > transitive dependency updates, most of which are already upgraded through > dependency management, but Apache POI should be upgraded to maintain version > parity. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-12489 Upgrade Apache POI from 5.2.4 to 5.2.5 [nifi]
exceptionfactory opened a new pull request, #8140: URL: https://github.com/apache/nifi/pull/8140 # Summary [NIFI-12489](https://issues.apache.org/jira/browse/NIFI-12489) Upgrades Apache POI from 5.2.4 to [5.2.5](https://poi.apache.org/changes.html#5.2.5). Version 5.2.5 consists primarily of transitive dependency updates, most of which are already updated through project managed dependencies. # 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 - [X] Build completed using `mvn clean install -P contrib-check` - [X] JDK 21 ### 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-12489) Upgrade Apache POI to 5.2.5
David Handermann created NIFI-12489: --- Summary: Upgrade Apache POI to 5.2.5 Key: NIFI-12489 URL: https://issues.apache.org/jira/browse/NIFI-12489 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: David Handermann Assignee: David Handermann Fix For: 1.25.0, 2.0.0 Apache POI [5.2.5|https://poi.apache.org/changes.html#5.2.5] contains several transitive dependency updates, most of which are already upgraded through dependency management, but Apache POI should be upgraded to maintain version parity. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12105: ExecuteStateless processor accepts additional NAR directories [nifi]
pgyori commented on PR #8129: URL: https://github.com/apache/nifi/pull/8129#issuecomment-1845514076 Thank you @pvillard31 and @exceptionfactory ! -- 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
Re: [PR] NIFI-12105: ExecuteStateless processor accepts additional NAR directories [nifi]
asfgit closed pull request #8129: NIFI-12105: ExecuteStateless processor accepts additional NAR directories URL: https://github.com/apache/nifi/pull/8129 -- 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-12105) ExecuteStateless should support multiple directories for NAR Directory property
[ https://issues.apache.org/jira/browse/NIFI-12105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12105: -- Fix Version/s: 1.25.0 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > ExecuteStateless should support multiple directories for NAR Directory > property > --- > > Key: NIFI-12105 > URL: https://issues.apache.org/jira/browse/NIFI-12105 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, NiFi Stateless >Reporter: Pierre Villard >Assignee: Peter Gyori >Priority: Major > Fix For: 1.25.0, 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ExecuteStateless has a property for the NAR Directory which currently accepts > a single directory. When deploying custom NARs, it's usually done in a > dedicated directory that is not the lib directory. It'd be nice to support a > comma separated list of directories when configuring ExecuteStateless so that > the execute flow can reference custom NARs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12105) ExecuteStateless should support multiple directories for NAR Directory property
[ https://issues.apache.org/jira/browse/NIFI-12105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794280#comment-17794280 ] ASF subversion and git services commented on NIFI-12105: Commit 92d491f87e71f912e7630bdc2b0c2d80b4230963 in nifi's branch refs/heads/support/nifi-1.x from Peter Gyori [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=92d491f87e ] NIFI-12105: ExecuteStateless processor accepts additional NAR directories Signed-off-by: Pierre Villard This closes #8129. > ExecuteStateless should support multiple directories for NAR Directory > property > --- > > Key: NIFI-12105 > URL: https://issues.apache.org/jira/browse/NIFI-12105 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, NiFi Stateless >Reporter: Pierre Villard >Assignee: Peter Gyori >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > ExecuteStateless has a property for the NAR Directory which currently accepts > a single directory. When deploying custom NARs, it's usually done in a > dedicated directory that is not the lib directory. It'd be nice to support a > comma separated list of directories when configuring ExecuteStateless so that > the execute flow can reference custom NARs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12105: ExecuteStateless processor accepts additional NAR directories [nifi]
pvillard31 commented on PR #8129: URL: https://github.com/apache/nifi/pull/8129#issuecomment-1845505812 Thanks @exceptionfactory - I'll go ahead and merge Thanks for the addition @pgyori ! -- 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-12105) ExecuteStateless should support multiple directories for NAR Directory property
[ https://issues.apache.org/jira/browse/NIFI-12105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794278#comment-17794278 ] ASF subversion and git services commented on NIFI-12105: Commit 5675d37bed764e4441415443483f0d776c11d3cb in nifi's branch refs/heads/main from Peter Gyori [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5675d37bed ] NIFI-12105: ExecuteStateless processor accepts additional NAR directories Signed-off-by: Pierre Villard This closes #8129. > ExecuteStateless should support multiple directories for NAR Directory > property > --- > > Key: NIFI-12105 > URL: https://issues.apache.org/jira/browse/NIFI-12105 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, NiFi Stateless >Reporter: Pierre Villard >Assignee: Peter Gyori >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > ExecuteStateless has a property for the NAR Directory which currently accepts > a single directory. When deploying custom NARs, it's usually done in a > dedicated directory that is not the lib directory. It'd be nice to support a > comma separated list of directories when configuring ExecuteStateless so that > the execute flow can reference custom NARs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12483) Streamline JMX Metrics Filtering Parameters
[ https://issues.apache.org/jira/browse/NIFI-12483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794277#comment-17794277 ] ASF subversion and git services commented on NIFI-12483: Commit a05f0f86aeb2f8c453d225b63b8831150a3a7727 in nifi's branch refs/heads/support/nifi-1.x from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=a05f0f86ae ] NIFI-12483 Streamlined JMX Metrics Filtering Parameters - Added bean name filter processing and added test cases Signed-off-by: Pierre Villard This closes #8134. > Streamline JMX Metrics Filtering Parameters > --- > > Key: NIFI-12483 > URL: https://issues.apache.org/jira/browse/NIFI-12483 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The JMX Metrics REST Resource provides selected access to registered bean > statistics based on application configuration properties. The default > configuration in application properties should be sufficient in most > scenarios to return only those beans necessary for targeted monitoring. In > other scenarios, allowing limited filtering based on HTTP request parameters > is supported. The HTTP request parameters should be processed prior to > filtering to provide optimal matching. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12488: Add support for dynamic sensitive properties for the ExecuteProcess processor [nifi]
exceptionfactory commented on PR #8138: URL: https://github.com/apache/nifi/pull/8138#issuecomment-1845504102 Thanks for the quick reply @lfrancke. If you get to the point where you don't think you will be able to complete the changes, I recommend noting these details on the Jira issue for future implementation. -- 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-12483) Streamline JMX Metrics Filtering Parameters
[ https://issues.apache.org/jira/browse/NIFI-12483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12483: -- Fix Version/s: 1.25.0 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Streamline JMX Metrics Filtering Parameters > --- > > Key: NIFI-12483 > URL: https://issues.apache.org/jira/browse/NIFI-12483 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.25.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The JMX Metrics REST Resource provides selected access to registered bean > statistics based on application configuration properties. The default > configuration in application properties should be sufficient in most > scenarios to return only those beans necessary for targeted monitoring. In > other scenarios, allowing limited filtering based on HTTP request parameters > is supported. The HTTP request parameters should be processed prior to > filtering to provide optimal matching. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12483) Streamline JMX Metrics Filtering Parameters
[ https://issues.apache.org/jira/browse/NIFI-12483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794276#comment-17794276 ] ASF subversion and git services commented on NIFI-12483: Commit 5c1b0a114095440bd0ae33cd4171f7761d53dda8 in nifi's branch refs/heads/main from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5c1b0a1140 ] NIFI-12483 Streamlined JMX Metrics Filtering Parameters - Added bean name filter processing and added test cases Signed-off-by: Pierre Villard This closes #8134. > Streamline JMX Metrics Filtering Parameters > --- > > Key: NIFI-12483 > URL: https://issues.apache.org/jira/browse/NIFI-12483 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The JMX Metrics REST Resource provides selected access to registered bean > statistics based on application configuration properties. The default > configuration in application properties should be sufficient in most > scenarios to return only those beans necessary for targeted monitoring. In > other scenarios, allowing limited filtering based on HTTP request parameters > is supported. The HTTP request parameters should be processed prior to > filtering to provide optimal matching. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12483 Streamline JMX Metrics Filtering Parameters [nifi]
asfgit closed pull request #8134: NIFI-12483 Streamline JMX Metrics Filtering Parameters URL: https://github.com/apache/nifi/pull/8134 -- 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
Re: [PR] NIFI-12236 Improving fault tolerancy of the QuestDB backed metrics repository [nifi]
exceptionfactory commented on code in PR #8123:
URL: https://github.com/apache/nifi/pull/8123#discussion_r1419100364
##
nifi-api/src/main/java/org/apache/nifi/controller/status/ConnectionStatus.java:
##
@@ -22,6 +22,7 @@
/**
*/
public class ConnectionStatus implements Cloneable {
+private long createdAtInMs;
Review Comment:
Thanks for the reply @simonbence.
Reviewing the usage, in particular reference to `AbstractEventAccess`, the
`created` timestamp here appears somewhat ambiguous. The usage in
`AbstractEventAccess` appears to populate this value based on the current
system time. From that perspective, `created` appears to mean the time at which
the Status object was created. However, the rest of the properties in the
Status object refer to the referenced object itself, such as the Connection or
Process Group. From that perspective, I would have expected a created timestamp
to mean the time at which the component was created. This highlights the
problem with adding this property to the NiFi API.
Although it might be possible to clarify the ambiguity with a different
name, it still falls into a different category than all of the other properties.
--
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
Re: [PR] NIFI-12488: Add support for dynamic sensitive properties for the ExecuteProcess processor [nifi]
lfrancke commented on PR #8138: URL: https://github.com/apache/nifi/pull/8138#issuecomment-1845496704 Thank you for the review and the detailed hints. I'll take a look but unfortunately my time for this is limited. But I'll see what I can do! I have to admit that I only looked at one blog post and the PR for ExecuteScript and missed those changes. -- 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
Re: [PR] NIFI-12236 Improving fault tolerancy of the QuestDB backed metrics repository [nifi]
simonbence commented on code in PR #8123:
URL: https://github.com/apache/nifi/pull/8123#discussion_r1419082031
##
nifi-api/src/main/java/org/apache/nifi/controller/status/ConnectionStatus.java:
##
@@ -22,6 +22,7 @@
/**
*/
public class ConnectionStatus implements Cloneable {
+private long createdAtInMs;
Review Comment:
The implementation was the trigger for the change but not the sole reason.
The idea was -based on how we use these- that the state snapshot and the time
of relevance travels together in many times which makes it suspicious that they
should be boundled together. I will not touch until you make your rounds, let's
discuss after that how you feel about the approach.
--
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-12475) Disable Bypass Validation by Default in PutMongoRecord
[
https://issues.apache.org/jira/browse/NIFI-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12475:
Issue Type: Improvement (was: Bug)
> Disable Bypass Validation by Default in PutMongoRecord
> --
>
> Key: NIFI-12475
> URL: https://issues.apache.org/jira/browse/NIFI-12475
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 2.0.0-M1, 1.16.1, 1.24.0
> Environment: based on standard container apache/nifi from docker hub
> no customer processors.
>Reporter: Patrick A. Mol
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Across a few versions of NiFi and Mongo,
> the use of PutMongoRecord suddenly stopped working and returned an error.
> Using a flowfile with one valid record, and on PutMongoRecord failure,
> sending the flowfile to SplitRecord and feeding it to PutMongo, using the
> same standard mongodb controller service, the insert would work without error.
> Turns out that the default setting for the PutMongoRecord property Bypass
> Validation is {_}True{_}, which requires elevated privileges in Mongo.
> Changing the property to False allows insert without error.
> The error text is
> {noformat}
> PutMongoRecord[id=018b1026-a670-1590-7941-b6978c972dc6] PutMongoRecord failed
> with error:: com.mongodb.MongoCommandException: Command failed with error 13
> (Unauthorized): 'not authorized on MONGO_DATABASE_NAME to execute command {
> insert: "COLLECTION_NAME", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: "MONGO_DATABASE_NAME", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID("722347df-2349-4ec5-88f2-867a946d9614") } }' on server
> MONGODB_URI_WITH_PORTNUMBER. The full response is {"ok": 0.0, "errmsg": "not
> authorized on MONGO_DATABASE_NAME to execute command { insert:
> \"COLLECTION_NAME\", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: \"MONGO_DATABASE_NAME\", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID(\"722347df-2349-4ec5-88f2-867a946d9614\") } }", "code": 13,
> "codeName": "Unauthorized", "$clusterTime": {"clusterTime": {"$timestamp":
> {"t": 1701736623, "i": 1}}, "signature": {"hash": {"$binary": {"base64":
> "YrJKNoaaf68Hx3mAGfByzHZOip0=", "subType": "00"}}, "keyId":
> 7264286828646105928}}, "operationTime": {"$timestamp": {"t": 1701736623, "i":
> 1}}}
> {noformat}
> Apparently, PutMongo does not use the same setting for the bypass document
> validation flag, so there is an inconsistency.
> Other libraries/tools, e.g. pymongo insert_many(), also default to False.
> Details regarding the privilege in MongoDB are here
> https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation
> With the privilege requiring a custom role in MongoDB, it is debatable
> whether the default setting to True is a bug or changing it to False is an
> improvement.
> At least the error and resolution is recorded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12475) Disable Bypass Validation by Default in PutMongoRecord
[
https://issues.apache.org/jira/browse/NIFI-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12475:
Status: Patch Available (was: Open)
> Disable Bypass Validation by Default in PutMongoRecord
> --
>
> Key: NIFI-12475
> URL: https://issues.apache.org/jira/browse/NIFI-12475
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.24.0, 1.16.1, 2.0.0-M1
> Environment: based on standard container apache/nifi from docker hub
> no customer processors.
>Reporter: Patrick A. Mol
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Across a few versions of NiFi and Mongo,
> the use of PutMongoRecord suddenly stopped working and returned an error.
> Using a flowfile with one valid record, and on PutMongoRecord failure,
> sending the flowfile to SplitRecord and feeding it to PutMongo, using the
> same standard mongodb controller service, the insert would work without error.
> Turns out that the default setting for the PutMongoRecord property Bypass
> Validation is {_}True{_}, which requires elevated privileges in Mongo.
> Changing the property to False allows insert without error.
> The error text is
> {noformat}
> PutMongoRecord[id=018b1026-a670-1590-7941-b6978c972dc6] PutMongoRecord failed
> with error:: com.mongodb.MongoCommandException: Command failed with error 13
> (Unauthorized): 'not authorized on MONGO_DATABASE_NAME to execute command {
> insert: "COLLECTION_NAME", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: "MONGO_DATABASE_NAME", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID("722347df-2349-4ec5-88f2-867a946d9614") } }' on server
> MONGODB_URI_WITH_PORTNUMBER. The full response is {"ok": 0.0, "errmsg": "not
> authorized on MONGO_DATABASE_NAME to execute command { insert:
> \"COLLECTION_NAME\", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: \"MONGO_DATABASE_NAME\", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID(\"722347df-2349-4ec5-88f2-867a946d9614\") } }", "code": 13,
> "codeName": "Unauthorized", "$clusterTime": {"clusterTime": {"$timestamp":
> {"t": 1701736623, "i": 1}}, "signature": {"hash": {"$binary": {"base64":
> "YrJKNoaaf68Hx3mAGfByzHZOip0=", "subType": "00"}}, "keyId":
> 7264286828646105928}}, "operationTime": {"$timestamp": {"t": 1701736623, "i":
> 1}}}
> {noformat}
> Apparently, PutMongo does not use the same setting for the bypass document
> validation flag, so there is an inconsistency.
> Other libraries/tools, e.g. pymongo insert_many(), also default to False.
> Details regarding the privilege in MongoDB are here
> https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation
> With the privilege requiring a custom role in MongoDB, it is debatable
> whether the default setting to True is a bug or changing it to False is an
> improvement.
> At least the error and resolution is recorded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] NIFI-12475 Disable Bypass Validation by Default in PutMongoRecord [nifi]
exceptionfactory opened a new pull request, #8139: URL: https://github.com/apache/nifi/pull/8139 # Summary [NIFI-12475](https://issues.apache.org/jira/browse/NIFI-12475) Updates the default setting for the `Bypass Validation` property in `PutMongoRecord` to `False`. As noted in the expanded property description and the referenced Jira issue, bypassing document validation requires additional permissions beyond basic insert and update privileges. This property should be set to `False` by default to align with the same behavior in `PutMongo`, and also to highlight the elevated permissions required as described in [MongoDB Privilege Actions](https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation) documentation. # 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 21 ### 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] [Updated] (NIFI-12475) Disable Bypass Validation by Default in PutMongoRecord
[
https://issues.apache.org/jira/browse/NIFI-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12475:
Labels: (was: backport-needed)
> Disable Bypass Validation by Default in PutMongoRecord
> --
>
> Key: NIFI-12475
> URL: https://issues.apache.org/jira/browse/NIFI-12475
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M1, 1.16.1, 1.24.0
> Environment: based on standard container apache/nifi from docker hub
> no customer processors.
>Reporter: Patrick A. Mol
>Assignee: David Handermann
>Priority: Minor
>
> Across a few versions of NiFi and Mongo,
> the use of PutMongoRecord suddenly stopped working and returned an error.
> Using a flowfile with one valid record, and on PutMongoRecord failure,
> sending the flowfile to SplitRecord and feeding it to PutMongo, using the
> same standard mongodb controller service, the insert would work without error.
> Turns out that the default setting for the PutMongoRecord property Bypass
> Validation is {_}True{_}, which requires elevated privileges in Mongo.
> Changing the property to False allows insert without error.
> The error text is
> {noformat}
> PutMongoRecord[id=018b1026-a670-1590-7941-b6978c972dc6] PutMongoRecord failed
> with error:: com.mongodb.MongoCommandException: Command failed with error 13
> (Unauthorized): 'not authorized on MONGO_DATABASE_NAME to execute command {
> insert: "COLLECTION_NAME", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: "MONGO_DATABASE_NAME", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID("722347df-2349-4ec5-88f2-867a946d9614") } }' on server
> MONGODB_URI_WITH_PORTNUMBER. The full response is {"ok": 0.0, "errmsg": "not
> authorized on MONGO_DATABASE_NAME to execute command { insert:
> \"COLLECTION_NAME\", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: \"MONGO_DATABASE_NAME\", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID(\"722347df-2349-4ec5-88f2-867a946d9614\") } }", "code": 13,
> "codeName": "Unauthorized", "$clusterTime": {"clusterTime": {"$timestamp":
> {"t": 1701736623, "i": 1}}, "signature": {"hash": {"$binary": {"base64":
> "YrJKNoaaf68Hx3mAGfByzHZOip0=", "subType": "00"}}, "keyId":
> 7264286828646105928}}, "operationTime": {"$timestamp": {"t": 1701736623, "i":
> 1}}}
> {noformat}
> Apparently, PutMongo does not use the same setting for the bypass document
> validation flag, so there is an inconsistency.
> Other libraries/tools, e.g. pymongo insert_many(), also default to False.
> Details regarding the privilege in MongoDB are here
> https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation
> With the privilege requiring a custom role in MongoDB, it is debatable
> whether the default setting to True is a bug or changing it to False is an
> improvement.
> At least the error and resolution is recorded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12475) Disable Bypass Validation by Default in PutMongoRecord
[
https://issues.apache.org/jira/browse/NIFI-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12475:
Labels: backport-needed (was: )
> Disable Bypass Validation by Default in PutMongoRecord
> --
>
> Key: NIFI-12475
> URL: https://issues.apache.org/jira/browse/NIFI-12475
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M1, 1.16.1, 1.24.0
> Environment: based on standard container apache/nifi from docker hub
> no customer processors.
>Reporter: Patrick A. Mol
>Assignee: David Handermann
>Priority: Minor
> Labels: backport-needed
>
> Across a few versions of NiFi and Mongo,
> the use of PutMongoRecord suddenly stopped working and returned an error.
> Using a flowfile with one valid record, and on PutMongoRecord failure,
> sending the flowfile to SplitRecord and feeding it to PutMongo, using the
> same standard mongodb controller service, the insert would work without error.
> Turns out that the default setting for the PutMongoRecord property Bypass
> Validation is {_}True{_}, which requires elevated privileges in Mongo.
> Changing the property to False allows insert without error.
> The error text is
> {noformat}
> PutMongoRecord[id=018b1026-a670-1590-7941-b6978c972dc6] PutMongoRecord failed
> with error:: com.mongodb.MongoCommandException: Command failed with error 13
> (Unauthorized): 'not authorized on MONGO_DATABASE_NAME to execute command {
> insert: "COLLECTION_NAME", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: "MONGO_DATABASE_NAME", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID("722347df-2349-4ec5-88f2-867a946d9614") } }' on server
> MONGODB_URI_WITH_PORTNUMBER. The full response is {"ok": 0.0, "errmsg": "not
> authorized on MONGO_DATABASE_NAME to execute command { insert:
> \"COLLECTION_NAME\", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: \"MONGO_DATABASE_NAME\", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID(\"722347df-2349-4ec5-88f2-867a946d9614\") } }", "code": 13,
> "codeName": "Unauthorized", "$clusterTime": {"clusterTime": {"$timestamp":
> {"t": 1701736623, "i": 1}}, "signature": {"hash": {"$binary": {"base64":
> "YrJKNoaaf68Hx3mAGfByzHZOip0=", "subType": "00"}}, "keyId":
> 7264286828646105928}}, "operationTime": {"$timestamp": {"t": 1701736623, "i":
> 1}}}
> {noformat}
> Apparently, PutMongo does not use the same setting for the bypass document
> validation flag, so there is an inconsistency.
> Other libraries/tools, e.g. pymongo insert_many(), also default to False.
> Details regarding the privilege in MongoDB are here
> https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation
> With the privilege requiring a custom role in MongoDB, it is debatable
> whether the default setting to True is a bug or changing it to False is an
> improvement.
> At least the error and resolution is recorded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12475) Disable Bypass Validation by Default in PutMongoRecord
[
https://issues.apache.org/jira/browse/NIFI-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12475:
Affects Version/s: 1.24.0
2.0.0-M1
> Disable Bypass Validation by Default in PutMongoRecord
> --
>
> Key: NIFI-12475
> URL: https://issues.apache.org/jira/browse/NIFI-12475
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M1, 1.16.1, 1.24.0
> Environment: based on standard container apache/nifi from docker hub
> no customer processors.
>Reporter: Patrick A. Mol
>Assignee: David Handermann
>Priority: Minor
>
> Across a few versions of NiFi and Mongo,
> the use of PutMongoRecord suddenly stopped working and returned an error.
> Using a flowfile with one valid record, and on PutMongoRecord failure,
> sending the flowfile to SplitRecord and feeding it to PutMongo, using the
> same standard mongodb controller service, the insert would work without error.
> Turns out that the default setting for the PutMongoRecord property Bypass
> Validation is {_}True{_}, which requires elevated privileges in Mongo.
> Changing the property to False allows insert without error.
> The error text is
> {noformat}
> PutMongoRecord[id=018b1026-a670-1590-7941-b6978c972dc6] PutMongoRecord failed
> with error:: com.mongodb.MongoCommandException: Command failed with error 13
> (Unauthorized): 'not authorized on MONGO_DATABASE_NAME to execute command {
> insert: "COLLECTION_NAME", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: "MONGO_DATABASE_NAME", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID("722347df-2349-4ec5-88f2-867a946d9614") } }' on server
> MONGODB_URI_WITH_PORTNUMBER. The full response is {"ok": 0.0, "errmsg": "not
> authorized on MONGO_DATABASE_NAME to execute command { insert:
> \"COLLECTION_NAME\", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: \"MONGO_DATABASE_NAME\", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID(\"722347df-2349-4ec5-88f2-867a946d9614\") } }", "code": 13,
> "codeName": "Unauthorized", "$clusterTime": {"clusterTime": {"$timestamp":
> {"t": 1701736623, "i": 1}}, "signature": {"hash": {"$binary": {"base64":
> "YrJKNoaaf68Hx3mAGfByzHZOip0=", "subType": "00"}}, "keyId":
> 7264286828646105928}}, "operationTime": {"$timestamp": {"t": 1701736623, "i":
> 1}}}
> {noformat}
> Apparently, PutMongo does not use the same setting for the bypass document
> validation flag, so there is an inconsistency.
> Other libraries/tools, e.g. pymongo insert_many(), also default to False.
> Details regarding the privilege in MongoDB are here
> https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation
> With the privilege requiring a custom role in MongoDB, it is debatable
> whether the default setting to True is a bug or changing it to False is an
> improvement.
> At least the error and resolution is recorded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12475) Disable Bypass Validation by Default in PutMongoRecord
[
https://issues.apache.org/jira/browse/NIFI-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12475:
Summary: Disable Bypass Validation by Default in PutMongoRecord (was:
Bypass Validation property set to True returns Authorization error.)
> Disable Bypass Validation by Default in PutMongoRecord
> --
>
> Key: NIFI-12475
> URL: https://issues.apache.org/jira/browse/NIFI-12475
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.16.1
> Environment: based on standard container apache/nifi from docker hub
> no customer processors.
>Reporter: Patrick A. Mol
>Assignee: David Handermann
>Priority: Minor
>
> Across a few versions of NiFi and Mongo,
> the use of PutMongoRecord suddenly stopped working and returned an error.
> Using a flowfile with one valid record, and on PutMongoRecord failure,
> sending the flowfile to SplitRecord and feeding it to PutMongo, using the
> same standard mongodb controller service, the insert would work without error.
> Turns out that the default setting for the PutMongoRecord property Bypass
> Validation is {_}True{_}, which requires elevated privileges in Mongo.
> Changing the property to False allows insert without error.
> The error text is
> {noformat}
> PutMongoRecord[id=018b1026-a670-1590-7941-b6978c972dc6] PutMongoRecord failed
> with error:: com.mongodb.MongoCommandException: Command failed with error 13
> (Unauthorized): 'not authorized on MONGO_DATABASE_NAME to execute command {
> insert: "COLLECTION_NAME", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: "MONGO_DATABASE_NAME", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID("722347df-2349-4ec5-88f2-867a946d9614") } }' on server
> MONGODB_URI_WITH_PORTNUMBER. The full response is {"ok": 0.0, "errmsg": "not
> authorized on MONGO_DATABASE_NAME to execute command { insert:
> \"COLLECTION_NAME\", ordered: false, bypassDocumentValidation: true,
> txnNumber: 1, $db: \"MONGO_DATABASE_NAME\", $clusterTime: { clusterTime:
> Timestamp(1701736623, 1), signature: { hash: BinData(0,
> 62B24A36869A7FAF07C7798019F072CC764E8A9D), keyId: 7264286828646105928 } },
> lsid: { id: UUID(\"722347df-2349-4ec5-88f2-867a946d9614\") } }", "code": 13,
> "codeName": "Unauthorized", "$clusterTime": {"clusterTime": {"$timestamp":
> {"t": 1701736623, "i": 1}}, "signature": {"hash": {"$binary": {"base64":
> "YrJKNoaaf68Hx3mAGfByzHZOip0=", "subType": "00"}}, "keyId":
> 7264286828646105928}}, "operationTime": {"$timestamp": {"t": 1701736623, "i":
> 1}}}
> {noformat}
> Apparently, PutMongo does not use the same setting for the bypass document
> validation flag, so there is an inconsistency.
> Other libraries/tools, e.g. pymongo insert_many(), also default to False.
> Details regarding the privilege in MongoDB are here
> https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-bypassDocumentValidation
> With the privilege requiring a custom role in MongoDB, it is debatable
> whether the default setting to True is a bug or changing it to False is an
> improvement.
> At least the error and resolution is recorded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794244#comment-17794244 ] Simon Bence commented on NIFI-12236: Hei [~pvillard]! Thanks for mentioning the admin guide! I forgot to add the newly wired out properties indeed. I will add those during the review. 1. I think we agreed on the defaulting, with review changes it will be changed back as well 2. As this looks to be more a nuanced question and I already have a discussion about it on the PR with David Hendermann, I suggest to continue this topic there. I am open for reverting those changes but before just doing that, I would like to be sure that the intentions for the change are clear. 3. I am not sure what Joe meant under moving it into a nar. If it is the already mentioned pluggability (which I totally in line with in the long run) I think it is not something to add to this PR, which is more like a glorified refactor story. If it is about something else, could you please specifiy it [~joewitt] ? (Note: the actual QuestDB related code is in a separate jar. All the code remained in the `nifi-framework-core` is related to the actual repository implementation (counterpart of the Volatile implementation > Improving fault tolerancy of the QuestDB backed metrics repository > -- > > Key: NIFI-12236 > URL: https://issues.apache.org/jira/browse/NIFI-12236 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Based on the related discussion on the dev email list, the QuestDB handling > of the metrics repository needs to be improved to have better fault tolerance > in order to be possible to use as a viable option for default metrics data > store. This should primarily focus on handling unexpeted database events like > corrupted database or loss of space on the disk. Any issues should be handled > with an attempt to keep the database service healthy but in case of that is > impossible, the priority is to keep NiFi and the core services running, even > with the price of metrics collection / presentation outage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[ https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794244#comment-17794244 ] Simon Bence edited comment on NIFI-12236 at 12/7/23 2:36 PM: - Hi [~pvillard]! Thanks for mentioning the admin guide! I forgot to add the newly wired out properties indeed. I will add those during the review. 1. I think we agreed on the defaulting, with review changes it will be changed back as well 2. As this looks to be more a nuanced question and I already have a discussion about it on the PR with David Hendermann, I suggest to continue this topic there. I am open for reverting those changes but before just doing that, I would like to be sure that the intentions for the change are clear. 3. I am not sure what Joe meant under moving it into a nar. If it is the already mentioned pluggability (which I totally in line with in the long run) I think it is not something to add to this PR, which is more like a glorified refactor story. If it is about something else, could you please specifiy it [~joewitt] ? (Note: the actual QuestDB related code is in a separate jar. All the code remained in the `nifi-framework-core` is related to the actual repository implementation (counterpart of the Volatile implementation was (Author: simonbence): Hei [~pvillard]! Thanks for mentioning the admin guide! I forgot to add the newly wired out properties indeed. I will add those during the review. 1. I think we agreed on the defaulting, with review changes it will be changed back as well 2. As this looks to be more a nuanced question and I already have a discussion about it on the PR with David Hendermann, I suggest to continue this topic there. I am open for reverting those changes but before just doing that, I would like to be sure that the intentions for the change are clear. 3. I am not sure what Joe meant under moving it into a nar. If it is the already mentioned pluggability (which I totally in line with in the long run) I think it is not something to add to this PR, which is more like a glorified refactor story. If it is about something else, could you please specifiy it [~joewitt] ? (Note: the actual QuestDB related code is in a separate jar. All the code remained in the `nifi-framework-core` is related to the actual repository implementation (counterpart of the Volatile implementation > Improving fault tolerancy of the QuestDB backed metrics repository > -- > > Key: NIFI-12236 > URL: https://issues.apache.org/jira/browse/NIFI-12236 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Based on the related discussion on the dev email list, the QuestDB handling > of the metrics repository needs to be improved to have better fault tolerance > in order to be possible to use as a viable option for default metrics data > store. This should primarily focus on handling unexpeted database events like > corrupted database or loss of space on the disk. Any issues should be handled > with an attempt to keep the database service healthy but in case of that is > impossible, the priority is to keep NiFi and the core services running, even > with the price of metrics collection / presentation outage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12351 Improve MiNiFi Service Scripts for Windows [nifi]
rliszli commented on code in PR #8015: URL: https://github.com/apache/nifi/pull/8015#discussion_r1419023938 ## minifi/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-resources/src/main/resources/bin/delete-service.bat: ## @@ -16,8 +16,16 @@ remSee the License for the specific language governing permissions and remlimitations under the License. rem -set SERVICE_NAME=minifi -set SRV_BIN=%SERVICE_NAME%.exe - -REM Remove service -%SRV_BIN% //DS//%SERVICE_NAME% +setlocal enabledelayedexpansion + +set arg1=%1 +if "!arg1:~1,11!" equ "serviceName" ( Review Comment: Unfortunatelly I tried a lot of ways to do this. For example, the suggested _findstr_ cannot be applied inside an if condition. Honestly I don't like this either, as most part of how bat script working, but this was the "cleanest" or "simpliest" as I could find. ## minifi/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-resources/src/main/resources/bin/install-service.bat: ## @@ -16,13 +16,77 @@ remSee the License for the specific language governing permissions and remlimitations under the License. rem -call minifi-env.bat +call %~sdp0\minifi-env.bat -set CONF_DIR=%MINIFI_ROOT%conf +setlocal enabledelayedexpansion +set "arg1=" +set "arg2=" +set "arg3=" +set "errorFlag=0" + +set "argCount=0" +for %%A in (%*) do ( Review Comment: Thanks, good idea, applied. Made the "code" much cleaner. ## minifi/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-resources/src/main/resources/bin/install-service.bat: ## @@ -16,13 +16,77 @@ remSee the License for the specific language governing permissions and remlimitations under the License. rem -call minifi-env.bat +call %~sdp0\minifi-env.bat -set CONF_DIR=%MINIFI_ROOT%conf +setlocal enabledelayedexpansion +set "arg1=" +set "arg2=" +set "arg3=" +set "errorFlag=0" + +set "argCount=0" +for %%A in (%*) do ( +set /a "argCount+=1" + +if !argCount! equ 1 set "arg1=%%~A" +if !argCount! equ 2 set "arg2=%%~A" +if !argCount! equ 3 set "arg3=%%~A" + +if !argCount! geq 4 ( +set "errorFlag=tooManyArguments" +goto :error +) + + if "!arg1:~0,11!" equ "serviceName" ( Review Comment: Thanks, should be fine now. ## minifi/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-resources/src/main/resources/bin/install-service.bat: ## @@ -65,12 +125,21 @@ set LOG_PREFIX=minifi.log --StopMethod="%STOP_METHOD%" ^ --StopTimeout="%STOP_TIMEOUT%" ^ --Classpath="%CLASS_PATH%" ^ ---JvmOptions="%JAVA_ARGS%" ^ +--JvmOptions9="%JAVA_ARGS%" ^ Review Comment: :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12351 Improve MiNiFi Service Scripts for Windows [nifi]
rliszli commented on PR #8015: URL: https://github.com/apache/nifi/pull/8015#issuecomment-1845418710 `Thanks for the changes it is an area which clearly can benefit from some improvement. Maybe something is not right on my side but I'm getting the following` Previously I only tested it on Windows 10. After this included Windows Server 2019 as well. Now should work on both. -- 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-12484) Bump dependency versions
[ https://issues.apache.org/jira/browse/NIFI-12484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794222#comment-17794222 ] ASF subversion and git services commented on NIFI-12484: Commit 17a331b9e14e3772137b18699b8c1d33cc11bc79 in nifi's branch refs/heads/main from Matt Gilman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=17a331b9e1 ] NIFI-12484: Bumping dependency to latest minor/incremental release (#8135) - Bumping dependency to latest minor/incremental release. - Adding an explicit override for vite which is needed until Angular can be upgraded to version 17. This closes #8135 > Bump dependency versions > > > Key: NIFI-12484 > URL: https://issues.apache.org/jira/browse/NIFI-12484 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12484) Bump dependency versions
[ https://issues.apache.org/jira/browse/NIFI-12484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows resolved NIFI-12484. Fix Version/s: 2.0.0 Resolution: Fixed > Bump dependency versions > > > Key: NIFI-12484 > URL: https://issues.apache.org/jira/browse/NIFI-12484 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12484: Bumping dependency to latest minor/incremental release [nifi]
rfellows merged PR #8135: URL: https://github.com/apache/nifi/pull/8135 -- 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-12236) Improving fault tolerancy of the QuestDB backed metrics repository
[
https://issues.apache.org/jira/browse/NIFI-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794214#comment-17794214
]
Pierre Villard commented on NIFI-12236:
---
I definitely agree on the documentation aspect and it'd be nice to have the PR
update the admin-guide with as much documentation as possible regarding this
implementation (its value, its configuration, etc).
There is already a bit here:
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#persistent-repository]
Regarding your points:
{quote} # Avoid making this the default. It can be opted into.{quote}
Definite agree here. Let's not change the default at this point.
{quote}2. Avoid making nifi-api changes.
{quote}
I believe [~simonbence] gave the reasons as why the changes are making sense
and since we're still working towards NiFi 2.0, I believe this is worth
discussing but I believe the current work can also be done without API change
if that's the real blocker.
{quote}3. Move this into its own nar instead of the core framework nar. It can
certainly still be included as it is today.
{quote}
Yeah, ideally every repository in NiFi could be a pluggable endpoint where a
NAR can be provided with a given implementation. I'd see a lot of value there
and I believe it's been mentioned a few times in the community. However, making
the repositories a pluggable endpoint would likely be a significant effort and,
in my opinion, it should be a follow up effort, not a prerequisite for the
current work to be included (which is what you said, if I understood you
correctly).
> Improving fault tolerancy of the QuestDB backed metrics repository
> --
>
> Key: NIFI-12236
> URL: https://issues.apache.org/jira/browse/NIFI-12236
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: Simon Bence
>Assignee: Simon Bence
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Based on the related discussion on the dev email list, the QuestDB handling
> of the metrics repository needs to be improved to have better fault tolerance
> in order to be possible to use as a viable option for default metrics data
> store. This should primarily focus on handling unexpeted database events like
> corrupted database or loss of space on the disk. Any issues should be handled
> with an attempt to keep the database service healthy but in case of that is
> impossible, the priority is to keep NiFi and the core services running, even
> with the price of metrics collection / presentation outage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12445: Provenance Event Listing [nifi]
rfellows commented on PR #8133: URL: https://github.com/apache/nifi/pull/8133#issuecomment-1845360895 Will Review -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12484: Bumping dependency to latest minor/incremental release [nifi]
rfellows commented on PR #8135: URL: https://github.com/apache/nifi/pull/8135#issuecomment-1845354794 reviewing... -- 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
Re: [PR] MINIFICPP-1415 Pass references to onTrigger and onSchedule instead of… [nifi-minifi-cpp]
szaszm commented on code in PR #1693: URL: https://github.com/apache/nifi-minifi-cpp/pull/1693#discussion_r1418972284 ## extensions/splunk/PutSplunkHTTP.cpp: ## Review Comment: In this case, I guess we can leave it as is for now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-12470) UI - Fix layout/formatting in Status History
[ https://issues.apache.org/jira/browse/NIFI-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794207#comment-17794207 ] ASF subversion and git services commented on NIFI-12470: Commit aa575de6e26a6a8e2564e52d84f848912debf7bb in nifi's branch refs/heads/support/nifi-1.x from Matt Gilman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=aa575de6e2 ] NIFI-12470: Fixing forEach callback for usage with Object.entries() to address layout issue in Status History (#8121) * NIFI-12470: - Fixing forEach callback for usage with Object.entries() to address layout issue in Status History. - Using es5 syntax. This closes #8121 > UI - Fix layout/formatting in Status History > > > Key: NIFI-12470 > URL: https://issues.apache.org/jira/browse/NIFI-12470 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 2.0.0 > > Attachments: Screenshot 2023-12-04 at 4.48.29 PM.png > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12470) UI - Fix layout/formatting in Status History
[ https://issues.apache.org/jira/browse/NIFI-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows updated NIFI-12470: --- Fix Version/s: 1.25.0 > UI - Fix layout/formatting in Status History > > > Key: NIFI-12470 > URL: https://issues.apache.org/jira/browse/NIFI-12470 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.25.0, 2.0.0 > > Attachments: Screenshot 2023-12-04 at 4.48.29 PM.png > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12470) UI - Fix layout/formatting in Status History
[ https://issues.apache.org/jira/browse/NIFI-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows resolved NIFI-12470. Fix Version/s: 2.0.0 Resolution: Fixed > UI - Fix layout/formatting in Status History > > > Key: NIFI-12470 > URL: https://issues.apache.org/jira/browse/NIFI-12470 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 2.0.0 > > Attachments: Screenshot 2023-12-04 at 4.48.29 PM.png > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12470) UI - Fix layout/formatting in Status History
[ https://issues.apache.org/jira/browse/NIFI-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794203#comment-17794203 ] ASF subversion and git services commented on NIFI-12470: Commit 414eea805f4c639f65fd029d2e2066ce8bad341d in nifi's branch refs/heads/main from Matt Gilman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=414eea805f ] NIFI-12470: Fixing forEach callback for usage with Object.entries() to address layout issue in Status History (#8121) * NIFI-12470: - Fixing forEach callback for usage with Object.entries() to address layout issue in Status History. - Using es5 syntax. This closes #8121 > UI - Fix layout/formatting in Status History > > > Key: NIFI-12470 > URL: https://issues.apache.org/jira/browse/NIFI-12470 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2023-12-04 at 4.48.29 PM.png > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12470: Fixing forEach callback for usage with Object.entries() to address layout issue in Status History [nifi]
rfellows merged PR #8121: URL: https://github.com/apache/nifi/pull/8121 -- 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-6515) FetchParquet max FlowFile size
[
https://issues.apache.org/jira/browse/NIFI-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794201#comment-17794201
]
Lars Francke commented on NIFI-6515:
We are stumbling across this as well now.
We have to read a 23GB Parquet file, currently using {{FetchParquet}} but it
seems as if that'll read the whole file in memory before passing it on.
It takes a long time and we get timeouts in various parts of the system.
We really would like the option of FetchParquet already splitting the data up
into batches (e.g. by size or count) as low as one FlowFile per record.
Has anyone here found a solution? If not I might consider expanding this
Processor.
> FetchParquet max FlowFile size
> --
>
> Key: NIFI-6515
> URL: https://issues.apache.org/jira/browse/NIFI-6515
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Matt Gilman
>Priority: Major
>
> FetchParquet cannot transfer out multiple FlowFiles. We should introduce a
> new property to set the size of the outgoing FlowFile and then transfer as
> many FlowFiles as needed based on the fetched data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MINIFICPP-2271) Upgrade AWS SDK C++ and add new AWS regions
[ https://issues.apache.org/jira/browse/MINIFICPP-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reassigned MINIFICPP-2271: --- Assignee: Marton Szasz > Upgrade AWS SDK C++ and add new AWS regions > --- > > Key: MINIFICPP-2271 > URL: https://issues.apache.org/jira/browse/MINIFICPP-2271 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marton Szasz >Assignee: Marton Szasz >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] MINIFICPP-2271 update AWS SDK and regions [nifi-minifi-cpp]
szaszm opened a new pull request, #1705: URL: https://github.com/apache/nifi-minifi-cpp/pull/1705 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically main)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [x] If applicable, have you updated the LICENSE file? - [x] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [x] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check 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
Re: [PR] NIFI-12470: Fixing forEach callback for usage with Object.entries() to address layout issue in Status History [nifi]
rfellows commented on PR #8121: URL: https://github.com/apache/nifi/pull/8121#issuecomment-1845311495 reviewing... -- 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-2271) Upgrade AWS SDK C++ and add new AWS regions
Marton Szasz created MINIFICPP-2271: --- Summary: Upgrade AWS SDK C++ and add new AWS regions Key: MINIFICPP-2271 URL: https://issues.apache.org/jira/browse/MINIFICPP-2271 Project: Apache NiFi MiNiFi C++ Issue Type: Improvement Reporter: Marton Szasz -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12488: Add support for dynamic sensitive properties for the ExecuteProcess processor [nifi]
lfrancke commented on PR #8138: URL: https://github.com/apache/nifi/pull/8138#issuecomment-1845242512 The build failed for me locally but on totally unrelated tests (Registry) so I assume it's okay. -- 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] [Resolved] (NIFI-12477) Update org.apache.commons.io.version to 2.15.1
[ https://issues.apache.org/jira/browse/NIFI-12477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12477. --- Fix Version/s: 1.25.0 2.0.0 Resolution: Fixed > Update org.apache.commons.io.version to 2.15.1 > -- > > Key: NIFI-12477 > URL: https://issues.apache.org/jira/browse/NIFI-12477 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Priority: Minor > Fix For: 1.25.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Update org.apache.commons.io.version to 2.15.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12473) Delete Pattern-based Remove Methods from Cache Client Services
[ https://issues.apache.org/jira/browse/NIFI-12473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12473: -- Fix Version/s: 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Delete Pattern-based Remove Methods from Cache Client Services > -- > > Key: NIFI-12473 > URL: https://issues.apache.org/jira/browse/NIFI-12473 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 2.0.0-M1 >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The DistributedMapCacheClient Controller Service interface has methods to > remove elements based on cache keys matching a regular expression. Cache > Service implementations have implemented this method at different levels, but > no Processors or other components use these interface methods. With the only > reference to these methods contained in test classes, the removeByPattern > methods should be removed from the Controller Service interface and from > implementation classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12473) Delete Pattern-based Remove Methods from Cache Client Services
[ https://issues.apache.org/jira/browse/NIFI-12473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794140#comment-17794140 ] ASF subversion and git services commented on NIFI-12473: Commit 34aebc1f6995a08526fccb8551a0a18e25ff1f98 in nifi's branch refs/heads/main from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=34aebc1f69 ] NIFI-12473 Deleted removeByPattern Methods from Cache Services Signed-off-by: Pierre Villard This closes #8124. > Delete Pattern-based Remove Methods from Cache Client Services > -- > > Key: NIFI-12473 > URL: https://issues.apache.org/jira/browse/NIFI-12473 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 2.0.0-M1 >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The DistributedMapCacheClient Controller Service interface has methods to > remove elements based on cache keys matching a regular expression. Cache > Service implementations have implemented this method at different levels, but > no Processors or other components use these interface methods. With the only > reference to these methods contained in test classes, the removeByPattern > methods should be removed from the Controller Service interface and from > implementation classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12473 Delete removeByPattern Methods from Cache Services [nifi]
asfgit closed pull request #8124: NIFI-12473 Delete removeByPattern Methods from Cache Services URL: https://github.com/apache/nifi/pull/8124 -- 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
