[jira] [Created] (NIFI-13087) Referencing Components not accurate linked to Parameter using in Advanced Rules for UpdateAttribute
Mark Bean created NIFI-13087:
Summary: Referencing Components not accurate linked to Parameter
using in Advanced Rules for UpdateAttribute
Key: NIFI-13087
URL: https://issues.apache.org/jira/browse/NIFI-13087
Project: Apache NiFi
Issue Type: Bug
Reporter: Mark Bean
Parameters may be used in Advanced Rules of the UpdateAttribute processor. For
example, a condition value may be something like:
${#\{param1}:equals("value-for-param1")}
When this is used, the UpdateAttribute processor is not accurately shown as a
Referencing Component to the parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13004) Remove include-grpc from Developer Guide
[ https://issues.apache.org/jira/browse/NIFI-13004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-13004: - Status: Patch Available (was: In Progress) > Remove include-grpc from Developer Guide > > > Key: NIFI-13004 > URL: https://issues.apache.org/jira/browse/NIFI-13004 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 2.0.0-M2 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The `include-grpc` profile was removed in NIFI-12069. However, a reference to > it still remains in the Developer Guide. Remove the reference. And check for > other references. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-13004) Remove include-grpc from Developer Guide
[ https://issues.apache.org/jira/browse/NIFI-13004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-13004: Assignee: Mark Bean > Remove include-grpc from Developer Guide > > > Key: NIFI-13004 > URL: https://issues.apache.org/jira/browse/NIFI-13004 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 2.0.0-M2 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > The `include-grpc` profile was removed in NIFI-12069. However, a reference to > it still remains in the Developer Guide. Remove the reference. And check for > other references. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13004) Remove include-grpc from Developer Guide
Mark Bean created NIFI-13004: Summary: Remove include-grpc from Developer Guide Key: NIFI-13004 URL: https://issues.apache.org/jira/browse/NIFI-13004 Project: Apache NiFi Issue Type: Bug Affects Versions: 2.0.0-M2 Reporter: Mark Bean The `include-grpc` profile was removed in NIFI-12069. However, a reference to it still remains in the Developer Guide. Remove the reference. And check for other references. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12925) ListenHTTP should disable unused HTTP methods
[ https://issues.apache.org/jira/browse/NIFI-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829975#comment-17829975 ] Mark Bean commented on NIFI-12925: -- No, CONNECT already receives 400 response. > ListenHTTP should disable unused HTTP methods > - > > Key: NIFI-12925 > URL: https://issues.apache.org/jira/browse/NIFI-12925 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Michael W Moser >Assignee: Mark Bean >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > For [security > reasons|https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods], > ListenHTTP should reply with 405 Method Not Allowed for HTTP methods OPTIONS > and TRACE. > PUT already returns 405. > GET, POST, DELETE, HEAD are used by the processor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12925) ListenHTTP should disable unused HTTP methods
[ https://issues.apache.org/jira/browse/NIFI-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12925: - Status: Patch Available (was: In Progress) > ListenHTTP should disable unused HTTP methods > - > > Key: NIFI-12925 > URL: https://issues.apache.org/jira/browse/NIFI-12925 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Michael W Moser >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For [security > reasons|https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods], > ListenHTTP should reply with 405 Method Not Allowed for HTTP methods OPTIONS > and TRACE. > PUT already returns 405. > GET, POST, DELETE, HEAD are used by the processor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12925) ListenHTTP should disable unused HTTP methods
[ https://issues.apache.org/jira/browse/NIFI-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-12925: Assignee: Mark Bean > ListenHTTP should disable unused HTTP methods > - > > Key: NIFI-12925 > URL: https://issues.apache.org/jira/browse/NIFI-12925 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Michael W Moser >Assignee: Mark Bean >Priority: Major > > For [security > reasons|https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods], > ListenHTTP should reply with 405 Method Not Allowed for HTTP methods OPTIONS > and TRACE. > PUT already returns 405. > GET, POST, DELETE, HEAD are used by the processor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12701) RAT check failure
[ https://issues.apache.org/jira/browse/NIFI-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12701: - Status: Patch Available (was: In Progress) > RAT check failure > - > > Key: NIFI-12701 > URL: https://issues.apache.org/jira/browse/NIFI-12701 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > Files with unapproved licenses: > > nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi/.prettierignore > This file was introduced with NIFI-12686. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12701) RAT check failure
[ https://issues.apache.org/jira/browse/NIFI-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-12701: Assignee: Mark Bean > RAT check failure > - > > Key: NIFI-12701 > URL: https://issues.apache.org/jira/browse/NIFI-12701 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > Files with unapproved licenses: > > nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi/.prettierignore > This file was introduced with NIFI-12686. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12701) RAT check failure
Mark Bean created NIFI-12701: Summary: RAT check failure Key: NIFI-12701 URL: https://issues.apache.org/jira/browse/NIFI-12701 Project: Apache NiFi Issue Type: Bug Reporter: Mark Bean Files with unapproved licenses: nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi/.prettierignore This file was introduced with NIFI-12686. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12699) Unit test timeout value too short for systems with slow disks
Mark Bean created NIFI-12699: Summary: Unit test timeout value too short for systems with slow disks Key: NIFI-12699 URL: https://issues.apache.org/jira/browse/NIFI-12699 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Reporter: Mark Bean Assignee: Mark Bean When building NiFi on a VM with relatively old disks, a unit test consistently fails due timing out. The unit test in question is: TestStandardFlowFileQueue.testListFlowFilesResultsLimitedCollection Extend the timeout from 5 sec to 10 sec. The value of 10 allows consistent passing of this unit test. On systems with faster disks, this increase in timeout will be inconsequential, i.e. will not slow down the build. Yet, the extension will allow compilation on older systems. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-8968) Improve throughput performance for InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-8968: Attachment: Compare_Invoke_PostHTTP.json > Improve throughput performance for InvokeHTTP > - > > Key: NIFI-8968 > URL: https://issues.apache.org/jira/browse/NIFI-8968 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Mark Bean >Priority: Major > Attachments: Compare_Invoke_PostHTTP.json, > ListenHTTP-BytesOut-sizeFilter.PNG, ListenHTTP-BytesOut.PNG, > ListenHTTP-FFOut-sizeFilter.PNG, ListenHTTP-FFOut.PNG, > PostHTTP_vs_InvokeHTTP.json, PostHTTP_vs_InvokeHTTP.xml > > > InvokeHTTP is the preferred processor to use over the deprecated PostHTTP. > However, PostHTTP outperforms InvokeHTTP (at least in POST mode). A template > and a JSON file have been attached to this ticket for benchmarking the two > processors. Using this flow, PostHTTP was observed to have a throughput of > approximately 5 times greater than InvokeHTTP. > In addition, it was noted that InvokeHTTP had approximately 5 times as many > tasks and 5 times the task duration for a given 5 minute stats window. And, > the statistics of Bytes Read and Bytes Transferred remain at zero for > InvokeHTTP; this area accurate statistics also needs to be addressed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-8968) Improve throughput performance for InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-8968: Attachment: ListenHTTP-FFOut-sizeFilter.PNG ListenHTTP-BytesOut-sizeFilter.PNG > Improve throughput performance for InvokeHTTP > - > > Key: NIFI-8968 > URL: https://issues.apache.org/jira/browse/NIFI-8968 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Mark Bean >Priority: Major > Attachments: ListenHTTP-BytesOut-sizeFilter.PNG, > ListenHTTP-BytesOut.PNG, ListenHTTP-FFOut-sizeFilter.PNG, > ListenHTTP-FFOut.PNG, PostHTTP_vs_InvokeHTTP.json, PostHTTP_vs_InvokeHTTP.xml > > > InvokeHTTP is the preferred processor to use over the deprecated PostHTTP. > However, PostHTTP outperforms InvokeHTTP (at least in POST mode). A template > and a JSON file have been attached to this ticket for benchmarking the two > processors. Using this flow, PostHTTP was observed to have a throughput of > approximately 5 times greater than InvokeHTTP. > In addition, it was noted that InvokeHTTP had approximately 5 times as many > tasks and 5 times the task duration for a given 5 minute stats window. And, > the statistics of Bytes Read and Bytes Transferred remain at zero for > InvokeHTTP; this area accurate statistics also needs to be addressed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-8968) Improve throughput performance for InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808962#comment-17808962 ] Mark Bean commented on NIFI-8968: - I performed a similar test by using PackageFlowFile and InvokeHTTP. The flow consisted of 3 GenerateFlowFile processors running simultaneously generating files of sizes 1 KB, 1 MB and 100 MB. Three configurations where run: 1) GenerateFlowFile -> PackageFlowFile -> InvokeHTTP 2) GenerateFlowFile -> InvokeHTTP 3) GenerateFlowFile -> PostHTTP Each configuration was run for approximately 15 minutes. The status history graph for the corresponding ListenHTTP is attached. Bottom line: PostHTTP still shows best throughput. However, PackageFlowFile does improve the overall throughput for InvokeHTTP. > Improve throughput performance for InvokeHTTP > - > > Key: NIFI-8968 > URL: https://issues.apache.org/jira/browse/NIFI-8968 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Mark Bean >Priority: Major > Attachments: ListenHTTP-BytesOut.PNG, ListenHTTP-FFOut.PNG, > PostHTTP_vs_InvokeHTTP.json, PostHTTP_vs_InvokeHTTP.xml > > > InvokeHTTP is the preferred processor to use over the deprecated PostHTTP. > However, PostHTTP outperforms InvokeHTTP (at least in POST mode). A template > and a JSON file have been attached to this ticket for benchmarking the two > processors. Using this flow, PostHTTP was observed to have a throughput of > approximately 5 times greater than InvokeHTTP. > In addition, it was noted that InvokeHTTP had approximately 5 times as many > tasks and 5 times the task duration for a given 5 minute stats window. And, > the statistics of Bytes Read and Bytes Transferred remain at zero for > InvokeHTTP; this area accurate statistics also needs to be addressed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-8968) Improve throughput performance for InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-8968: Attachment: ListenHTTP-BytesOut.PNG ListenHTTP-FFOut.PNG > Improve throughput performance for InvokeHTTP > - > > Key: NIFI-8968 > URL: https://issues.apache.org/jira/browse/NIFI-8968 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Mark Bean >Priority: Major > Attachments: ListenHTTP-BytesOut.PNG, ListenHTTP-FFOut.PNG, > PostHTTP_vs_InvokeHTTP.json, PostHTTP_vs_InvokeHTTP.xml > > > InvokeHTTP is the preferred processor to use over the deprecated PostHTTP. > However, PostHTTP outperforms InvokeHTTP (at least in POST mode). A template > and a JSON file have been attached to this ticket for benchmarking the two > processors. Using this flow, PostHTTP was observed to have a throughput of > approximately 5 times greater than InvokeHTTP. > In addition, it was noted that InvokeHTTP had approximately 5 times as many > tasks and 5 times the task duration for a given 5 minute stats window. And, > the statistics of Bytes Read and Bytes Transferred remain at zero for > InvokeHTTP; this area accurate statistics also needs to be addressed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-11669) Allow expired entries in distributed cache to be pruned
[ https://issues.apache.org/jira/browse/NIFI-11669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean resolved NIFI-11669. -- Resolution: Won't Fix > Allow expired entries in distributed cache to be pruned > --- > > Key: NIFI-11669 > URL: https://issues.apache.org/jira/browse/NIFI-11669 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.21.0 >Reporter: Mark Bean >Priority: Major > > DetectDuplicate processor adds entries to a DistributedMapCacheClient > service. The processor also has an Age Off Duration property. The cached > value is removed from the cache only if a subsequent duplicate is detected > and the (optional) Age Off Duration has expired. The result is that entries > which are beyond their age off duration remain in the cache needlessly and > continue to consume memory. > There should be a proactive pruning process to eliminate the expired entries. > Two thoughts come to mind: using a DistributedMapCache implementation which > expires entries. This is the most flexible as other users of the cache would > benefit as well. Alternatively, the DetectDuplicate processor could > periodically prune the cache. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12604) Add support to empty queues
[ https://issues.apache.org/jira/browse/NIFI-12604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807367#comment-17807367 ] Mark Bean commented on NIFI-12604: -- Thanks [~joewitt] , [~mcgilman] . Makes more sense now. > Add support to empty queues > --- > > Key: NIFI-12604 > URL: https://issues.apache.org/jira/browse/NIFI-12604 > 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 > > Introduce actions for emptying a queue or all queues within a Process Group. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12604) Add support to empty queues
[ https://issues.apache.org/jira/browse/NIFI-12604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807348#comment-17807348 ] Mark Bean commented on NIFI-12604: -- [~mcgilman] Can you explain what this issue is adding? There already exists the ability empty queues at a Process Group level. Thanks. > Add support to empty queues > --- > > Key: NIFI-12604 > URL: https://issues.apache.org/jira/browse/NIFI-12604 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Introduce actions for emptying a queue or all queues within a Process Group. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804369#comment-17804369 ] Mark Bean commented on NIFI-12555: -- Changing the order worked; the behavior is as expected now. The use-case was a new property (several properties, actually) were added to a custom controller service. The new properties replaced the old ones. In order to allow for consistency with previous releases, I preferred to have the old properties listed first. > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > Attachments: TestCustomProcessor.java > > > Consider PROPERTY_1 with: > .dependsOn(PROPERTY_2, "foo") > > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > -It is possible this is related to changes introduced in NIFI-11593. Note > that the above behavior occurs even when PROPERTY_2 has specific allowed > values.- > The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of > 1.22.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803616#comment-17803616 ] Mark Bean commented on NIFI-12555: -- I attached code for a sample custom processor which shows this behavior. > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > Attachments: TestCustomProcessor.java > > > Consider PROPERTY_1 with: > ` > .dependsOn(PROPERTY_2, "foo") > ` > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > -It is possible this is related to changes introduced in NIFI-11593. Note > that the above behavior occurs even when PROPERTY_2 has specific allowed > values.- > The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of > 1.22.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12555: - Description: Consider PROPERTY_1 with: .dependsOn(PROPERTY_2, "foo") In the UI, when Property 2 is set to a value of "bar", Property 1 should not be displayed. However, when the configuration is first opened, Property 1 is displayed. The UI correctly updates only after re-selecting "bar" for Property 2 - or even just opening its value and choosing "Cancel". In other words, after taking any action to change any property, then Property 1 is correctly removed from the UI. This appears to be a problem only for the initial display of component properties, and not when they are refreshed and/or dependency rules are evaluated. -It is possible this is related to changes introduced in NIFI-11593. Note that the above behavior occurs even when PROPERTY_2 has specific allowed values.- The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of 1.22.0. was: Consider PROPERTY_1 with: ` .dependsOn(PROPERTY_2, "foo") ` In the UI, when Property 2 is set to a value of "bar", Property 1 should not be displayed. However, when the configuration is first opened, Property 1 is displayed. The UI correctly updates only after re-selecting "bar" for Property 2 - or even just opening its value and choosing "Cancel". In other words, after taking any action to change any property, then Property 1 is correctly removed from the UI. This appears to be a problem only for the initial display of component properties, and not when they are refreshed and/or dependency rules are evaluated. -It is possible this is related to changes introduced in NIFI-11593. Note that the above behavior occurs even when PROPERTY_2 has specific allowed values.- The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of 1.22.0. > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > Attachments: TestCustomProcessor.java > > > Consider PROPERTY_1 with: > .dependsOn(PROPERTY_2, "foo") > > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > -It is possible this is related to changes introduced in NIFI-11593. Note > that the above behavior occurs even when PROPERTY_2 has specific allowed > values.- > The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of > 1.22.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12555: - Attachment: TestCustomProcessor.java > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > Attachments: TestCustomProcessor.java > > > Consider PROPERTY_1 with: > ` > .dependsOn(PROPERTY_2, "foo") > ` > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > -It is possible this is related to changes introduced in NIFI-11593. Note > that the above behavior occurs even when PROPERTY_2 has specific allowed > values.- > The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of > 1.22.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12555: - Description: Consider PROPERTY_1 with: ` .dependsOn(PROPERTY_2, "foo") ` In the UI, when Property 2 is set to a value of "bar", Property 1 should not be displayed. However, when the configuration is first opened, Property 1 is displayed. The UI correctly updates only after re-selecting "bar" for Property 2 - or even just opening its value and choosing "Cancel". In other words, after taking any action to change any property, then Property 1 is correctly removed from the UI. This appears to be a problem only for the initial display of component properties, and not when they are refreshed and/or dependency rules are evaluated. -It is possible this is related to changes introduced in NIFI-11593. Note that the above behavior occurs even when PROPERTY_2 has specific allowed values.- The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of 1.22.0. was: Consider PROPERTY_1 with: ` .dependsOn(PROPERTY_2, "foo") ` In the UI, when Property 2 is set to a value of "bar", Property 1 should not be displayed. However, when the configuration is first opened, Property 1 is displayed. The UI correctly updates only after re-selecting "bar" for Property 2 - or even just opening its value and choosing "Cancel". In other words, after taking any action to change any property, then Property 1 is correctly removed from the UI. This appears to be a problem only for the initial display of component properties, and not when they are refreshed and/or dependency rules are evaluated. It is possible this is related to changes introduced in [NIFI-11593|https://issues.apache.org/jira/browse/NIFI-11593]. Note that the above behavior occurs even when PROPERTY_2 has specific allowed values. > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > > Consider PROPERTY_1 with: > ` > .dependsOn(PROPERTY_2, "foo") > ` > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > -It is possible this is related to changes introduced in NIFI-11593. Note > that the above behavior occurs even when PROPERTY_2 has specific allowed > values.- > The same behavior is seen in 1.21.0, and NIFI-11593 has a fix version of > 1.22.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12555: - Component/s: Core UI > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > > Consider PROPERTY_1 with: > ` > .dependsOn(PROPERTY_2, "foo") > ` > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > It is possible this is related to changes introduced in > [NIFI-11593|https://issues.apache.org/jira/browse/NIFI-11593]. Note that the > above behavior occurs even when PROPERTY_2 has specific allowed values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
[ https://issues.apache.org/jira/browse/NIFI-12555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12555: - Affects Version/s: 1.24.0 > UI - Property with .dependsOn() incorrectly being displayed > --- > > Key: NIFI-12555 > URL: https://issues.apache.org/jira/browse/NIFI-12555 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.24.0 >Reporter: Mark Bean >Priority: Major > > Consider PROPERTY_1 with: > ` > .dependsOn(PROPERTY_2, "foo") > ` > In the UI, when Property 2 is set to a value of "bar", Property 1 should not > be displayed. However, when the configuration is first opened, Property 1 is > displayed. The UI correctly updates only after re-selecting "bar" for > Property 2 - or even just opening its value and choosing "Cancel". In other > words, after taking any action to change any property, then Property 1 is > correctly removed from the UI. > This appears to be a problem only for the initial display of component > properties, and not when they are refreshed and/or dependency rules are > evaluated. > It is possible this is related to changes introduced in > [NIFI-11593|https://issues.apache.org/jira/browse/NIFI-11593]. Note that the > above behavior occurs even when PROPERTY_2 has specific allowed values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12555) UI - Property with .dependsOn() incorrectly being displayed
Mark Bean created NIFI-12555: Summary: UI - Property with .dependsOn() incorrectly being displayed Key: NIFI-12555 URL: https://issues.apache.org/jira/browse/NIFI-12555 Project: Apache NiFi Issue Type: Bug Reporter: Mark Bean Consider PROPERTY_1 with: ` .dependsOn(PROPERTY_2, "foo") ` In the UI, when Property 2 is set to a value of "bar", Property 1 should not be displayed. However, when the configuration is first opened, Property 1 is displayed. The UI correctly updates only after re-selecting "bar" for Property 2 - or even just opening its value and choosing "Cancel". In other words, after taking any action to change any property, then Property 1 is correctly removed from the UI. This appears to be a problem only for the initial display of component properties, and not when they are refreshed and/or dependency rules are evaluated. It is possible this is related to changes introduced in [NIFI-11593|https://issues.apache.org/jira/browse/NIFI-11593]. Note that the above behavior occurs even when PROPERTY_2 has specific allowed values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12285) Allow wget location for py4j to be configurable
[ https://issues.apache.org/jira/browse/NIFI-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-12285: Assignee: Mark Bean > Allow wget location for py4j to be configurable > --- > > Key: NIFI-12285 > URL: https://issues.apache.org/jira/browse/NIFI-12285 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > The nifi-python-framework pom.xml uses the download-maven-plugin to obtain > the py4j package via wget. The URL for this download location should be > configurable rather than hardcoded in order to support builds performed on > isolated networks. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12283) Re-instate the no-swagger-ui profile
[ https://issues.apache.org/jira/browse/NIFI-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-12283: - Status: Patch Available (was: In Progress) > Re-instate the no-swagger-ui profile > > > Key: NIFI-12283 > URL: https://issues.apache.org/jira/browse/NIFI-12283 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0 > Environment: building NiFi on an isolated or offline network >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There was a profile in the nifi-registry-web-api, no-swagger-ui. This profile > suppressed attempting a `wget` operation to get the swagger-ui component > needed to create the OpenAPI (aka Swagger) presentation of the API. This > operation is not possible when developing offline or in an isolated network > not connected to the Internet. > The profile was removed as part of NIFI-11165. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12285) Allow wget location for py4j to be configurable
Mark Bean created NIFI-12285: Summary: Allow wget location for py4j to be configurable Key: NIFI-12285 URL: https://issues.apache.org/jira/browse/NIFI-12285 Project: Apache NiFi Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Mark Bean The nifi-python-framework pom.xml uses the download-maven-plugin to obtain the py4j package via wget. The URL for this download location should be configurable rather than hardcoded in order to support builds performed on isolated networks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12283) Re-instate the no-swagger-ui profile
[ https://issues.apache.org/jira/browse/NIFI-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-12283: Assignee: Mark Bean > Re-instate the no-swagger-ui profile > > > Key: NIFI-12283 > URL: https://issues.apache.org/jira/browse/NIFI-12283 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0 > Environment: building NiFi on an isolated or offline network >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > There was a profile in the nifi-registry-web-api, no-swagger-ui. This profile > suppressed attempting a `wget` operation to get the swagger-ui component > needed to create the OpenAPI (aka Swagger) presentation of the API. This > operation is not possible when developing offline or in an isolated network > not connected to the Internet. > The profile was removed as part of NIFI-11165. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12283) Re-instate the no-swagger-ui profile
Mark Bean created NIFI-12283: Summary: Re-instate the no-swagger-ui profile Key: NIFI-12283 URL: https://issues.apache.org/jira/browse/NIFI-12283 Project: Apache NiFi Issue Type: Improvement Affects Versions: 2.0.0 Environment: building NiFi on an isolated or offline network Reporter: Mark Bean There was a profile in the nifi-registry-web-api, no-swagger-ui. This profile suppressed attempting a `wget` operation to get the swagger-ui component needed to create the OpenAPI (aka Swagger) presentation of the API. This operation is not possible when developing offline or in an isolated network not connected to the Internet. The profile was removed as part of NIFI-11165. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10904) Changing Font Color for Dropdown Menu When Selecting Controller Services
[ https://issues.apache.org/jira/browse/NIFI-10904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758634#comment-17758634 ] Mark Bean commented on NIFI-10904: -- Taking a look at the PR, I generated a screenshot of the new black text which is no longer grayed out. See attached image. > Changing Font Color for Dropdown Menu When Selecting Controller Services > > > Key: NIFI-10904 > URL: https://issues.apache.org/jira/browse/NIFI-10904 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Anson Yu >Assignee: Reynaldo Rea >Priority: Trivial > Attachments: GrayOut.PNG, ProposedBlackText.PNG > > Time Spent: 0.5h > Remaining Estimate: 0h > > When I was adding a controller service to a processor (such as > ConvertRecords) via the Properties tab in it's configurations, I noticed the > color of the base options in the dropdown containing "Reference parameter..." > & "Create new service..." used a grey color that gave the impression of it > being unavailable on first glance, even though were selectable options. I > think it would be better if the default color was something else. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10904) Changing Font Color for Dropdown Menu When Selecting Controller Services
[ https://issues.apache.org/jira/browse/NIFI-10904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-10904: - Attachment: ProposedBlackText.PNG > Changing Font Color for Dropdown Menu When Selecting Controller Services > > > Key: NIFI-10904 > URL: https://issues.apache.org/jira/browse/NIFI-10904 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Anson Yu >Assignee: Reynaldo Rea >Priority: Trivial > Attachments: GrayOut.PNG, ProposedBlackText.PNG > > Time Spent: 0.5h > Remaining Estimate: 0h > > When I was adding a controller service to a processor (such as > ConvertRecords) via the Properties tab in it's configurations, I noticed the > color of the base options in the dropdown containing "Reference parameter..." > & "Create new service..." used a grey color that gave the impression of it > being unavailable on first glance, even though were selectable options. I > think it would be better if the default color was something else. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11934) InvokeHTTP does not send filename attribute
[ https://issues.apache.org/jira/browse/NIFI-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11934: - Status: Patch Available (was: In Progress) > InvokeHTTP does not send filename attribute > --- > > Key: NIFI-11934 > URL: https://issues.apache.org/jira/browse/NIFI-11934 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.23.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The InvokeHTTP processor can be configured to send FlowFile attributes when > using the POST HTTP method. Certain attributes are excluded from being sent. > These include some core attributes: UUID, FILENAME and PATH. It makes sense > to exclude UUID and PATH as these will be created/assigned when the FlowFile > is received by a ListenHTTP processor. However, filename should be allowed to > remain as the original filename. > Not only is does this make good sense from a flow perspective, but it is also > consistent with the behavior of the now-deprecated PostHTTP processor. This > functionality must be maintained or dataflows will break when PostHTTP is no > longer available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11934) InvokeHTTP does not send filename attribute
Mark Bean created NIFI-11934: Summary: InvokeHTTP does not send filename attribute Key: NIFI-11934 URL: https://issues.apache.org/jira/browse/NIFI-11934 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 1.23.0 Reporter: Mark Bean The InvokeHTTP processor can be configured to send FlowFile attributes when using the POST HTTP method. Certain attributes are excluded from being sent. These include some core attributes: UUID, FILENAME and PATH. It makes sense to exclude UUID and PATH as these will be created/assigned when the FlowFile is received by a ListenHTTP processor. However, filename should be allowed to remain as the original filename. Not only is does this make good sense from a flow perspective, but it is also consistent with the behavior of the now-deprecated PostHTTP processor. This functionality must be maintained or dataflows will break when PostHTTP is no longer available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-11934) InvokeHTTP does not send filename attribute
[ https://issues.apache.org/jira/browse/NIFI-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-11934: Assignee: Mark Bean > InvokeHTTP does not send filename attribute > --- > > Key: NIFI-11934 > URL: https://issues.apache.org/jira/browse/NIFI-11934 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.23.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > The InvokeHTTP processor can be configured to send FlowFile attributes when > using the POST HTTP method. Certain attributes are excluded from being sent. > These include some core attributes: UUID, FILENAME and PATH. It makes sense > to exclude UUID and PATH as these will be created/assigned when the FlowFile > is received by a ListenHTTP processor. However, filename should be allowed to > remain as the original filename. > Not only is does this make good sense from a flow perspective, but it is also > consistent with the behavior of the now-deprecated PostHTTP processor. This > functionality must be maintained or dataflows will break when PostHTTP is no > longer available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11914) Allow expression language support in SegmentSize property of SegmentContent
[ https://issues.apache.org/jira/browse/NIFI-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11914: - Status: Patch Available (was: In Progress) > Allow expression language support in SegmentSize property of SegmentContent > --- > > Key: NIFI-11914 > URL: https://issues.apache.org/jira/browse/NIFI-11914 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.23.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The Segment Size property of Segment Content processor should allow support > for Expression Language. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11914) Allow expression language support in SegmentSize property of SegmentContent
Mark Bean created NIFI-11914: Summary: Allow expression language support in SegmentSize property of SegmentContent Key: NIFI-11914 URL: https://issues.apache.org/jira/browse/NIFI-11914 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 1.23.0 Reporter: Mark Bean Assignee: Mark Bean The Segment Size property of Segment Content processor should allow support for Expression Language. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11877) Add a comments field for UpdateAttribute Rules
[ https://issues.apache.org/jira/browse/NIFI-11877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11877: - Status: Patch Available (was: In Progress) > Add a comments field for UpdateAttribute Rules > -- > > Key: NIFI-11877 > URL: https://issues.apache.org/jira/browse/NIFI-11877 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It would be useful to have a Comments field dedicated to each Rule in the > Advanced UI of UpdateAttribute. This provides a better location to provide > comments as they apply to a particular rule. The only alternative is to > document Rules in the Comments tab of the processor. This is too far removed > from the Rule to be easy to associate the comment with the Rule - and is > highly susceptible to the comment becoming stale relative to rule changes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11877) Add a comments field for UpdateAttribute Rules
Mark Bean created NIFI-11877: Summary: Add a comments field for UpdateAttribute Rules Key: NIFI-11877 URL: https://issues.apache.org/jira/browse/NIFI-11877 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Mark Bean It would be useful to have a Comments field dedicated to each Rule in the Advanced UI of UpdateAttribute. This provides a better location to provide comments as they apply to a particular rule. The only alternative is to document Rules in the Comments tab of the processor. This is too far removed from the Rule to be easy to associate the comment with the Rule - and is highly susceptible to the comment becoming stale relative to rule changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-11877) Add a comments field for UpdateAttribute Rules
[ https://issues.apache.org/jira/browse/NIFI-11877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-11877: Assignee: Mark Bean > Add a comments field for UpdateAttribute Rules > -- > > Key: NIFI-11877 > URL: https://issues.apache.org/jira/browse/NIFI-11877 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > It would be useful to have a Comments field dedicated to each Rule in the > Advanced UI of UpdateAttribute. This provides a better location to provide > comments as they apply to a particular rule. The only alternative is to > document Rules in the Comments tab of the processor. This is too far removed > from the Rule to be easy to associate the comment with the Rule - and is > highly susceptible to the comment becoming stale relative to rule changes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11874) Reorganize UI presentation of Process Group configuration
[ https://issues.apache.org/jira/browse/NIFI-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11874: - Status: Patch Available (was: In Progress) > Reorganize UI presentation of Process Group configuration > - > > Key: NIFI-11874 > URL: https://issues.apache.org/jira/browse/NIFI-11874 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.23.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When configuring a Process Group, the configuration options scroll off the > screen. Of course, this depends on the user's display resolution. However, on > many common display configurations, this results in the options scrolling off > a single screen view. > Recommend creating two columns of configuration settings so they are more > likely to fit on a single dialog window without needing to scroll - in > particular the "Apply" button. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-11874) Reorganize UI presentation of Process Group configuration
[ https://issues.apache.org/jira/browse/NIFI-11874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-11874: Assignee: Mark Bean > Reorganize UI presentation of Process Group configuration > - > > Key: NIFI-11874 > URL: https://issues.apache.org/jira/browse/NIFI-11874 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.23.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When configuring a Process Group, the configuration options scroll off the > screen. Of course, this depends on the user's display resolution. However, on > many common display configurations, this results in the options scrolling off > a single screen view. > Recommend creating two columns of configuration settings so they are more > likely to fit on a single dialog window without needing to scroll - in > particular the "Apply" button. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11874) Reorganize UI presentation of Process Group configuration
Mark Bean created NIFI-11874: Summary: Reorganize UI presentation of Process Group configuration Key: NIFI-11874 URL: https://issues.apache.org/jira/browse/NIFI-11874 Project: Apache NiFi Issue Type: Improvement Components: Core UI Affects Versions: 1.23.0 Reporter: Mark Bean When configuring a Process Group, the configuration options scroll off the screen. Of course, this depends on the user's display resolution. However, on many common display configurations, this results in the options scrolling off a single screen view. Recommend creating two columns of configuration settings so they are more likely to fit on a single dialog window without needing to scroll - in particular the "Apply" button. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11845) Upgrade NiFi Registry from 1.22.0 to 1.23.0 fails with H2 database migration failure
[ https://issues.apache.org/jira/browse/NIFI-11845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745683#comment-17745683 ] Mark Bean commented on NIFI-11845: -- Included complete stack trace in attachement, nifi-registry-app.log > Upgrade NiFi Registry from 1.22.0 to 1.23.0 fails with H2 database migration > failure > > > Key: NIFI-11845 > URL: https://issues.apache.org/jira/browse/NIFI-11845 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mark Bean >Priority: Major > Fix For: 1.23.0 > > Attachments: nifi-registry-app.log > > > Upgrading NiFi Registry 1.22.0 to 1.23.0 failed during RC evaluation. The H2 > database was not successfully migrated. > Procedure for reproducing: Configure and start Registry 1.22.0. Add at least > one versioned flow to the Registry. > Shutdown Registry 1.22.0 > Install Registry 1.23.0. Configuration files have remained the same in 1.23.0 > (no new or removed properties) so it is safe to copy conf/ directory from > 1.22.0 into 1.23.0 installation. > Copy database/ and flow_storage/ directories from 1.22.0 to 1.23.0 (or > reference appropriately in 1.23.0 config files. > Attempt to start Registry 1.23.0. > Stack trace is deep. It begins with: > 023-07-21 13:12:31,815 ERROR [main] o.springframework.boot.SpringApplication > Application run failed > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'niFiRegistryApiApplication': Unsatisfied dependency > expressed through field 'eventService'; nested exception is > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'eventService' defined in URL > [jar:file:/opt/apache-nifi/nifi-registry-1.23.0/work/jetty/nifi-registry-web-api-1.23.0.war/webapp/WEB-INF/lib/nifi-registry-framework-1.23.0.jar!/org/apache/nifi/registry/event/EventService.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'standardProviderFactory' defined in URL > [jar:file:/opt/apache-nifi/nifi-registry-1.23.0/work/jetty/nifi-registry-web-api-1.23.0.war/webapp/WEB-INF/lib/nifi-registry-framework-1.23.0.jar!/org/apache/nifi/registry/provider/StandardProviderFactory.class]: > Unsatisfied dependency expressed through constructor parameter 2; nested > exception is org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'getDataSource' defined in class path resource > [org/apache/nifi/registry/db/DataSourceFactory.class]: Bean instantiation via > factory method failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [javax.sql.DataSource]: Factory method 'getDataSource' threw exception; > nested exception is java.lang.RuntimeException: H2 database migration failed > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:662) > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:642) > at > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119) > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:399) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:619) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) > at > org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:955) > at >
[jira] [Updated] (NIFI-11845) Upgrade NiFi Registry from 1.22.0 to 1.23.0 fails with H2 database migration failure
[ https://issues.apache.org/jira/browse/NIFI-11845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11845: - Attachment: nifi-registry-app.log > Upgrade NiFi Registry from 1.22.0 to 1.23.0 fails with H2 database migration > failure > > > Key: NIFI-11845 > URL: https://issues.apache.org/jira/browse/NIFI-11845 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mark Bean >Priority: Major > Fix For: 1.23.0 > > Attachments: nifi-registry-app.log > > > Upgrading NiFi Registry 1.22.0 to 1.23.0 failed during RC evaluation. The H2 > database was not successfully migrated. > Procedure for reproducing: Configure and start Registry 1.22.0. Add at least > one versioned flow to the Registry. > Shutdown Registry 1.22.0 > Install Registry 1.23.0. Configuration files have remained the same in 1.23.0 > (no new or removed properties) so it is safe to copy conf/ directory from > 1.22.0 into 1.23.0 installation. > Copy database/ and flow_storage/ directories from 1.22.0 to 1.23.0 (or > reference appropriately in 1.23.0 config files. > Attempt to start Registry 1.23.0. > Stack trace is deep. It begins with: > 023-07-21 13:12:31,815 ERROR [main] o.springframework.boot.SpringApplication > Application run failed > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'niFiRegistryApiApplication': Unsatisfied dependency > expressed through field 'eventService'; nested exception is > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'eventService' defined in URL > [jar:file:/opt/apache-nifi/nifi-registry-1.23.0/work/jetty/nifi-registry-web-api-1.23.0.war/webapp/WEB-INF/lib/nifi-registry-framework-1.23.0.jar!/org/apache/nifi/registry/event/EventService.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'standardProviderFactory' defined in URL > [jar:file:/opt/apache-nifi/nifi-registry-1.23.0/work/jetty/nifi-registry-web-api-1.23.0.war/webapp/WEB-INF/lib/nifi-registry-framework-1.23.0.jar!/org/apache/nifi/registry/provider/StandardProviderFactory.class]: > Unsatisfied dependency expressed through constructor parameter 2; nested > exception is org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'getDataSource' defined in class path resource > [org/apache/nifi/registry/db/DataSourceFactory.class]: Bean instantiation via > factory method failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [javax.sql.DataSource]: Factory method 'getDataSource' threw exception; > nested exception is java.lang.RuntimeException: H2 database migration failed > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:662) > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:642) > at > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119) > at > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:399) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:619) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) > at > org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:955) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:921) > at >
[jira] [Created] (NIFI-11845) Upgrade NiFi Registry from 1.22.0 to 1.23.0 fails with H2 database migration failure
Mark Bean created NIFI-11845: Summary: Upgrade NiFi Registry from 1.22.0 to 1.23.0 fails with H2 database migration failure Key: NIFI-11845 URL: https://issues.apache.org/jira/browse/NIFI-11845 Project: Apache NiFi Issue Type: Bug Reporter: Mark Bean Fix For: 1.23.0 Upgrading NiFi Registry 1.22.0 to 1.23.0 failed during RC evaluation. The H2 database was not successfully migrated. Procedure for reproducing: Configure and start Registry 1.22.0. Add at least one versioned flow to the Registry. Shutdown Registry 1.22.0 Install Registry 1.23.0. Configuration files have remained the same in 1.23.0 (no new or removed properties) so it is safe to copy conf/ directory from 1.22.0 into 1.23.0 installation. Copy database/ and flow_storage/ directories from 1.22.0 to 1.23.0 (or reference appropriately in 1.23.0 config files. Attempt to start Registry 1.23.0. Stack trace is deep. It begins with: 023-07-21 13:12:31,815 ERROR [main] o.springframework.boot.SpringApplication Application run failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'niFiRegistryApiApplication': Unsatisfied dependency expressed through field 'eventService'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'eventService' defined in URL [jar:file:/opt/apache-nifi/nifi-registry-1.23.0/work/jetty/nifi-registry-web-api-1.23.0.war/webapp/WEB-INF/lib/nifi-registry-framework-1.23.0.jar!/org/apache/nifi/registry/event/EventService.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'standardProviderFactory' defined in URL [jar:file:/opt/apache-nifi/nifi-registry-1.23.0/work/jetty/nifi-registry-web-api-1.23.0.war/webapp/WEB-INF/lib/nifi-registry-framework-1.23.0.jar!/org/apache/nifi/registry/provider/StandardProviderFactory.class]: Unsatisfied dependency expressed through constructor parameter 2; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'getDataSource' defined in class path resource [org/apache/nifi/registry/db/DataSourceFactory.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [javax.sql.DataSource]: Factory method 'getDataSource' threw exception; nested exception is java.lang.RuntimeException: H2 database migration failed at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:662) at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:642) at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119) at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:399) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:619) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:955) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:921) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583) at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:147) at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:731) at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:408) at
[jira] [Commented] (NIFI-8044) Controller services do not refer to any component when they are not associated with a top-level process group
[ https://issues.apache.org/jira/browse/NIFI-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743873#comment-17743873 ] Mark Bean commented on NIFI-8044: - At least as of NiFi 1.21.0 this issue no longer exists. It may have been fixed even earlier, but I confirmed correct expected behavior when running NiFi 1.21.0 connected to a NiFi Registry 1.19.1 > Controller services do not refer to any component when they are not > associated with a top-level process group > - > > Key: NIFI-8044 > URL: https://issues.apache.org/jira/browse/NIFI-8044 > Project: Apache NiFi > Issue Type: Bug > Components: Flow Versioning >Affects Versions: 1.11.4 > Environment: Any environment >Reporter: Samuele Lenticchia >Priority: Major > > After the import of a versioned flow, the controller services configuration > page (SETTINGS) says that it does not refer to any component if the > controller services are defined in a scope higher than the first level. > *Scenario* > I have a process group (I will name it B) nested in a process group (that I > will name A) that is at top-level. So they will be: > NiFi Flow » A » B > In process group B, it is defined at least one controller service (scope B) > which refers to at least one component (Component_B) in this process group. > Process group A is versioned with the name FlowA. > *Issue* > When I import FlowA from the registry, the service at scope B says "No > referencing components" on the settings page. Also, if I try to enable it, > the same text "No referencing components" is shown under the "Referencing > Components" label. > *Expected behavior* > When I import FlowA, the service at scope B should list the processors > and/or controller services that refer to this service. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11669) Allow expired entries in distributed cache to be pruned
Mark Bean created NIFI-11669: Summary: Allow expired entries in distributed cache to be pruned Key: NIFI-11669 URL: https://issues.apache.org/jira/browse/NIFI-11669 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 1.21.0 Reporter: Mark Bean DetectDuplicate processor adds entries to a DistributedMapCacheClient service. The processor also has an Age Off Duration property. The cached value is removed from the cache only if a subsequent duplicate is detected and the (optional) Age Off Duration has expired. The result is that entries which are beyond their age off duration remain in the cache needlessly and continue to consume memory. There should be a proactive pruning process to eliminate the expired entries. Two thoughts come to mind: using a DistributedMapCache implementation which expires entries. This is the most flexible as other users of the cache would benefit as well. Alternatively, the DetectDuplicate processor could periodically prune the cache. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11309) Add connection details for a cluster to the context menu of a connection
Mark Bean created NIFI-11309: Summary: Add connection details for a cluster to the context menu of a connection Key: NIFI-11309 URL: https://issues.apache.org/jira/browse/NIFI-11309 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.19.1 Reporter: Mark Bean In a cluster, the node-specific details of a connection can be observed by choosing Global Menu > Summary > Connections > View Connection Details (on the right-hand side). This information should be made available directly from a given connection on the graph. Add a new item to the context menu available when right-clicking on a connections. Aside: there are two separate "View Connection Details" options on the Global Menu > Summary > Connections line items. This is confusing and one or both should be renamed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11308) Create an Expression Language function to return NiFi version
Mark Bean created NIFI-11308: Summary: Create an Expression Language function to return NiFi version Key: NIFI-11308 URL: https://issues.apache.org/jira/browse/NIFI-11308 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.19.1 Reporter: Mark Bean Create a new Expression Language function which returns the version of NiFi being run. This allows for programmatic access to version information within the flow. Suggest the function be subjectless as it applies to the instance making the EL call and be called "nifiVersion()" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11306) Add Done button to Advanced UI of UpdateAttribute processor
Mark Bean created NIFI-11306: Summary: Add Done button to Advanced UI of UpdateAttribute processor Key: NIFI-11306 URL: https://issues.apache.org/jira/browse/NIFI-11306 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.19.1 Reporter: Mark Bean Once entering the Advanced UI of an UpdateAttribute processor, the only way to exit the dialog is to close it completely returning the user to the main graph. Recommend adding a "Done" button so that the UI returns to the Configure dialog of the UpdateAttribute processor. This is desirable for several reasons not the least of which is to quickly return to the Properties tab to enter additional properties and/or default values for attributes not matching any advanced rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11304) Add Bulletin indicator for Processors on the Summary page
[ https://issues.apache.org/jira/browse/NIFI-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11304: - Description: It would be useful to have a Bulletin indicator column on the Processors, Remote Process Group and Process Group tabs of the Summary page. This would allow the user to sort on this column to quickly find and navigate to components which have active bulletins. The additional space requirements are minimal, and some current columns could be reduced in size to accommodate the additional column, e.g. Run Status. was: It would be useful to have a Bulletin indicator column on the Processors tab of the Summary page. This would allow the user to sort on this column to quickly find all processors which have active bulletins. The additional space requirements are minimal, and some current columns could be reduced in size to accommodate the additional column, e.g. Run Status. > Add Bulletin indicator for Processors on the Summary page > - > > Key: NIFI-11304 > URL: https://issues.apache.org/jira/browse/NIFI-11304 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.1 >Reporter: Mark Bean >Priority: Major > > It would be useful to have a Bulletin indicator column on the Processors, > Remote Process Group and Process Group tabs of the Summary page. This would > allow the user to sort on this column to quickly find and navigate to > components which have active bulletins. The additional space requirements are > minimal, and some current columns could be reduced in size to accommodate the > additional column, e.g. Run Status. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11304) Add Bulletin indicator for Processors on the Summary page
Mark Bean created NIFI-11304: Summary: Add Bulletin indicator for Processors on the Summary page Key: NIFI-11304 URL: https://issues.apache.org/jira/browse/NIFI-11304 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.19.1 Reporter: Mark Bean It would be useful to have a Bulletin indicator column on the Processors tab of the Summary page. This would allow the user to sort on this column to quickly find all processors which have active bulletins. The additional space requirements are minimal, and some current columns could be reduced in size to accommodate the additional column, e.g. Run Status. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11303) Create direct go-to option from Provenance lineage
Mark Bean created NIFI-11303: Summary: Create direct go-to option from Provenance lineage Key: NIFI-11303 URL: https://issues.apache.org/jira/browse/NIFI-11303 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.19.1 Reporter: Mark Bean The process to navigate from a Provenance event in the lineage diagram to the component which generated the event is a little cumbersome. It requires right-clicking on the event, choose 'View details', locating the Component Id, returning to the main graph, entering the Component Id in the Search bar and finally selecting the component. It would be useful and more direct to have a "go to" link option available on the context menu when right-clicking on the event. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-11302) Fix version info in About dialog for NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-11302: Assignee: Mark Bean > Fix version info in About dialog for NiFi Registry > -- > > Key: NIFI-11302 > URL: https://issues.apache.org/jira/browse/NIFI-11302 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The About dialog for NiFi Registry does not display the version information > when using Java 11; it only works for Java 8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11302) Fix version info in About dialog for NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11302: - Status: Patch Available (was: In Progress) > Fix version info in About dialog for NiFi Registry > -- > > Key: NIFI-11302 > URL: https://issues.apache.org/jira/browse/NIFI-11302 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The About dialog for NiFi Registry does not display the version information > when using Java 11; it only works for Java 8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11302) Fix version info in About dialog for NiFi Registry
Mark Bean created NIFI-11302: Summary: Fix version info in About dialog for NiFi Registry Key: NIFI-11302 URL: https://issues.apache.org/jira/browse/NIFI-11302 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.19.1 Reporter: Mark Bean The About dialog for NiFi Registry does not display the version information when using Java 11; it only works for Java 8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11134) Labels are not tracked by Flow Configuration History
[ https://issues.apache.org/jira/browse/NIFI-11134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11134: - Status: Patch Available (was: In Progress) > Labels are not tracked by Flow Configuration History > > > Key: NIFI-11134 > URL: https://issues.apache.org/jira/browse/NIFI-11134 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a Label is added, modified or deleted, this action is not reflected in > the Flow Configuration History. It should be part of the history so changes > to a label's contents (for example) will be attributed to a specific user. In > cases where the label content has changes, the before and after text should > be captured as Previous Value and Value, respectively. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-11134) Labels are not tracked by Flow Configuration History
[ https://issues.apache.org/jira/browse/NIFI-11134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-11134: Assignee: Mark Bean > Labels are not tracked by Flow Configuration History > > > Key: NIFI-11134 > URL: https://issues.apache.org/jira/browse/NIFI-11134 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > When a Label is added, modified or deleted, this action is not reflected in > the Flow Configuration History. It should be part of the history so changes > to a label's contents (for example) will be attributed to a specific user. In > cases where the label content has changes, the before and after text should > be captured as Previous Value and Value, respectively. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11134) Labels are not tracked by Flow Configuration History
Mark Bean created NIFI-11134: Summary: Labels are not tracked by Flow Configuration History Key: NIFI-11134 URL: https://issues.apache.org/jira/browse/NIFI-11134 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.19.1 Reporter: Mark Bean When a Label is added, modified or deleted, this action is not reflected in the Flow Configuration History. It should be part of the history so changes to a label's contents (for example) will be attributed to a specific user. In cases where the label content has changes, the before and after text should be captured as Previous Value and Value, respectively. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10958) Documentation is not generated for some components in Java 17
[ https://issues.apache.org/jira/browse/NIFI-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644391#comment-17644391 ] Mark Bean commented on NIFI-10958: -- The lack of documentation appears to apply to the "General" docs as well (User Guide, Admin Guide, Expression Language, etc.) > Documentation is not generated for some components in Java 17 > - > > Key: NIFI-10958 > URL: https://issues.apache.org/jira/browse/NIFI-10958 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation Website >Affects Versions: 1.19.0 > Environment: Java 17 >Reporter: Mark Bean >Priority: Major > > When building with Java 17, the documentation for some components is not > generated properly. Affected components are identified by the following > warning messages which appear in nifi-app.log when docs are first created: > > 2022-12-07 09:13:17,236 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.processors.script.ExecuteScript] > 2022-12-07 09:13:17,610 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.processors.script.InvokeScriptedProcessor] > 2022-12-07 09:13:18,071 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.record.sink.script.ScriptedRecordSink] > 2022-12-07 09:13:18,074 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.rules.engine.script.ScriptedRulesEngine] > 2022-12-07 09:13:18,078 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.record.script.ScriptedReader] > 2022-12-07 09:13:18,082 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.rules.handlers.script.ScriptedActionHandler] > 2022-12-07 09:13:18,088 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.lookup.script.SimpleScriptedLookupService] > 2022-12-07 09:13:18,094 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.lookup.script.ScriptedLookupService] > 2022-12-07 09:13:18,098 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.record.script.ScriptedRecordSetWriter] > 2022-12-07 09:13:18,262 WARN [main] o.apache.nifi.documentation.DocGenerator > Documentation generation failed: Component Class [class > org.apache.nifi.reporting.script.ScriptedReportingTask] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10958) Documentation is not generated for some components in Java 17
Mark Bean created NIFI-10958: Summary: Documentation is not generated for some components in Java 17 Key: NIFI-10958 URL: https://issues.apache.org/jira/browse/NIFI-10958 Project: Apache NiFi Issue Type: Bug Components: Documentation Website Affects Versions: 1.19.0 Environment: Java 17 Reporter: Mark Bean When building with Java 17, the documentation for some components is not generated properly. Affected components are identified by the following warning messages which appear in nifi-app.log when docs are first created: 2022-12-07 09:13:17,236 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.processors.script.ExecuteScript] 2022-12-07 09:13:17,610 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.processors.script.InvokeScriptedProcessor] 2022-12-07 09:13:18,071 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.record.sink.script.ScriptedRecordSink] 2022-12-07 09:13:18,074 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.rules.engine.script.ScriptedRulesEngine] 2022-12-07 09:13:18,078 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.record.script.ScriptedReader] 2022-12-07 09:13:18,082 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.rules.handlers.script.ScriptedActionHandler] 2022-12-07 09:13:18,088 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.lookup.script.SimpleScriptedLookupService] 2022-12-07 09:13:18,094 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.lookup.script.ScriptedLookupService] 2022-12-07 09:13:18,098 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.record.script.ScriptedRecordSetWriter] 2022-12-07 09:13:18,262 WARN [main] o.apache.nifi.documentation.DocGenerator Documentation generation failed: Component Class [class org.apache.nifi.reporting.script.ScriptedReportingTask] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10852) compress-commons does not handle large groupid values
[
https://issues.apache.org/jira/browse/NIFI-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Bean updated NIFI-10852:
-
Status: Patch Available (was: In Progress)
> compress-commons does not handle large groupid values
> -
>
> Key: NIFI-10852
> URL: https://issues.apache.org/jira/browse/NIFI-10852
> Project: Apache NiFi
> Issue Type: Bug
> Components: C2
>Affects Versions: 1.18.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a limitation in the org.apache.commons:commons-compress library
> which does not allow groupid values larger than 2097151 by default. Some
> users who have a large groupid value may experience problems building Apache
> NiFi, particularly the c2 modules.
> While this isn't the cause of the problem, the exhibited unit test failure is:
> {{[ERROR] Tests run: 12, Failures: 4, Errors: 0, Skipped: 0, Time elapsed:
> 0.317 s <<< FAILURE! - in
> org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest}}
> {{[ERROR]
> org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest.testContentIsFilteredOut(String,
> String, String, String)[1] Time elapsed: 0.096 s <<< FAILURE!}}
> {{Wanted but not invoked:}}
> {{c2Client.uploadBundle(}}
> {{ ,}}
> {{ }}
> {{);}}
> {{-> at
> org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest.testContentIsFilteredOut(TransferDebugOperationHandlerTest.java:206)}}
> {{Actually, there were zero interactions with this mock.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (NIFI-10852) compress-commons does not handle large groupid values
[
https://issues.apache.org/jira/browse/NIFI-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Bean reassigned NIFI-10852:
Assignee: Mark Bean
> compress-commons does not handle large groupid values
> -
>
> Key: NIFI-10852
> URL: https://issues.apache.org/jira/browse/NIFI-10852
> Project: Apache NiFi
> Issue Type: Bug
> Components: C2
>Affects Versions: 1.18.0
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a limitation in the org.apache.commons:commons-compress library
> which does not allow groupid values larger than 2097151 by default. Some
> users who have a large groupid value may experience problems building Apache
> NiFi, particularly the c2 modules.
> While this isn't the cause of the problem, the exhibited unit test failure is:
> {{[ERROR] Tests run: 12, Failures: 4, Errors: 0, Skipped: 0, Time elapsed:
> 0.317 s <<< FAILURE! - in
> org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest}}
> {{[ERROR]
> org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest.testContentIsFilteredOut(String,
> String, String, String)[1] Time elapsed: 0.096 s <<< FAILURE!}}
> {{Wanted but not invoked:}}
> {{c2Client.uploadBundle(}}
> {{ ,}}
> {{ }}
> {{);}}
> {{-> at
> org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest.testContentIsFilteredOut(TransferDebugOperationHandlerTest.java:206)}}
> {{Actually, there were zero interactions with this mock.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-10852) compress-commons does not handle large groupid values
Mark Bean created NIFI-10852:
Summary: compress-commons does not handle large groupid values
Key: NIFI-10852
URL: https://issues.apache.org/jira/browse/NIFI-10852
Project: Apache NiFi
Issue Type: Bug
Components: C2
Affects Versions: 1.18.0
Reporter: Mark Bean
There is a limitation in the org.apache.commons:commons-compress library which
does not allow groupid values larger than 2097151 by default. Some users who
have a large groupid value may experience problems building Apache NiFi,
particularly the c2 modules.
While this isn't the cause of the problem, the exhibited unit test failure is:
{{[ERROR] Tests run: 12, Failures: 4, Errors: 0, Skipped: 0, Time elapsed:
0.317 s <<< FAILURE! - in
org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest}}
{{[ERROR]
org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest.testContentIsFilteredOut(String,
String, String, String)[1] Time elapsed: 0.096 s <<< FAILURE!}}
{{Wanted but not invoked:}}
{{c2Client.uploadBundle(}}
{{ ,}}
{{ }}
{{);}}
{{-> at
org.apache.nifi.c2.client.service.operation.TransferDebugOperationHandlerTest.testContentIsFilteredOut(TransferDebugOperationHandlerTest.java:206)}}
{{Actually, there were zero interactions with this mock.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10714) DistributeLoad is invalid when changing Number of Relationships property
[ https://issues.apache.org/jira/browse/NIFI-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean resolved NIFI-10714. -- Resolution: Cannot Reproduce As of version 1.17.0, this cannot be reproduced > DistributeLoad is invalid when changing Number of Relationships property > > > Key: NIFI-10714 > URL: https://issues.apache.org/jira/browse/NIFI-10714 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.16.3 >Reporter: Mark Bean >Priority: Major > > When the "Number of Relationship" property is changed on DistributeLoad and > an appropriate number of dynamic properties are added/removed to match Number > of Relationships, the processor goes to an invalid state. > For example, processor has 2 relationships initially and is in a valid state. > Change Number of Relationships to 3 and add a dynamic property '3' with value > '5'. Errors include: > 'Property Name' validated against '3' is invalid because Property Name must > be a positive integer between 1 and the number of relationships (inclusive) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10228) FlowParser is using incorrect identifier for process group
[ https://issues.apache.org/jira/browse/NIFI-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-10228: Assignee: Mark Bean > FlowParser is using incorrect identifier for process group > -- > > Key: NIFI-10228 > URL: https://issues.apache.org/jira/browse/NIFI-10228 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.3 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Fix For: 1.19.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When starting NiFi for the first time using the managed-authorizer, NiFi will > put the Initial Admin Identity in certain Access Policies. However, it only > does this for Global Access Policies, and does not add this user to any > Component Access Policies, e.g. 'view/modify the component'. > > This has been frustrating, but as I understand it is unavoidable because the > UUID of the root process group has not yet been created (there is no > flow.xml.gz) at the time the policies are generated. > > However, I found that if a flow.xml.gz existed without a corresponding > authorizations.xml or users.xml, then the startup process would in fact > create the Component Access Policies and add the admin user to them. > > Now, with the introduction of flow.json.gz, the root process group has both > "identifier" and "instanceIdentifier" properties. The Component Access > Policies created on startup as described above reference the "identifier" > UUID, but the UI indicates the "instanceIdentifier" is the proper UUID for > the root process group. Therefore, the Component Access Policies are > ineffective as they reference an incorrect UUID value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10703) Event Driven Thread Count resets on NiFi restart
[ https://issues.apache.org/jira/browse/NIFI-10703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630664#comment-17630664 ] Mark Bean commented on NIFI-10703: -- I'm fairly certain it was left out intentionally because Event Driven is generally a bad idea, and it will likely be removed when advancing to NiFi 2.0. However, I feel that it should still be fully supported until then. If it's a configurable feature, it should continue to function. > Event Driven Thread Count resets on NiFi restart > > > Key: NIFI-10703 > URL: https://issues.apache.org/jira/browse/NIFI-10703 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.18.0 >Reporter: Mark Bean >Assignee: Nathan Gough >Priority: Minor > > The controller setting for Maximum Event Driven Thread Count is reset to "1" > after restarting NiFi. This occurs because this property is not written to > the flow.json.gz file; it is only present in the flow.xml.gz. > Therefore, until this issue is reolved and the property added to the JSON, a > work-around is to remove the flow.json.gz before restarting NiFi. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10714) DistributeLoad is invalid when changing Number of Relationships property
Mark Bean created NIFI-10714: Summary: DistributeLoad is invalid when changing Number of Relationships property Key: NIFI-10714 URL: https://issues.apache.org/jira/browse/NIFI-10714 Project: Apache NiFi Issue Type: Bug Components: Extensions Affects Versions: 1.16.3 Reporter: Mark Bean When the "Number of Relationship" property is changed on DistributeLoad and an appropriate number of dynamic properties are added/removed to match Number of Relationships, the processor goes to an invalid state. For example, processor has 2 relationships initially and is in a valid state. Change Number of Relationships to 3 and add a dynamic property '3' with value '5'. Errors include: 'Property Name' validated against '3' is invalid because Property Name must be a positive integer between 1 and the number of relationships (inclusive) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-4798) UpdateAttribute should allow empty string values without requiring state management
[ https://issues.apache.org/jira/browse/NIFI-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17625154#comment-17625154 ] Mark Bean commented on NIFI-4798: - Update since this ticket has been dormant for so long.. The goal is not simply to remove an attribute. Rather it is to allow an attribute to be created (or modified) such that it's value is an empty string. This ticket is not solely for the removal of an attribute as suggested previously. > UpdateAttribute should allow empty string values without requiring state > management > --- > > Key: NIFI-4798 > URL: https://issues.apache.org/jira/browse/NIFI-4798 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Extensions >Affects Versions: 1.5.0 >Reporter: Mark Bean >Priority: Minor > Labels: easyfix > Time Spent: 0.5h > Remaining Estimate: 0h > > The conditional validation of dynamic properties in UpdateAttribute use the > NON_EMPTY_STRING validator when state management is not enabled. This prevent > the "Set empty string" checkbox option. The introduction of state management > to this processor changed this behavior which previously allowed an empty > string for an attribute value. The validator for the non-stateful case should > be changed to return the original behavior. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10228) FlowParser is using incorrect identifier for process group
[ https://issues.apache.org/jira/browse/NIFI-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17624692#comment-17624692 ] Mark Bean commented on NIFI-10228: -- [~bbende] I submitted a PR for this some time ago. Another user suggested a unit test. However [~markap14] an I agree that a unit test is not necessary. Would you mind looking at the PR and approving if no concerns. [https://github.com/apache/nifi/pull/6217] > FlowParser is using incorrect identifier for process group > -- > > Key: NIFI-10228 > URL: https://issues.apache.org/jira/browse/NIFI-10228 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.3 >Reporter: Mark Bean >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > When starting NiFi for the first time using the managed-authorizer, NiFi will > put the Initial Admin Identity in certain Access Policies. However, it only > does this for Global Access Policies, and does not add this user to any > Component Access Policies, e.g. 'view/modify the component'. > > This has been frustrating, but as I understand it is unavoidable because the > UUID of the root process group has not yet been created (there is no > flow.xml.gz) at the time the policies are generated. > > However, I found that if a flow.xml.gz existed without a corresponding > authorizations.xml or users.xml, then the startup process would in fact > create the Component Access Policies and add the admin user to them. > > Now, with the introduction of flow.json.gz, the root process group has both > "identifier" and "instanceIdentifier" properties. The Component Access > Policies created on startup as described above reference the "identifier" > UUID, but the UI indicates the "instanceIdentifier" is the proper UUID for > the root process group. Therefore, the Component Access Policies are > ineffective as they reference an incorrect UUID value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10703) Event Driven Thread Count resets on NiFi restart
[ https://issues.apache.org/jira/browse/NIFI-10703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-10703: - Summary: Event Driven Thread Count resets on NiFi restart (was: Event Driven ) > Event Driven Thread Count resets on NiFi restart > > > Key: NIFI-10703 > URL: https://issues.apache.org/jira/browse/NIFI-10703 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.18.0 >Reporter: Mark Bean >Priority: Minor > > The controller setting for Maximum Event Driven Thread Count is reset to "1" > after restarting NiFi. This occurs because this property is not written to > the flow.json.gz file; it is only present in the flow.xml.gz. > Therefore, until this issue is reolved and the property added to the JSON, a > work-around is to remove the flow.json.gz before restarting NiFi. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10703) Event Driven
Mark Bean created NIFI-10703: Summary: Event Driven Key: NIFI-10703 URL: https://issues.apache.org/jira/browse/NIFI-10703 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.18.0 Reporter: Mark Bean The controller setting for Maximum Event Driven Thread Count is reset to "1" after restarting NiFi. This occurs because this property is not written to the flow.json.gz file; it is only present in the flow.xml.gz. Therefore, until this issue is reolved and the property added to the JSON, a work-around is to remove the flow.json.gz before restarting NiFi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10243) ControlRate throttle on both flowfile and byte count
[ https://issues.apache.org/jira/browse/NIFI-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-10243: - Status: Patch Available (was: In Progress) > ControlRate throttle on both flowfile and byte count > > > Key: NIFI-10243 > URL: https://issues.apache.org/jira/browse/NIFI-10243 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.16.3 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Request the ability for a ControlRate component to throttle based upon > multiple thresholds. Currently, you can only set the "Rate Control Criteria" > of "data rate", or "flowfile count". Allowing you to set either a "byte" > threshold OR "flowfile count" threshold. > > Requesting the ability to optionally include values for both... so > essentially a throttle would kick in whenever either threshold is met. This > is particularly useful with varying datasets that contain many small objects > within potentially small sized files that might otherwise fly underneath the > threshold that was meant to limit overall file counts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10228) FlowParser is using incorrect identifier for process group
[ https://issues.apache.org/jira/browse/NIFI-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-10228: - Status: Patch Available (was: Open) > FlowParser is using incorrect identifier for process group > -- > > Key: NIFI-10228 > URL: https://issues.apache.org/jira/browse/NIFI-10228 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.3 >Reporter: Mark Bean >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > When starting NiFi for the first time using the managed-authorizer, NiFi will > put the Initial Admin Identity in certain Access Policies. However, it only > does this for Global Access Policies, and does not add this user to any > Component Access Policies, e.g. 'view/modify the component'. > > This has been frustrating, but as I understand it is unavoidable because the > UUID of the root process group has not yet been created (there is no > flow.xml.gz) at the time the policies are generated. > > However, I found that if a flow.xml.gz existed without a corresponding > authorizations.xml or users.xml, then the startup process would in fact > create the Component Access Policies and add the admin user to them. > > Now, with the introduction of flow.json.gz, the root process group has both > "identifier" and "instanceIdentifier" properties. The Component Access > Policies created on startup as described above reference the "identifier" > UUID, but the UI indicates the "instanceIdentifier" is the proper UUID for > the root process group. Therefore, the Component Access Policies are > ineffective as they reference an incorrect UUID value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10243) ControlRate throttle on both flowfile and byte count
[ https://issues.apache.org/jira/browse/NIFI-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-10243: Assignee: Mark Bean > ControlRate throttle on both flowfile and byte count > > > Key: NIFI-10243 > URL: https://issues.apache.org/jira/browse/NIFI-10243 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.16.3 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > > Request the ability for a ControlRate component to throttle based upon > multiple thresholds. Currently, you can only set the "Rate Control Criteria" > of "data rate", or "flowfile count". Allowing you to set either a "byte" > threshold OR "flowfile count" threshold. > > Requesting the ability to optionally include values for both... so > essentially a throttle would kick in whenever either threshold is met. This > is particularly useful with varying datasets that contain many small objects > within potentially small sized files that might otherwise fly underneath the > threshold that was meant to limit overall file counts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10243) ControlRate throttle on both flowfile and byte count
Mark Bean created NIFI-10243: Summary: ControlRate throttle on both flowfile and byte count Key: NIFI-10243 URL: https://issues.apache.org/jira/browse/NIFI-10243 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 1.16.3 Reporter: Mark Bean Request the ability for a ControlRate component to throttle based upon multiple thresholds. Currently, you can only set the "Rate Control Criteria" of "data rate", or "flowfile count". Allowing you to set either a "byte" threshold OR "flowfile count" threshold. Requesting the ability to optionally include values for both... so essentially a throttle would kick in whenever either threshold is met. This is particularly useful with varying datasets that contain many small objects within potentially small sized files that might otherwise fly underneath the threshold that was meant to limit overall file counts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10228) FlowParser is using incorrect identifier for process group
[ https://issues.apache.org/jira/browse/NIFI-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17566447#comment-17566447 ] Mark Bean commented on NIFI-10228: -- Per [~bbende]: I think you are right, it looks like in FlowParser parseJson, the returned FlowInfo comes from this... final VersionedProcessGroup rootGroup = dataflow.getRootGroup(); return new FlowInfo(rootGroup.getIdentifier(), ports); Which I think should be the instance identifier there. > FlowParser is using incorrect identifier for process group > -- > > Key: NIFI-10228 > URL: https://issues.apache.org/jira/browse/NIFI-10228 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.3 >Reporter: Mark Bean >Priority: Major > > When starting NiFi for the first time using the managed-authorizer, NiFi will > put the Initial Admin Identity in certain Access Policies. However, it only > does this for Global Access Policies, and does not add this user to any > Component Access Policies, e.g. 'view/modify the component'. > > This has been frustrating, but as I understand it is unavoidable because the > UUID of the root process group has not yet been created (there is no > flow.xml.gz) at the time the policies are generated. > > However, I found that if a flow.xml.gz existed without a corresponding > authorizations.xml or users.xml, then the startup process would in fact > create the Component Access Policies and add the admin user to them. > > Now, with the introduction of flow.json.gz, the root process group has both > "identifier" and "instanceIdentifier" properties. The Component Access > Policies created on startup as described above reference the "identifier" > UUID, but the UI indicates the "instanceIdentifier" is the proper UUID for > the root process group. Therefore, the Component Access Policies are > ineffective as they reference an incorrect UUID value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10228) FlowParser is using incorrect identifier for process group
Mark Bean created NIFI-10228: Summary: FlowParser is using incorrect identifier for process group Key: NIFI-10228 URL: https://issues.apache.org/jira/browse/NIFI-10228 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.16.3 Reporter: Mark Bean When starting NiFi for the first time using the managed-authorizer, NiFi will put the Initial Admin Identity in certain Access Policies. However, it only does this for Global Access Policies, and does not add this user to any Component Access Policies, e.g. 'view/modify the component'. This has been frustrating, but as I understand it is unavoidable because the UUID of the root process group has not yet been created (there is no flow.xml.gz) at the time the policies are generated. However, I found that if a flow.xml.gz existed without a corresponding authorizations.xml or users.xml, then the startup process would in fact create the Component Access Policies and add the admin user to them. Now, with the introduction of flow.json.gz, the root process group has both "identifier" and "instanceIdentifier" properties. The Component Access Policies created on startup as described above reference the "identifier" UUID, but the UI indicates the "instanceIdentifier" is the proper UUID for the root process group. Therefore, the Component Access Policies are ineffective as they reference an incorrect UUID value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-8968) Improve throughput performance for InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558542#comment-17558542 ] Mark Bean commented on NIFI-8968: - Thanks for the additional info [~exceptionfactory] Unless/until the performance of InvokeHTTP can be improved, I suggest we remove the Deprecated tag from PostHTTP. This may become important in the not-to-distant future as there are discussions of a major release (NiFi 2.0). I suspect deprecated processors may be removed at this point. > Improve throughput performance for InvokeHTTP > - > > Key: NIFI-8968 > URL: https://issues.apache.org/jira/browse/NIFI-8968 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Mark Bean >Priority: Major > Attachments: PostHTTP_vs_InvokeHTTP.json, PostHTTP_vs_InvokeHTTP.xml > > > InvokeHTTP is the preferred processor to use over the deprecated PostHTTP. > However, PostHTTP outperforms InvokeHTTP (at least in POST mode). A template > and a JSON file have been attached to this ticket for benchmarking the two > processors. Using this flow, PostHTTP was observed to have a throughput of > approximately 5 times greater than InvokeHTTP. > In addition, it was noted that InvokeHTTP had approximately 5 times as many > tasks and 5 times the task duration for a given 5 minute stats window. And, > the statistics of Bytes Read and Bytes Transferred remain at zero for > InvokeHTTP; this area accurate statistics also needs to be addressed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (NIFI-5378) NiFiProperties: Add check to validation to prevent startup when duplicate keys are encountered
[ https://issues.apache.org/jira/browse/NIFI-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-5378: Affects Version/s: 1.16.1 Status: Patch Available (was: In Progress) > NiFiProperties: Add check to validation to prevent startup when duplicate > keys are encountered > -- > > Key: NIFI-5378 > URL: https://issues.apache.org/jira/browse/NIFI-5378 > Project: Apache NiFi > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.16.1, 1.7.0 >Reporter: Jon Kessler >Assignee: Mark Bean >Priority: Minor > > Currently duplicate keys can exist in the nifi.properties file and you aren't > necessarily guaranteed or sure which value will be used when the system > starts. There is already a method in NiFiProperties.java for validation at > startup. Logic should be added so that when duplicates are encountered the > system is not permitted to start. Also include a good log message to say what > the duplicates are and what the issue was. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (NIFI-5378) NiFiProperties: Add check to validation to prevent startup when duplicate keys are encountered
[ https://issues.apache.org/jira/browse/NIFI-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean reassigned NIFI-5378: --- Assignee: Mark Bean > NiFiProperties: Add check to validation to prevent startup when duplicate > keys are encountered > -- > > Key: NIFI-5378 > URL: https://issues.apache.org/jira/browse/NIFI-5378 > Project: Apache NiFi > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.7.0 >Reporter: Jon Kessler >Assignee: Mark Bean >Priority: Minor > > Currently duplicate keys can exist in the nifi.properties file and you aren't > necessarily guaranteed or sure which value will be used when the system > starts. There is already a method in NiFiProperties.java for validation at > startup. Logic should be added so that when duplicates are encountered the > system is not permitted to start. Also include a good log message to say what > the duplicates are and what the issue was. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (NIFI-5378) NiFiProperties: Add check to validation to prevent startup when duplicate keys are encountered
[ https://issues.apache.org/jira/browse/NIFI-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539742#comment-17539742 ] Mark Bean commented on NIFI-5378: - Reviving an old ticket. I think it is reasonable to not allow NiFi to start if duplicate keys with different values are detected in nifi.properties. Such a condition is most likely human error. And, rather than guess at which is the correct property, NiFi should log an error message and not start. On the other hand, if there are duplicate keys with the same value, then NiFi should log it as a warning and continue to start. > NiFiProperties: Add check to validation to prevent startup when duplicate > keys are encountered > -- > > Key: NIFI-5378 > URL: https://issues.apache.org/jira/browse/NIFI-5378 > Project: Apache NiFi > Issue Type: Improvement > Components: Configuration >Affects Versions: 1.7.0 >Reporter: Jon Kessler >Priority: Minor > > Currently duplicate keys can exist in the nifi.properties file and you aren't > necessarily guaranteed or sure which value will be used when the system > starts. There is already a method in NiFiProperties.java for validation at > startup. Logic should be added so that when duplicates are encountered the > system is not permitted to start. Also include a good log message to say what > the duplicates are and what the issue was. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (NIFI-8917) Create profiles to exclude ancillary modules from build
[ https://issues.apache.org/jira/browse/NIFI-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean resolved NIFI-8917. - Resolution: Won't Fix > Create profiles to exclude ancillary modules from build > --- > > Key: NIFI-8917 > URL: https://issues.apache.org/jira/browse/NIFI-8917 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.14.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > The source code for the nifi project now includes several projects which are > related but not explicitly required by the main nifi application. Recommend > the creation of profiles (e.g. "exclude-nifi-registry") for each of the > ancillary modules to be excluded from the build. These can be useful for > reducing build time during development, excluding components not intended to > be used by the builder. > The modules eligible for exclusion or exclusivity are: > minfi > nifi-registry > nifi-toolkit -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (NIFI-8917) Create profiles to exclude ancillary modules from build
[ https://issues.apache.org/jira/browse/NIFI-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-8917: Status: Open (was: Patch Available) Will not fix. There are alternative ways to accomplish the same thing. > Create profiles to exclude ancillary modules from build > --- > > Key: NIFI-8917 > URL: https://issues.apache.org/jira/browse/NIFI-8917 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Affects Versions: 1.14.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > The source code for the nifi project now includes several projects which are > related but not explicitly required by the main nifi application. Recommend > the creation of profiles (e.g. "exclude-nifi-registry") for each of the > ancillary modules to be excluded from the build. These can be useful for > reducing build time during development, excluding components not intended to > be used by the builder. > The modules eligible for exclusion or exclusivity are: > minfi > nifi-registry > nifi-toolkit -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (NIFI-9891) Add documentation of Parameter Context inheritance
Mark Bean created NIFI-9891: --- Summary: Add documentation of Parameter Context inheritance Key: NIFI-9891 URL: https://issues.apache.org/jira/browse/NIFI-9891 Project: Apache NiFi Issue Type: Improvement Components: Documentation Website Affects Versions: 1.16.0 Reporter: Mark Bean A new feature supporting inheritance of Parameter Contexts was added in version 1.16.0. Details of its usage should be added to the User Guide. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (NIFI-9562) Add archive conflict resolution strategy to PutFile
[ https://issues.apache.org/jira/browse/NIFI-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean resolved NIFI-9562. - Resolution: Won't Do > Add archive conflict resolution strategy to PutFile > --- > > Key: NIFI-9562 > URL: https://issues.apache.org/jira/browse/NIFI-9562 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > The PutFile processor would benefit from an 'archive' Conflict Resolution > Strategy. This strategy is similar to 'replace'. However, if a file exists on > the file system and would otherwise be overwritten (or cause the FlowFile to > fail), the existing file is moved to an archive directory specified by the > processor's configuration. > The processor will add the following properties which depend on the > replacement strategy value of "archive" (new). > Archive Directory > Archive Filename Extension > Maximum Archive File Count > Guarantee Archive Filename Uniqueness > The processor will (optionally) add an extension to the filename when moving > it to the archive directory. If that filename is still not unique, the > filename can be made unique by adding a distinct value such as UUID. Similar > to the regular directory location for PutFile, the archive directory may also > have a limit on the total number of files it will hold. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (NIFI-9562) Add archive conflict resolution strategy to PutFile
[ https://issues.apache.org/jira/browse/NIFI-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484379#comment-17484379 ] Mark Bean commented on NIFI-9562: - Canceling this ticket. There are alternatives to this approach. And, in a clustered environment, the use case breaks down because it would needless duplicate archived files on every node. > Add archive conflict resolution strategy to PutFile > --- > > Key: NIFI-9562 > URL: https://issues.apache.org/jira/browse/NIFI-9562 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > The PutFile processor would benefit from an 'archive' Conflict Resolution > Strategy. This strategy is similar to 'replace'. However, if a file exists on > the file system and would otherwise be overwritten (or cause the FlowFile to > fail), the existing file is moved to an archive directory specified by the > processor's configuration. > The processor will add the following properties which depend on the > replacement strategy value of "archive" (new). > Archive Directory > Archive Filename Extension > Maximum Archive File Count > Guarantee Archive Filename Uniqueness > The processor will (optionally) add an extension to the filename when moving > it to the archive directory. If that filename is still not unique, the > filename can be made unique by adding a distinct value such as UUID. Similar > to the regular directory location for PutFile, the archive directory may also > have a limit on the total number of files it will hold. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (NIFI-9562) Add archive conflict resolution strategy to PutFile
Mark Bean created NIFI-9562: --- Summary: Add archive conflict resolution strategy to PutFile Key: NIFI-9562 URL: https://issues.apache.org/jira/browse/NIFI-9562 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Mark Bean Assignee: Mark Bean The PutFile processor would benefit from an 'archive' Conflict Resolution Strategy. This strategy is similar to 'replace'. However, if a file exists on the file system and would otherwise be overwritten (or cause the FlowFile to fail), the existing file is moved to an archive directory specified by the processor's configuration. The processor will add the following properties which depend on the replacement strategy value of "archive" (new). Archive Directory Archive Filename Extension Maximum Archive File Count Guarantee Archive Filename Uniqueness The processor will (optionally) add an extension to the filename when moving it to the archive directory. If that filename is still not unique, the filename can be made unique by adding a distinct value such as UUID. Similar to the regular directory location for PutFile, the archive directory may also have a limit on the total number of files it will hold. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (NIFI-9433) Load Balancer hangs
[ https://issues.apache.org/jira/browse/NIFI-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452465#comment-17452465 ] Mark Bean commented on NIFI-9433: - Still chasing this, but I'll offer what I noted. In NioAsyncLoadBalanceClient partitions are added to partitionQueue, but are never removed, e.g. when a connection is removed from the flow. > Load Balancer hangs > --- > > Key: NIFI-9433 > URL: https://issues.apache.org/jira/browse/NIFI-9433 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.0 >Reporter: Mark Bean >Priority: Critical > > Simplified scenario to demonstrate problem: > A 2-node cluster with a simple flow. GenerateFlowFile -> load-balanced > connection -> UpdateAttribute. And, unconnected to the first two processors, > Funnel #1 -> non-load-balanced Connection -> Funnel #2. > GenerateFlowFile is scheduled to run on Primary Node only. It is started. > This causes the connection to be very busy load balancing (round robin). > Then, the connection between the two funnels is removed. > Immediately, an error is thrown, and the flow gets stuck in a state of > constantly throwing errors indicating that a connection (the one just > deleted) does not exist and cannot be balanced. > It is unclear why this connection is being considered by the load balancer at > all. > The sequence of errors include the following: > Primary Node reports > 2021-12-02 12:20:03,812 ERROR [NiFi Web Server-1811] > o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue Unacknowledged > from FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], > Swap Files=[0], Unacknowledged=[0, 0 Bytes] ] to FlowFile Queue Size[ > ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], > Unacknowledged=[-206, -20600 Bytes] ] > java.lang.RuntimeException: Cannot create negative queue size > 2021-12-02 12:20:03,813 ERROR [NiFi Web Server-1811] > o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue active from > FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap > Files=[0], Unacknowledged=[-206, -20600 Bytes] ] to FlowFile Queue Size[ > ActiveQueue=[206, 20600 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], > Unacknowledged=[-206, -20600 Bytes] ] > java.lang.RuntimeException: Cannot create negative queue size > The above may be a symptom of subsequent errors in the log: > Primary Node reports: > 2021-12-02 12:20:03,814 ERROR [Load-Balanced Client Thread-6] > o.a.n.c.q.c.c.a.n.NioAsyncLoadBalanceClient Failed to communicate with Peer > > java.io.IOException: Failed to negotiate Protocol Version with Peer > . Recommended version 1 but instead of an ACCEPT or REJECT > response got back a response of 33. > Non-Primary Node reports: > 2021-12-02 12:20:03,828 ERROR [Load-Balance Server Thread-4] > o.a.n.c.q.c.s.ConnectionLoadBalanceServer Failed to communicate with > Peer > java.io.IOException: Expected to receive Transaction Completion Indicator > from Peer but instead received a value of 1 > The highly concerning part is this error which indicates a Connection which > was not scheduled to load balance was attempting to receive a FlowFile. > Non-Primary Node reports: > 2021-12-02 12:29:05,228 ERROR [Load-Balance Server Thread-808] > o.a.n.c.q.c.s.StandardLoadBalanceProtocol Attempted to receive FlowFiles from > Peer for Connection with ID but no connection exists with that > ID. > Note the that value in this message corresponds to the Connection that > was removed causing the errors to begin. Should the above message ever occur? > Does the load balancer ever consider Connections which are configured as "Do > not load balance" > Users have also reported that FlowFiles have been load balanced from one > Connection to another, unrelated Connection on the other Node. (This is still > being verified.) > Finally, on the UI the load-balanced connection indicates it is actively load > balancing some number (206 in this case) of FlowFiles currently in the > connection. And, attempts to "list queue" on this connection show no > FlowFiles. Presumably they are being held by the load balancer and are > inaccessible in the queue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (NIFI-9433) Load Balancer hangs
[ https://issues.apache.org/jira/browse/NIFI-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-9433: Description: Simplified scenario to demonstrate problem: A 2-node cluster with a simple flow. GenerateFlowFile -> load-balanced connection -> UpdateAttribute. And, unconnected to the first two processors, Funnel #1 -> non-load-balanced Connection -> Funnel #2. GenerateFlowFile is scheduled to run on Primary Node only. It is started. This causes the connection to be very busy load balancing (round robin). Then, the connection between the two funnels is removed. Immediately, an error is thrown, and the flow gets stuck in a state of constantly throwing errors indicating that a connection (the one just deleted) does not exist and cannot be balanced. It is unclear why this connection is being considered by the load balancer at all. The sequence of errors include the following: Primary Node reports 2021-12-02 12:20:03,812 ERROR [NiFi Web Server-1811] o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue Unacknowledged from FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[0, 0 Bytes] ] to FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[-206, -20600 Bytes] ] java.lang.RuntimeException: Cannot create negative queue size 2021-12-02 12:20:03,813 ERROR [NiFi Web Server-1811] o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue active from FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[-206, -20600 Bytes] ] to FlowFile Queue Size[ ActiveQueue=[206, 20600 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[-206, -20600 Bytes] ] java.lang.RuntimeException: Cannot create negative queue size The above may be a symptom of subsequent errors in the log: Primary Node reports: 2021-12-02 12:20:03,814 ERROR [Load-Balanced Client Thread-6] o.a.n.c.q.c.c.a.n.NioAsyncLoadBalanceClient Failed to communicate with Peer java.io.IOException: Failed to negotiate Protocol Version with Peer . Recommended version 1 but instead of an ACCEPT or REJECT response got back a response of 33. Non-Primary Node reports: 2021-12-02 12:20:03,828 ERROR [Load-Balance Server Thread-4] o.a.n.c.q.c.s.ConnectionLoadBalanceServer Failed to communicate with Peer java.io.IOException: Expected to receive Transaction Completion Indicator from Peer but instead received a value of 1 The highly concerning part is this error which indicates a Connection which was not scheduled to load balance was attempting to receive a FlowFile. Non-Primary Node reports: 2021-12-02 12:29:05,228 ERROR [Load-Balance Server Thread-808] o.a.n.c.q.c.s.StandardLoadBalanceProtocol Attempted to receive FlowFiles from Peer for Connection with ID but no connection exists with that ID. Note the that value in this message corresponds to the Connection that was removed causing the errors to begin. Should the above message ever occur? Does the load balancer ever consider Connections which are configured as "Do not load balance" Users have also reported that FlowFiles have been load balanced from one Connection to another, unrelated Connection on the other Node. (This is still being verified.) Finally, on the UI the load-balanced connection indicates it is actively load balancing some number (206 in this case) of FlowFiles currently in the connection. And, attempts to "list queue" on this connection show no FlowFiles. Presumably they are being held by the load balancer and are inaccessible in the queue. was: Simplified scenario to demonstrate problem: A 2-node cluster with a simple flow. GenerateFlowFile -> load-balanced connection -> UpdateAttribute. And, unconnected to the first two processors, Funnel #1 -> non-load-balanced Connection -> Funnel #2. GenerateFlowFile is scheduled to run on Primary Node only. It is started. This causes the connection to be very busy load balancing (round robin). Then, the connection between the two funnels is removed. Immediately, an error is thrown, and the flow gets stuck in a state of constantly throwing errors indicating that a connection (the one just deleted) does not exist and cannot be balanced. It is unclear why this connection is being considered by the load balancer at all. The sequence of errors include the following: Primary Node reports 2021-12-02 12:20:03,812 ERROR [NiFi Web Server-1811] o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue Unacknowledged from FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[0, 0 Bytes] ] to FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[-206, -20600 Bytes] ] java.lang.RuntimeException: Cannot create negative queue size 2021-12-02 12:20:03,813 ERROR [NiFi Web
[jira] [Created] (NIFI-9433) Load Balancer hangs
Mark Bean created NIFI-9433:
---
Summary: Load Balancer hangs
Key: NIFI-9433
URL: https://issues.apache.org/jira/browse/NIFI-9433
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework
Affects Versions: 1.15.0
Reporter: Mark Bean
Simplified scenario to demonstrate problem:
A 2-node cluster with a simple flow. GenerateFlowFile -> load-balanced
connection -> UpdateAttribute. And, unconnected to the first two processors,
Funnel #1 -> non-load-balanced Connection -> Funnel #2.
GenerateFlowFile is scheduled to run on Primary Node only. It is started. This
causes the connection to be very busy load balancing (round robin). Then, the
connection between the two funnels is removed.
Immediately, an error is thrown, and the flow gets stuck in a state of
constantly throwing errors indicating that a connection (the one just deleted)
does not exist and cannot be balanced.
It is unclear why this connection is being considered by the load balancer at
all.
The sequence of errors include the following:
Primary Node reports
2021-12-02 12:20:03,812 ERROR [NiFi Web Server-1811]
o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue Unacknowledged from
FlowFile Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap
Files=[0], Unacknowledged=[0, 0 Bytes] ] to FlowFile Queue Size[
ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0],
Unacknowledged=[-206, -20600 Bytes] ]
java.lang.RuntimeException: Cannot create negative queue size
2021-12-02 12:20:03,813 ERROR [NiFi Web Server-1811]
o.a.n.c.queue.SwappablePriorityQueue Updated Size of Queue active from FlowFile
Queue Size[ ActiveQueue=[0, 0 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0],
Unacknowledged=[-206, -20600 Bytes] ] to FlowFile Queue Size[ ActiveQueue=[206,
20600 Bytes], Swap Queue=[0, 0 Bytes], Swap Files=[0], Unacknowledged=[-206,
-20600 Bytes] ]
java.lang.RuntimeException: Cannot create negative queue size
The above may be a symptom of subsequent errors in the log:
Primary Node reports:
2021-12-02 12:20:03,814 ERROR [Load-Balanced Client Thread-6]
o.a.n.c.q.c.c.a.n.NioAsyncLoadBalanceClient Failed to communicate with Peer
{host:port}
java.io.IOException: Failed to negotiate Protocol Version with Peer
{host:port}. Recommended version 1 but instead of an ACCEPT or REJECT response
got back a response of 33.
Non-Primary Node reports:
2021-12-02 12:20:03,828 ERROR [Load-Balance Server Thread-4]
o.a.n.c.q.c.s.ConnectionLoadBalanceServer Failed to communicate with Peer
{fqdn/IP:port}
java.io.IOException: Expected to receive Transaction Completion Indicator from
Peer {fqdn} but instead received a value of 1
The highly concerning part is this error which indicates a Connection which was
not scheduled to load balance was attempting to receive a FlowFile.
Non-Primary Node reports:
2021-12-02 12:29:05,228 ERROR [Load-Balance Server Thread-808]
o.a.n.c.q.c.s.StandardLoadBalanceProtocol Attempted to receive FlowFiles from
Peer {fqdn} for Connection with ID {uuid} but no connection exists with that ID.
Note the that {uuid} value in this message corresponds to the Connection that
was removed causing the errors to begin. Should the above message ever occur?
Does the load balancer ever consider Connections which are configured as "Do
not load balance"
Users have also reported that FlowFiles have been load balanced from one
Connection to another, unrelated Connection on the other Node. (This is still
being verified.)
Finally, on the UI the load-balanced connection indicates it is actively load
balancing some number (206 in this case) of FlowFiles currently in the
connection. And, attempts to "list queue" on this connection show no FlowFiles.
Presumably they are being held by the load balancer and are inaccessible in the
queue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (NIFI-9072) Improvements to ValidateXML
[ https://issues.apache.org/jira/browse/NIFI-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-9072: Status: Patch Available (was: In Progress) > Improvements to ValidateXML > > > Key: NIFI-9072 > URL: https://issues.apache.org/jira/browse/NIFI-9072 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.14.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The ValidateXML processor can be improved by optionally allowing a flowfile > attribute to be validated instead of only content. A new property, "XML > Source Attribute" is added to the processor. When this property is not empty, > it specifies the attribute name where the XML to be validated is located. > This XML is the source for validation. > In addition, sometimes an XML schema is not known and/or the user simply > wants to validate the XML is well-formed. The existing property, "Schema > File" should be optional. When it is not set, then only basic validation to > ensure the XML is well-formed is performed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-9072) Improvements to ValidateXML
[ https://issues.apache.org/jira/browse/NIFI-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435044#comment-17435044 ] Mark Bean commented on NIFI-9072: - I fully agree with your reservation to use large XML documents (or any large data item) in attributes. However, I find it overly limiting to prevent responsible usage only for fear it may be abused. I still believe this ticket represents a viable new feature when used appropriately. For example, upstream customers may be populating attributes (in XML format) to indicate metadata for the document contained in the flowfile contents. This does not require a large XML document. I pushed a new commit to the PR to include some additional documentation which discourages the use of large-valued attributes. See the processor description as well as the System Resources Considerations section. > Improvements to ValidateXML > > > Key: NIFI-9072 > URL: https://issues.apache.org/jira/browse/NIFI-9072 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.14.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The ValidateXML processor can be improved by optionally allowing a flowfile > attribute to be validated instead of only content. A new property, "XML > Source Attribute" is added to the processor. When this property is not empty, > it specifies the attribute name where the XML to be validated is located. > This XML is the source for validation. > In addition, sometimes an XML schema is not known and/or the user simply > wants to validate the XML is well-formed. The existing property, "Schema > File" should be optional. When it is not set, then only basic validation to > ensure the XML is well-formed is performed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-9056) Content Repository Filling Up
[ https://issues.apache.org/jira/browse/NIFI-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422289#comment-17422289 ] Mark Bean commented on NIFI-9056: - [~aheys] The trigger for NIFI-8727 was a ProcessSession.clone() followed by write() or append(), i.e. content is modified, before a commit(). I believe the issue occurs whether the commit() is performed explicitly by code or implicitly by the framework. You may want to check your custom processors for this pattern. > Content Repository Filling Up > - > > Key: NIFI-9056 > URL: https://issues.apache.org/jira/browse/NIFI-9056 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.13.2 >Reporter: Andrew Heys >Priority: Major > > We have a clustered nifi setup that has recently been upgraded to 1.13.2 from > 1.11.4. After upgrading, one of the issues we have run into is that the > Content Repository will fill up to the > nifi.content.repository.archive.backpressure.percentage mark and lock the > processing & canvas. The only solution is to restart nifi at this point. We > have the following properties set: > nifi.content.repository.archive.backpressure.percentage=95% > nifi.content.repository.archive.max.usage.percentage=25% > nifi.content.repository.archive.max.retention.period=2 hours > The max usage property seems to be completed ignored. Monitoring the nifi > cluster disk % for content repository shows that it slowly fills up over time > and never decreasing. If we pause the input to entire nifi flow and let all > the processing clear out with 0 flowfiles remaining on the canvas for 15+ > minutes, the content repository disk usage does not decrease. Currently, our > only solution is to restart nifi on a daily cron schedule. After restarting > the nifi, it will clear out the 80+ GB of the content repository and usage > falls down to 0%. > > There seems to be an issue removing the older content claims in 1.13.2. > Thanks! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-8727) claimantCount will never decrement to zero
[
https://issues.apache.org/jira/browse/NIFI-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421495#comment-17421495
]
Mark Bean commented on NIFI-8727:
-
Correction: After running for about 24 hours, NiFi was restarted and there were
no "Found unknown file" messages. The ones noted previously might be
attributable to claims that just recently became empty, but before the cleanup
process executed.
Either way, the symptom of a constantly growing content repository - resulting
from claims not reaching a claimant count of 0 - is no longer observed.
Note: the proposed solution will result in a StandardRepositoryRecord having a
type of UPDATE rather than the current logic having a value of CREATE.
> claimantCount will never decrement to zero
> --
>
> Key: NIFI-8727
> URL: https://issues.apache.org/jira/browse/NIFI-8727
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.12.0, 1.13.0, 1.12.1, 1.13.1, 1.13.2
> Environment: linux
>Reporter: wangliqiang
>Priority: Major
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> When running my processor code below :
> {code:java}
> //originalFlowFile has content , so ClaimantCount=1
> FlowFile multiFlowFile = session.clone(originalFlowFile); // claim count
> +1，so ClaimantCount=2
> multiFlowFile = session.write(multiFlowFile, new OutputStreamCallback() {
> @Override
> public void process(OutputStream out) throws IOException {
> IOUtils.write(tvMultiAlbumJson, out, Charset.forName("UTF-8"));
> }
> });//the new content will resuse the same resource claim , so ClaimantCount=3
> //At this point we have two flowfile and two contentClaim ，and ClaimCount=3.
> //When this two flowfiles dropped，the claimantCount should decrement to
> 0，however the result is ClaimantCount=1！
> //If we use "sh nifi.sh diagnostics --verbose dump.log" to get a dump log，we
> will find some info like this “default/465/1623853427574-10705, Claimant
> Count = 1, In Use = true, Awaiting Destruction = false, References (0) = []”
> //And the file “default/465/1623853427574-10705” will never be archived，and
> will never be destroyed，and the content_repository will use more storage than
> it configs.{code}
> The above is a sort of phenomenon. The reason is the code below：
> {code:java}
> //session.clone
> public FlowFile clone(FlowFile example, final long offset, final long size) {
> .
> final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null); //here the originalFlowFileRecord of record
> is null
> .
> return clone;
> }
> //session.commit
> private void updateClaimCounts(final RepositoryRecord record) {
> ..
> if (record.isContentModified()) {
> decrementClaimCount(originalClaim); //here the originalClaim is null
> }
> }{code}
> Perhaps we should not use session.clone like that，but without official note
> it will sometimes happen to be used.
> So i change "final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null)" to "final StandardRepositoryRecord record =
> new StandardRepositoryRecord(null, currRec);"
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (NIFI-8727) claimantCount will never decrement to zero
[
https://issues.apache.org/jira/browse/NIFI-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Bean reassigned NIFI-8727:
---
Assignee: Mark Bean
> claimantCount will never decrement to zero
> --
>
> Key: NIFI-8727
> URL: https://issues.apache.org/jira/browse/NIFI-8727
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.12.0, 1.13.0, 1.12.1, 1.13.1, 1.13.2
> Environment: linux
>Reporter: wangliqiang
>Assignee: Mark Bean
>Priority: Major
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> When running my processor code below :
> {code:java}
> //originalFlowFile has content , so ClaimantCount=1
> FlowFile multiFlowFile = session.clone(originalFlowFile); // claim count
> +1，so ClaimantCount=2
> multiFlowFile = session.write(multiFlowFile, new OutputStreamCallback() {
> @Override
> public void process(OutputStream out) throws IOException {
> IOUtils.write(tvMultiAlbumJson, out, Charset.forName("UTF-8"));
> }
> });//the new content will resuse the same resource claim , so ClaimantCount=3
> //At this point we have two flowfile and two contentClaim ，and ClaimCount=3.
> //When this two flowfiles dropped，the claimantCount should decrement to
> 0，however the result is ClaimantCount=1！
> //If we use "sh nifi.sh diagnostics --verbose dump.log" to get a dump log，we
> will find some info like this “default/465/1623853427574-10705, Claimant
> Count = 1, In Use = true, Awaiting Destruction = false, References (0) = []”
> //And the file “default/465/1623853427574-10705” will never be archived，and
> will never be destroyed，and the content_repository will use more storage than
> it configs.{code}
> The above is a sort of phenomenon. The reason is the code below：
> {code:java}
> //session.clone
> public FlowFile clone(FlowFile example, final long offset, final long size) {
> .
> final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null); //here the originalFlowFileRecord of record
> is null
> .
> return clone;
> }
> //session.commit
> private void updateClaimCounts(final RepositoryRecord record) {
> ..
> if (record.isContentModified()) {
> decrementClaimCount(originalClaim); //here the originalClaim is null
> }
> }{code}
> Perhaps we should not use session.clone like that，but without official note
> it will sometimes happen to be used.
> So i change "final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null)" to "final StandardRepositoryRecord record =
> new StandardRepositoryRecord(null, currRec);"
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-8727) claimantCount will never decrement to zero
[
https://issues.apache.org/jira/browse/NIFI-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420942#comment-17420942
]
Mark Bean commented on NIFI-8727:
-
I applied the same fix as above. Specifically, modified
StandardProcessSession.clone() such that the new repository record included a
reference to the current record:
final StandardRepositoryRecord record = new StandardRepositoryRecord(null,
currRec);
However, this did not resolve the problem completely. Through additional log
messages I added for debugging, I could see that the claimant count went to
zero. However, in the flowfile repo
(RocksDBFlowFileRepository.determineDestructibleClaims), I noted the "current
claim" is destructible, but the "original claim" is not. Yet, when NiFi was
restarted, that claim was identified as "Found unknown file" which means there
were no flowfiles associated with this claim.
> claimantCount will never decrement to zero
> --
>
> Key: NIFI-8727
> URL: https://issues.apache.org/jira/browse/NIFI-8727
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.12.0, 1.13.0, 1.12.1, 1.13.1, 1.13.2
> Environment: linux
>Reporter: wangliqiang
>Priority: Major
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> When running my processor code below :
> {code:java}
> //originalFlowFile has content , so ClaimantCount=1
> FlowFile multiFlowFile = session.clone(originalFlowFile); // claim count
> +1，so ClaimantCount=2
> multiFlowFile = session.write(multiFlowFile, new OutputStreamCallback() {
> @Override
> public void process(OutputStream out) throws IOException {
> IOUtils.write(tvMultiAlbumJson, out, Charset.forName("UTF-8"));
> }
> });//the new content will resuse the same resource claim , so ClaimantCount=3
> //At this point we have two flowfile and two contentClaim ，and ClaimCount=3.
> //When this two flowfiles dropped，the claimantCount should decrement to
> 0，however the result is ClaimantCount=1！
> //If we use "sh nifi.sh diagnostics --verbose dump.log" to get a dump log，we
> will find some info like this “default/465/1623853427574-10705, Claimant
> Count = 1, In Use = true, Awaiting Destruction = false, References (0) = []”
> //And the file “default/465/1623853427574-10705” will never be archived，and
> will never be destroyed，and the content_repository will use more storage than
> it configs.{code}
> The above is a sort of phenomenon. The reason is the code below：
> {code:java}
> //session.clone
> public FlowFile clone(FlowFile example, final long offset, final long size) {
> .
> final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null); //here the originalFlowFileRecord of record
> is null
> .
> return clone;
> }
> //session.commit
> private void updateClaimCounts(final RepositoryRecord record) {
> ..
> if (record.isContentModified()) {
> decrementClaimCount(originalClaim); //here the originalClaim is null
> }
> }{code}
> Perhaps we should not use session.clone like that，but without official note
> it will sometimes happen to be used.
> So i change "final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null)" to "final StandardRepositoryRecord record =
> new StandardRepositoryRecord(null, currRec);"
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-9056) Content Repository Filling Up
[ https://issues.apache.org/jira/browse/NIFI-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420939#comment-17420939 ] Mark Bean commented on NIFI-9056: - Thanks for the detail [~markap14]. It is possible the issue being reported here is being caused by [NIFI-8727|https://issues.apache.org/jira/browse/NIFI-8727]. > Content Repository Filling Up > - > > Key: NIFI-9056 > URL: https://issues.apache.org/jira/browse/NIFI-9056 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.13.2 >Reporter: Andrew Heys >Priority: Major > > We have a clustered nifi setup that has recently been upgraded to 1.13.2 from > 1.11.4. After upgrading, one of the issues we have run into is that the > Content Repository will fill up to the > nifi.content.repository.archive.backpressure.percentage mark and lock the > processing & canvas. The only solution is to restart nifi at this point. We > have the following properties set: > nifi.content.repository.archive.backpressure.percentage=95% > nifi.content.repository.archive.max.usage.percentage=25% > nifi.content.repository.archive.max.retention.period=2 hours > The max usage property seems to be completed ignored. Monitoring the nifi > cluster disk % for content repository shows that it slowly fills up over time > and never decreasing. If we pause the input to entire nifi flow and let all > the processing clear out with 0 flowfiles remaining on the canvas for 15+ > minutes, the content repository disk usage does not decrease. Currently, our > only solution is to restart nifi on a daily cron schedule. After restarting > the nifi, it will clear out the 80+ GB of the content repository and usage > falls down to 0%. > > There seems to be an issue removing the older content claims in 1.13.2. > Thanks! -- This message was sent by Atlassian Jira (v8.3.4#803005)
