[jira] [Created] (NIFI-13799) Replicated Cluster HTTP Requests should avoid Response Buffering
David Handermann created NIFI-13799: --- Summary: Replicated Cluster HTTP Requests should avoid Response Buffering Key: NIFI-13799 URL: https://issues.apache.org/jira/browse/NIFI-13799 Project: Apache NiFi Issue Type: Improvement Reporter: David Handermann Assignee: David Handermann HTTP request replication between clustered nodes buffers responses before returning to the client. This is acceptable for standard operations such as status retrieval and configuration changes, but it can result in heap memory exhaustion when attempting to download large file content for local evaluation. This issue is specific to clustered deployments because standalone instances do not require request replication. Buffering the response and deserializing into objects is necessary for returning merged status information, but it is not necessary for download operations. Refactoring the implementation for more selective buffering based on content size and operation type would avoid potential memory issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13794) Release NiFi NAR Maven Plugin 2.1.0
David Handermann created NIFI-13794: --- Summary: Release NiFi NAR Maven Plugin 2.1.0 Key: NIFI-13794 URL: https://issues.apache.org/jira/browse/NIFI-13794 Project: Apache NiFi Issue Type: Task Components: Tools and Build Reporter: David Handermann Assignee: David Handermann Fix For: nifi-nar-maven-plugin-2.1.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13773) Make nifi-nar-maven-plugin capable of using different versions of nifi-api and nifi-framework-api dependencies
[
https://issues.apache.org/jira/browse/NIFI-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13773:
Fix Version/s: nifi-nar-maven-plugin-2.1.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Make nifi-nar-maven-plugin capable of using different versions of nifi-api
> and nifi-framework-api dependencies
> --
>
> Key: NIFI-13773
> URL: https://issues.apache.org/jira/browse/NIFI-13773
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: nifi-nar-maven-plugin-2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> nifi-api is going to be extracted into a separate git repo and it will have
> its own release cycle in the future. So nifi-api and nifi versions will be
> independent and nifi with version A should be able to build with nifi-api
> version B (assumed they are compatible).
> Testing this scenario with nifi 2.0.0-SNAPSHOT and nifi-api 2.0.0 surfaced
> the following issue in nifi-nar-maven-plugin during doc generation:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.nifi:nifi-nar-maven-plugin:2.0.0:nar (default-nar) on project
> nifi-python-test-extensions-nar: Failed to create Extension Documentation:
> Could not resolve local dependency
> org.apache.nifi:nifi-framework-api:jar:2.0.0 {code}
> The nar plugin looks for nifi-framework-api with the exact same version as
> nifi-api's version. This needs to be improved in order to support the
> independent nifi-api vs nifi versioning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13712) Improve ListenSlack to catch channel join events
[ https://issues.apache.org/jira/browse/NIFI-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13712: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Improve ListenSlack to catch channel join events > > > Key: NIFI-13712 > URL: https://issues.apache.org/jira/browse/NIFI-13712 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > Improve the current implementation of the ListenSlack processor to also > capture the events when a member is joining a channel. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13753) Conduct Apache NiFi API 2.0.0 Release
[ https://issues.apache.org/jira/browse/NIFI-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13753. - Resolution: Fixed > Conduct Apache NiFi API 2.0.0 Release > - > > Key: NIFI-13753 > URL: https://issues.apache.org/jira/browse/NIFI-13753 > Project: Apache NiFi > Issue Type: Task >Affects Versions: nifi-api-2.0.0 >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: nifi-api-2.0.0 > > > Initial release of [Apache NiFi API|https://github.com/apache/nifi-api] as a > separate artifact for version 2.0.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13793) Place the correct minimum Maven version in nifi-api README
[ https://issues.apache.org/jira/browse/NIFI-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883880#comment-17883880 ] David Handermann commented on NIFI-13793: - By way of background, the intent of listing Maven 3.9 was to keep major and minor number, without necessarily having to update the README for every version increment, although there is some value in having the documentation reflect what is present in the Maven configuration itself. > Place the correct minimum Maven version in nifi-api README > -- > > Key: NIFI-13793 > URL: https://issues.apache.org/jira/browse/NIFI-13793 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Priority: Minor > > Currently the [README|https://github.com/apache/nifi-api/blob/main/README.md] > for the nifi-api has 3.9 as the Maven version but it should say 3.9.9 as that > is the minimum version specified in the > [pom.xml|https://github.com/apache/nifi-api/blob/42a35005c5d65d3989b2e452e20199eed75fec0e/pom.xml#L78] > file similar to in nifi where the minimum Maven version specified in the > [README|https://github.com/apache/nifi/blob/main/README.md] is 3.9.6. > Also it might be a good idea to have as the header in the nifi-api say > 'Minimum Requirements' as it does in the nifi README instead of > 'Requirements'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13793) Place the correct minimum Maven version in nifi-api README
[ https://issues.apache.org/jira/browse/NIFI-13793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883879#comment-17883879 ] David Handermann commented on NIFI-13793: - Thanks for summarizing these concerns [~dstiegli1]. It may be helpful to indicate the exact version of Maven in the README, matching the required version in the Maven configuration. I think it is best to leave the header as Requirements, because the module makes no compatibility claims regarding higher versions of Maven or Java. > Place the correct minimum Maven version in nifi-api README > -- > > Key: NIFI-13793 > URL: https://issues.apache.org/jira/browse/NIFI-13793 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Priority: Minor > > Currently the [README|https://github.com/apache/nifi-api/blob/main/README.md] > for the nifi-api has 3.9 as the Maven version but it should say 3.9.9 as that > is the minimum version specified in the > [pom.xml|https://github.com/apache/nifi-api/blob/42a35005c5d65d3989b2e452e20199eed75fec0e/pom.xml#L78] > file similar to in nifi where the minimum Maven version specified in the > [README|https://github.com/apache/nifi/blob/main/README.md] is 3.9.6. > Also it might be a good idea to have as the header in the nifi-api say > 'Minimum Requirements' as it does in the nifi README instead of > 'Requirements'. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13791) ConsumeKafka / PublishKafka should increment counters for messages sent/received per topic
[ https://issues.apache.org/jira/browse/NIFI-13791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13791: Resolution: Fixed Status: Resolved (was: Patch Available) > ConsumeKafka / PublishKafka should increment counters for messages > sent/received per topic > -- > > Key: NIFI-13791 > URL: https://issues.apache.org/jira/browse/NIFI-13791 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > At present, PublishKafka has a counter for records sent in total but not > per-topic. ConsumeKafka doesn't have any counters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13787) ConsumeKafka does not provide proper error handling
[ https://issues.apache.org/jira/browse/NIFI-13787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13787: Resolution: Fixed Status: Resolved (was: Patch Available) > ConsumeKafka does not provide proper error handling > --- > > Key: NIFI-13787 > URL: https://issues.apache.org/jira/browse/NIFI-13787 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 2.0.0-M2, 2.0.0-M3, 2.0.0-M4 >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > ConsumeKafka does not properly handle failure conditions. > In the event that an Exception is thrown, the consumer never rolls back the > offsets that have been consumed. As a result, this means that the next time > the processor runs, it will consume the next batch of events. If this is > successful, the commits when then be committed, having lost the group of > records that were previously consumed and not handled successfully. > This will likely require a rework of the abstractions that are provided by > the Kafka Connection Service / Kafka Consumer Service. The consumer service > attempts to handle connection pooling, but this means that the processor does > not have the necessary access to a particular Consumer in order to rollback > transactions, etc. Additionally, it leads to code that is rather complex, > whereas the pooling can be sufficiently handled in a couple lines of code in > the processor by simply using a BlockingQueue of consumers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13789) NullPointerException when trying to start a Stateless Process Group
[
https://issues.apache.org/jira/browse/NIFI-13789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13789:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> NullPointerException when trying to start a Stateless Process Group
> ---
>
> Key: NIFI-13789
> URL: https://issues.apache.org/jira/browse/NIFI-13789
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 2.0.0-M5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm encountering the following error when I try to start a stateless process
> group:
> {code:java}
> 2024-09-22 10:01:38,057 ERROR [Monitor Processor Lifecycle Thread-1]
> o.a.n.groups.StandardStatelessGroupNode
> StandardStatelessGroupNode[group=StandardProcessGroup[identifier=cbfb160c-1000-1192-710e-83dde392d8b1,name=Redpanda_Consume_Produce_Loop]]
> Failed to start
> StandardStatelessGroupNode[group=StandardProcessGroup[identifier=cbfb160c-1000-1192-710e-83dde392d8b1,name=Redpanda_Consume_Produce_Loop]];
> will try again in 10 seconds
> java.lang.NullPointerException: Cannot invoke
> "org.apache.nifi.groups.ProcessGroup.getParent()" because "topLevelGroup" is
> null
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.populatePropertiesMap(StandardVersionedComponentSynchronizer.java:1464)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.updateControllerService(StandardVersionedComponentSynchronizer.java:1390)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeControllerServices(StandardVersionedComponentSynchronizer.java:596)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:415)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:251)
> at
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:668)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:246)
> at
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3865)
> at
> org.apache.nifi.controller.flow.StandardStatelessGroupNodeFactory.createStatelessProcessGroup(StandardStatelessGroupNodeFactory.java:297)
> at
> org.apache.nifi.controller.flow.StandardStatelessGroupNodeFactory$1.createStatelessProcessGroup(StandardStatelessGroupNodeFactory.java:154)
> at
> org.apache.nifi.groups.StandardStatelessGroupNode.createStatelessFlow(StandardStatelessGroupNode.java:345)
> at
> org.apache.nifi.groups.StandardStatelessGroupNode.initialize(StandardStatelessGroupNode.java:218)
> at
> org.apache.nifi.groups.StandardStatelessGroupNode.lambda$initialize$1(StandardStatelessGroupNode.java:246)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1583) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-13784) Improve Kafka Processor Producer Handling
[ https://issues.apache.org/jira/browse/NIFI-13784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13784. - Resolution: Fixed > Improve Kafka Processor Producer Handling > - > > Key: NIFI-13784 > URL: https://issues.apache.org/jira/browse/NIFI-13784 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > I ran into some issues with PublishKafka not properly handling timeouts. Any > time there is a timeout, I encounter an error indicating that the incoming > FlowFile was not transferred to any relationship. This then yields the > processor, resulting in poor performance. > Looking further, I'm finding other issues that need to be addressed also, > such as PublishKafka creating a new Kafka Producer every time it is triggered > to run. This is expensive always but far moreso when using transactional > producers. > The Consumer has a leaky abstraction, in that the ConsumerService returned > extends AutoCloseable but then documents that processors should not close it, > only the KafkaConnectionService should. In that case, ConsumerService should > not implement AutoCloseable. We should never expose methods that we don't > want called. > Error handling is not properly implemented in the case of transaction commits > timing out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13784) Improve Kafka Processor Producer Handling
[ https://issues.apache.org/jira/browse/NIFI-13784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13784: Summary: Improve Kafka Processor Producer Handling (was: Improve Kafka Processors' handling) > Improve Kafka Processor Producer Handling > - > > Key: NIFI-13784 > URL: https://issues.apache.org/jira/browse/NIFI-13784 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > I ran into some issues with PublishKafka not properly handling timeouts. Any > time there is a timeout, I encounter an error indicating that the incoming > FlowFile was not transferred to any relationship. This then yields the > processor, resulting in poor performance. > Looking further, I'm finding other issues that need to be addressed also, > such as PublishKafka creating a new Kafka Producer every time it is triggered > to run. This is expensive always but far moreso when using transactional > producers. > The Consumer has a leaky abstraction, in that the ConsumerService returned > extends AutoCloseable but then documents that processors should not close it, > only the KafkaConnectionService should. In that case, ConsumerService should > not implement AutoCloseable. We should never expose methods that we don't > want called. > Error handling is not properly implemented in the case of transaction commits > timing out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13783) Replace Commons Codec Hex with Java HexFormat in Kafka Processors
David Handermann created NIFI-13783: --- Summary: Replace Commons Codec Hex with Java HexFormat in Kafka Processors Key: NIFI-13783 URL: https://issues.apache.org/jira/browse/NIFI-13783 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: David Handermann Assignee: David Handermann The Kafka Processors have minimal use of Apache Commons Codec for hexadecimal formatting. This is no longer required with the move to Java 21 and the availability of the Java HexFormat class. Calls to Commons Codec should be replaced and the dependency removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13714) RecordTransform python processors do not work with intended python dictionary result
[
https://issues.apache.org/jira/browse/NIFI-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann resolved NIFI-13714.
-
Fix Version/s: 2.0.0-M5
Resolution: Fixed
> RecordTransform python processors do not work with intended python dictionary
> result
>
>
> Key: NIFI-13714
> URL: https://issues.apache.org/jira/browse/NIFI-13714
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Gábor Gyimesi
>Assignee: Gábor Gyimesi
>Priority: Major
> Fix For: 2.0.0-M5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There is a single example for RecordTransform processors in the NiFi
> repository which is SetRecordField.py. The processor reads json records and
> partitions them to separate flow files depending on the 'group' key in the
> json record. The partition is then passed as a python dictionary to the
> RecordTransformResult's partition parameter. When using this processor in a
> NiFi flow it fails with the following error:
> {code:java}
> 2024-09-05 10:13:12,570 ERROR [python-log-167728] py4j.java_gateway There was
> an exception while executing the Python Proxy on the Python Side.
> Traceback (most recent call last):
> File
> "/home/ggyimesi/projects/nifi/nifi-assembly/target/nifi-2.0.0-M4-bin/nifi-2.0.0-M4/python/framework/py4j/java_gateway.py",
> line 2468, in _call_proxy
> get_command_part(return_value, self.pool)
> File
> "/home/ggyimesi/projects/nifi/nifi-assembly/target/nifi-2.0.0-M4-bin/nifi-2.0.0-M4/python/framework/py4j/protocol.py",
> line 298, in get_command_part
> command_part = REFERENCE_TYPE + parameter._get_object_id()
> AttributeError: 'dict' object has no attribute '_get_object_id'
> 2024-09-05 10:13:12,573 INFO [Index Provenance Events-1]
> o.a.l.s.MemorySegmentIndexInputProvider Using MemorySegmentIndexInput and
> native madvise support with Java 21 or later; to disable start with
> -Dorg.apache.lucene.store.MMapDirectory.enableMemorySegments=false
> 2024-09-05 10:13:12,571 ERROR [Timer-Driven Process Thread-6]
> o.a.n.p.processor.RecordTransformProxy PythonProcessor[type=SetRecordField,
> id=c13967ae-0191-1000-1b43-dc620ce47e4f] Failed to transform
> StandardFlowFileRecord[uuid=889075ce-72aa-4186-84fe-801f54491e21,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1725523992497-1, container=default,
> section=1], offset=0, length=171],offset=0,name=record.json,size=171];
> routing to failure
> py4j.Py4JException: An exception was raised by the Python Proxy. Return
> Message: Traceback (most recent call last):
> File
> "/home/ggyimesi/projects/nifi/nifi-assembly/target/nifi-2.0.0-M4-bin/nifi-2.0.0-M4/python/framework/py4j/java_gateway.py",
> line 2468, in _call_proxy
> get_command_part(return_value, self.pool)
> File
> "/home/ggyimesi/projects/nifi/nifi-assembly/target/nifi-2.0.0-M4-bin/nifi-2.0.0-M4/python/framework/py4j/protocol.py",
> line 298, in get_command_part
> command_part = REFERENCE_TYPE + parameter._get_object_id()
> AttributeError: 'dict' object has no attribute '_get_object_id'
> {code}
> It seems the NiFi Python API does not handle python dictionaries correctly as
> it is supposed to, when the python dictionary is replaced with a
> JvmHolder.gateway.jvm.java.util.HashMap type and that is passed to the
> partition parameter in the result then the processor works as expected. We
> shouldn't depend on java types in a python processor implementation, so this
> should be fixed so that python dictionaries are handled correctly here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13777) Stateless Process Groups fail to start if any Processor makes use of a Controller Service in its @OnScheduled method
[ https://issues.apache.org/jira/browse/NIFI-13777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13777: Resolution: Fixed Status: Resolved (was: Patch Available) > Stateless Process Groups fail to start if any Processor makes use of a > Controller Service in its @OnScheduled method > > > Key: NIFI-13777 > URL: https://issues.apache.org/jira/browse/NIFI-13777 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 2.0.0-M2, 2.0.0-M3, 2.0.0-M4 >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > When starting a Stateless Process Group, if any of the Processors attempt to > access a Controller Service in its @OnScheduled method (e.g., ConsumeKafka) > the logs are filled with huge numbers of errors indicating that the processor > cannot start because the Controller Service is disabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13775) Kafka Bundles inherit the incorrect parent NAR and Upgrade Kafka Client Version to 3.8.0
[ https://issues.apache.org/jira/browse/NIFI-13775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13775: Summary: Kafka Bundles inherit the incorrect parent NAR and Upgrade Kafka Client Version to 3.8.0 (was: New kafka services inherit the incorrect parent NAR and bump Kafka Client Version to 3.8.0) > Kafka Bundles inherit the incorrect parent NAR and Upgrade Kafka Client > Version to 3.8.0 > > > Key: NIFI-13775 > URL: https://issues.apache.org/jira/browse/NIFI-13775 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > New Kafka processors fail due to missing things like commons-lang3. > It turns out the kafka module pom declares it extends from the > nifi-standard-shared-bom but then the services nar says it depends on > nifi-standard-services-api-nar. The services nar should depend on the > nifi-standard-shared-nar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13775) Kafka Bundles inherit the incorrect parent NAR and Upgrade Kafka Client Version to 3.8.0
[ https://issues.apache.org/jira/browse/NIFI-13775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13775. - Resolution: Fixed > Kafka Bundles inherit the incorrect parent NAR and Upgrade Kafka Client > Version to 3.8.0 > > > Key: NIFI-13775 > URL: https://issues.apache.org/jira/browse/NIFI-13775 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > New Kafka processors fail due to missing things like commons-lang3. > It turns out the kafka module pom declares it extends from the > nifi-standard-shared-bom but then the services nar says it depends on > nifi-standard-services-api-nar. The services nar should depend on the > nifi-standard-shared-nar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13770) Remove Placeholder Prefix from Python Component Type
[
https://issues.apache.org/jira/browse/NIFI-13770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13770:
Status: Patch Available (was: In Progress)
> Remove Placeholder Prefix from Python Component Type
>
>
> Key: NIFI-13770
> URL: https://issues.apache.org/jira/browse/NIFI-13770
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The original implementation of Python Processors included an internal prefix
> of {{python.}} for Python components to work around label rendering in the
> user interface, which expected a package name in the Component Type. With
> adjustments to the user interface rendering for Component Type labels, the
> placeholder prefix can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13770) Remove Placeholder Prefix from Python Component Type
David Handermann created NIFI-13770:
---
Summary: Remove Placeholder Prefix from Python Component Type
Key: NIFI-13770
URL: https://issues.apache.org/jira/browse/NIFI-13770
Project: Apache NiFi
Issue Type: Improvement
Reporter: David Handermann
Assignee: David Handermann
The original implementation of Python Processors included an internal prefix of
{{python.}} for Python components to work around label rendering in the user
interface, which expected a package name in the Component Type. With
adjustments to the user interface rendering for Component Type labels, the
placeholder prefix can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13750) Improve performance for listing large SFTP directories
[ https://issues.apache.org/jira/browse/NIFI-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13750: Issue Type: Improvement (was: Task) > Improve performance for listing large SFTP directories > --- > > Key: NIFI-13750 > URL: https://issues.apache.org/jira/browse/NIFI-13750 > Project: Apache NiFi > Issue Type: Improvement >Reporter: endzeit >Assignee: endzeit >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Use improvements introduced to > [sshj#928|https://github.com/hierynomus/sshj/pull/928] to greatly reduce time > required for listing large remote directories using ListSFTP -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13750) Improve performance for listing large SFTP directories
[ https://issues.apache.org/jira/browse/NIFI-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13750: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Improve performance for listing large SFTP directories > --- > > Key: NIFI-13750 > URL: https://issues.apache.org/jira/browse/NIFI-13750 > Project: Apache NiFi > Issue Type: Improvement >Reporter: endzeit >Assignee: endzeit >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > Use improvements introduced to > [sshj#928|https://github.com/hierynomus/sshj/pull/928] to greatly reduce time > required for listing large remote directories using ListSFTP -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13763) HashSet filtering can not be set for DeduplicateRecord processor
[
https://issues.apache.org/jira/browse/NIFI-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13763:
Priority: Minor (was: Major)
> HashSet filtering can not be set for DeduplicateRecord processor
>
>
> Key: NIFI-13763
> URL: https://issues.apache.org/jira/browse/NIFI-13763
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Timea Barna
>Assignee: Timea Barna
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following calculation determines which filtering method should be used:
> {code:java}boolean useHashSet = context.getProperty(FILTER_TYPE).getValue()
> .equals(context.getProperty(HASH_SET_VALUE.getValue()).getValue());{code}
> As HASH_SET_VALUE is an Allowable value not a PropertyDescriptor, this
> boolean will always be false, so in all cases Bloom Filter will be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13763) HashSet filtering can not be set for DeduplicateRecord processor
[
https://issues.apache.org/jira/browse/NIFI-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13763:
Issue Type: Bug (was: New Feature)
> HashSet filtering can not be set for DeduplicateRecord processor
>
>
> Key: NIFI-13763
> URL: https://issues.apache.org/jira/browse/NIFI-13763
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Timea Barna
>Assignee: Timea Barna
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following calculation determines which filtering method should be used:
> {code:java}boolean useHashSet = context.getProperty(FILTER_TYPE).getValue()
> .equals(context.getProperty(HASH_SET_VALUE.getValue()).getValue());{code}
> As HASH_SET_VALUE is an Allowable value not a PropertyDescriptor, this
> boolean will always be false, so in all cases Bloom Filter will be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13763) HashSet filtering can not be set for DeduplicateRecord processor
[
https://issues.apache.org/jira/browse/NIFI-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13763:
Component/s: Extensions
> HashSet filtering can not be set for DeduplicateRecord processor
>
>
> Key: NIFI-13763
> URL: https://issues.apache.org/jira/browse/NIFI-13763
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Timea Barna
>Assignee: Timea Barna
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following calculation determines which filtering method should be used:
> {code:java}boolean useHashSet = context.getProperty(FILTER_TYPE).getValue()
> .equals(context.getProperty(HASH_SET_VALUE.getValue()).getValue());{code}
> As HASH_SET_VALUE is an Allowable value not a PropertyDescriptor, this
> boolean will always be false, so in all cases Bloom Filter will be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13763) HashSet filtering can not be set for DeduplicateRecord processor
[
https://issues.apache.org/jira/browse/NIFI-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13763:
Fix Version/s: 1.28.0
2.0.0-M5
Resolution: Fixed
Status: Resolved (was: Patch Available)
> HashSet filtering can not be set for DeduplicateRecord processor
>
>
> Key: NIFI-13763
> URL: https://issues.apache.org/jira/browse/NIFI-13763
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Timea Barna
>Assignee: Timea Barna
>Priority: Minor
> Fix For: 1.28.0, 2.0.0-M5
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following calculation determines which filtering method should be used:
> {code:java}boolean useHashSet = context.getProperty(FILTER_TYPE).getValue()
> .equals(context.getProperty(HASH_SET_VALUE.getValue()).getValue());{code}
> As HASH_SET_VALUE is an Allowable value not a PropertyDescriptor, this
> boolean will always be false, so in all cases Bloom Filter will be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13758) Upgrade Google Cloud Libraries to 26.46.0
[ https://issues.apache.org/jira/browse/NIFI-13758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13758: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Google Cloud Libraries to 26.46.0 > - > > Key: NIFI-13758 > URL: https://issues.apache.org/jira/browse/NIFI-13758 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > The Google Cloud Libraries BOM dependency should be upgraded from 26.45.0 to > 26.46.0 to incorporate several bug fixes and improvements, including a > resolution for > [https://github.com/googleapis/google-auth-library-java/issues/1387] in > google-auth-library-oauth2-http library (see also NIFI-13583). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13768) Upgrade protobuf to 3.25.5
[ https://issues.apache.org/jira/browse/NIFI-13768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13768. - Resolution: Fixed > Upgrade protobuf to 3.25.5 > -- > > Key: NIFI-13768 > URL: https://issues.apache.org/jira/browse/NIFI-13768 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > Protobuf dependencies in OpenTelemetry and Protobuf Reader extensions should > be upgrade to 3.25.5 to resolve CVE-2024-7254 related to parsing crafted > binary fields resulting in a StackOverflow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13768) Upgrade protobuf to 3.25.5
David Handermann created NIFI-13768: --- Summary: Upgrade protobuf to 3.25.5 Key: NIFI-13768 URL: https://issues.apache.org/jira/browse/NIFI-13768 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: David Handermann Assignee: David Handermann Fix For: 2.0.0-M5 Protobuf dependencies in OpenTelemetry and Protobuf Reader extensions should be upgrade to 3.25.5 to resolve CVE-2024-7254 related to parsing crafted binary fields resulting in a StackOverflow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13767) Upgrade express to 4.21.0
[ https://issues.apache.org/jira/browse/NIFI-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13767. - Resolution: Fixed > Upgrade express to 4.21.0 > -- > > Key: NIFI-13767 > URL: https://issues.apache.org/jira/browse/NIFI-13767 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > The express library is a development dependency of NiFi Registry and should > be upgraded to 4.21.0 to mitigate vulnerability findings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13767) Upgrade express to 4.21.0
David Handermann created NIFI-13767: --- Summary: Upgrade express to 4.21.0 Key: NIFI-13767 URL: https://issues.apache.org/jira/browse/NIFI-13767 Project: Apache NiFi Issue Type: Improvement Components: NiFi Registry Reporter: David Handermann Assignee: David Handermann Fix For: 2.0.0-M5 The express library is a development dependency of NiFi Registry and should be upgraded to 4.21.0 to mitigate vulnerability findings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13753) Conduct Apache NiFi API 2.0.0 Release
[ https://issues.apache.org/jira/browse/NIFI-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13753: Fix Version/s: nifi-api-2.0.0 > Conduct Apache NiFi API 2.0.0 Release > - > > Key: NIFI-13753 > URL: https://issues.apache.org/jira/browse/NIFI-13753 > Project: Apache NiFi > Issue Type: Task >Affects Versions: nifi-api-2.0.0 >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: nifi-api-2.0.0 > > > Initial release of [Apache NiFi API|https://github.com/apache/nifi-api] as a > separate artifact for version 2.0.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13757) Uploaded NAR hits Error and stays Installing
[ https://issues.apache.org/jira/browse/NIFI-13757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13757. - Fix Version/s: 2.0.0-M5 Resolution: Fixed > Uploaded NAR hits Error and stays Installing > > > Key: NIFI-13757 > URL: https://issues.apache.org/jira/browse/NIFI-13757 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > The NarInstallTask has a try/catch for Exception, but in some cases > attempting to load the actual extension class may produce a sub-class of > Error which is not caught by the task, so then the state never gets updated > to FAILED and the error message never gets set. > In addition, at the point during which it hits the Error, the NAR has already > been registered in ExtensionManager, and future calls to get available > extension types will see the bundle and attempt to access the extension > definitions, which also encounters the same Error and fails the overall > request. This should be made more lenient to still allow all the other > available extensions to be returned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13753) Conduct Apache NiFi API 2.0.0 Release
[ https://issues.apache.org/jira/browse/NIFI-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13753: Summary: Conduct Apache NiFi API 2.0.0 Release (was: Conduct Apache NiFi API 2.0.0) > Conduct Apache NiFi API 2.0.0 Release > - > > Key: NIFI-13753 > URL: https://issues.apache.org/jira/browse/NIFI-13753 > Project: Apache NiFi > Issue Type: Task >Affects Versions: nifi-api-2.0.0 >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > > Initial release of [Apache NiFi API|https://github.com/apache/nifi-api] as a > separate artifact for version 2.0.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13753) Conduct Apache NiFi API 2.0.0
David Handermann created NIFI-13753: --- Summary: Conduct Apache NiFi API 2.0.0 Key: NIFI-13753 URL: https://issues.apache.org/jira/browse/NIFI-13753 Project: Apache NiFi Issue Type: Task Affects Versions: nifi-api-2.0.0 Reporter: David Handermann Assignee: David Handermann Initial release of [Apache NiFi API|https://github.com/apache/nifi-api] as a separate artifact for version 2.0.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13732) Create initial nifi-api repository
[ https://issues.apache.org/jira/browse/NIFI-13732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13732. - Fix Version/s: nifi-api-2.0.0 Resolution: Fixed > Create initial nifi-api repository > -- > > Key: NIFI-13732 > URL: https://issues.apache.org/jira/browse/NIFI-13732 > Project: Apache NiFi > Issue Type: New Feature >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: nifi-api-2.0.0 > > > The nifi-api repository should be created and populated with the current > version of the nifi-api module from the main branch in the NiFi project > repository. The initial version should remain 2.0.0-SNAPSHOT in preparation > for an initial release of the nifi-api module for reference in the main > repository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13736) Documentation update for Expression Language join function
[
https://issues.apache.org/jira/browse/NIFI-13736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13736:
Fix Version/s: 2.0.0-M5
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Documentation update for Expression Language join function
> --
>
> Key: NIFI-13736
> URL: https://issues.apache.org/jira/browse/NIFI-13736
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Mark Bean
>Assignee: Mark Bean
>Priority: Minor
> Fix For: 2.0.0-M5
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The expected output of the `join` method in the Expression Language Guide is
> incorrect.
> Provided:
> Expression: ${allAttributes("abc", "xyz"):join(" now")}
> Value: hello world nowgood bye world now
> Correct expected value should not include "now" at the end of the Value.
> Value: hello world nowgood bye world
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-7583) Update User Guide to explain how swapping affects queue prioritization
[ https://issues.apache.org/jira/browse/NIFI-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-7583: --- Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Update User Guide to explain how swapping affects queue prioritization > -- > > Key: NIFI-7583 > URL: https://issues.apache.org/jira/browse/NIFI-7583 > Project: Apache NiFi > Issue Type: Task > Components: Configuration >Reporter: Mark Payne >Assignee: Eric Secules >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13751) Update sshj to v0.39.0
[ https://issues.apache.org/jira/browse/NIFI-13751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13751: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Update sshj to v0.39.0 > -- > > Key: NIFI-13751 > URL: https://issues.apache.org/jira/browse/NIFI-13751 > Project: Apache NiFi > Issue Type: Task >Reporter: endzeit >Assignee: endzeit >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13745) Extend the NiFi Python API with access to StateManager
[ https://issues.apache.org/jira/browse/NIFI-13745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881704#comment-17881704 ] David Handermann commented on NIFI-13745: - Thanks for the summary and updates [~pgyori]. The exception handling is worth considering. In the Java implementation, a state manager implementation may fail to write the state map, and the calling Processor may or may decide to fail the entire process. This seems like an important aspect of implementation for the Python API. >From a package name point of view, just using `state` seems like an option >instead of `componentstate`. The StateMap version is also important from a comparison point of view, as different component instances may attempt optimistic updates based on the retrieved version. > Extend the NiFi Python API with access to StateManager > -- > > Key: NIFI-13745 > URL: https://issues.apache.org/jira/browse/NIFI-13745 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: Peter Gyori >Assignee: Peter Gyori >Priority: Major > > There are use-cases where it is necessary to store state from Python-based > processors in NiFi. One such case is creating and using a List* type Python > processor that needs to store information regarding which items have already > been listed in previous executions. For that we need to expose the > StateManager functionality through the Python API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13745) Extend the NiFi Python API with access to StateManager
[ https://issues.apache.org/jira/browse/NIFI-13745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881548#comment-17881548 ] David Handermann commented on NIFI-13745: - [~pgyori] Thanks for describing the general goal of this addition to the Python API. The general use case makes sense, and this sounds like a good opportunity to develop an approach that is straightforward to use. What do you have in mind in terms of the basic implementation? The Java StateManager interface is fairly straightforward, although exception handling is one key aspect to consider. On the Python side, supporting a dictionary of string keys and values seems like a natural fit, but representing the StateMap with optional version will be another important aspect. > Extend the NiFi Python API with access to StateManager > -- > > Key: NIFI-13745 > URL: https://issues.apache.org/jira/browse/NIFI-13745 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: Peter Gyori >Assignee: Peter Gyori >Priority: Major > > There are use-cases where it is necessary to store state from Python-based > processors in NiFi. One such case is creating and using a List* type Python > processor that needs to store information regarding which items have already > been listed in previous executions. For that we need to expose the > StateManager functionality through the Python API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13734) Elasticsearch Client Service Integration Test Failing
David Handermann created NIFI-13734:
---
Summary: Elasticsearch Client Service Integration Test Failing
Key: NIFI-13734
URL: https://issues.apache.org/jira/browse/NIFI-13734
Project: Apache NiFi
Issue Type: Bug
Reporter: David Handermann
Assignee: David Handermann
Recent changes to Elasticsearch support included adjustments for the {{took}}
field that records the amount of time spent running a query. The
ElasticSearchClientService_IT is failing when asserting some values for
{{{}getTook(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-13730) Refactor TestUpdateAttribute using current API methods
[ https://issues.apache.org/jira/browse/NIFI-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13730. - Fix Version/s: 2.0.0-M5 Resolution: Fixed > Refactor TestUpdateAttribute using current API methods > -- > > Key: NIFI-13730 > URL: https://issues.apache.org/jira/browse/NIFI-13730 > Project: Apache NiFi > Issue Type: Task >Reporter: endzeit >Assignee: endzeit >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13715) StandardProvenanceEventRecord.hashCode() is not consistent with equals() in handling Parent/Child FlowFiles
[
https://issues.apache.org/jira/browse/NIFI-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13715:
Fix Version/s: 1.28.0
> StandardProvenanceEventRecord.hashCode() is not consistent with equals() in
> handling Parent/Child FlowFiles
> ---
>
> Key: NIFI-13715
> URL: https://issues.apache.org/jira/browse/NIFI-13715
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 1.28.0, 2.0.0-M5
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{StandardProvenanceEventRecord}} may contain Child FlowFile UUIDs stored in
> a list (and similarly Parent FlowFile UUIDs in another list). The
> {{equals()}} method
> [sorts|https://github.com/apache/nifi/blob/d56f92d738e54b8e9c0ce04606bd7b6259375239/nifi-commons/nifi-data-provenance-utils/src/main/java/org/apache/nifi/provenance/StandardProvenanceEventRecord.java#L400]
> the UUID lists of the event objects before comparing them and therefore 2
> event objects are considered equal if they have the same Child FlowFiles but
> in different order. On the other hand, {{hashCode()}} does not apply sorting
> and produces different hashes for these equal objects which breaks the
> equals/hashCode contract: _If two objects are equal according to the equals()
> method, then the hashCode() method must return the same value for them._
> Real life flow example where the improper {{hashCode()}} method causes an
> issue:
> QueryRecord with multiple queries and output relationships. The processor's
> code emits a FORK provenance event with 2+ Child FlowFiles (that many outputs
> it has). The framework
> ([StandardProcessSession|https://github.com/apache/nifi/blob/d56f92d738e54b8e9c0ce04606bd7b6259375239/nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/controller/repository/StandardProcessSession.java#L849-L851])
> can also generate the FORK event automatically and it checks if the
> component has already emitted the event and if yes, it will skip the
> automatic one. Due to the wrong hashCode() method, this check may fail and in
> this case 2 FORK events are saved in Provenance repository. This leads to
> "Unable to generate Lineage Graph because multiple events were registered
> claiming to have generated the same FlowFile" error when opening the next
> event after the FORKs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13718) Switch Request Replicator from OkHttp to Web Client Service
David Handermann created NIFI-13718: --- Summary: Switch Request Replicator from OkHttp to Web Client Service Key: NIFI-13718 URL: https://issues.apache.org/jira/browse/NIFI-13718 Project: Apache NiFi Issue Type: Improvement Reporter: David Handermann Assignee: David Handermann The framework cluster module includes an implementation of the HTTP Request Replicator based on the OkHttp library. With the introduction of the nifi-web-client-api and refactoring the implementation to use the Java HttpClient, the Request Replicator Client should be refactored to use the Web Client Service interface, removing dependencies on OkHttp and Kotlin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13706) Handle Exceptions Fetching Parameters on Startup
[ https://issues.apache.org/jira/browse/NIFI-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13706: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Handle Exceptions Fetching Parameters on Startup > > > Key: NIFI-13706 > URL: https://issues.apache.org/jira/browse/NIFI-13706 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > Following recent changes to fetch parameters from Parameter Providers on > startup, configuration problems or connectivity issues can throw exceptions, > causing the NiFi application process to fail on initialization. > Fetching parameters already handles missing parameters, logging a warning. > Adding exception handling to the parameter fetching method will allow NiFi to > start with logs indicating missing parameters. Although the flow > configuration may be missing parameters when NiFi starts, allowing the > application start permits an authorized user to correct the Parameter > Provider configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13707) Switch Kubernetes HTTP Client from OkHttp to JDK
[
https://issues.apache.org/jira/browse/NIFI-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13707:
Status: Patch Available (was: Open)
> Switch Kubernetes HTTP Client from OkHttp to JDK
>
>
> Key: NIFI-13707
> URL: https://issues.apache.org/jira/browse/NIFI-13707
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Kubernetes Client framework extensions use the Fabric8 library which
> provides different options for HTTP requests. The default implementation uses
> OkHttp, but the
> [kubernetes-httpclient-jdk|https://central.sonatype.com/artifact/io.fabric8/kubernetes-httpclient-jdk]
> supports the Java HttpClient available in Java 9 and following. Excluding
> the {{kubernetes-httpclient-okhttp}} library and adding a dependency on the
> JDK implementation enables the Fabric8 client to use the JDK version based on
> Service Provider discovery.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13707) Switch Kubernetes HTTP Client from OkHttp to JDK
David Handermann created NIFI-13707:
---
Summary: Switch Kubernetes HTTP Client from OkHttp to JDK
Key: NIFI-13707
URL: https://issues.apache.org/jira/browse/NIFI-13707
Project: Apache NiFi
Issue Type: Improvement
Reporter: David Handermann
Assignee: David Handermann
The Kubernetes Client framework extensions use the Fabric8 library which
provides different options for HTTP requests. The default implementation uses
OkHttp, but the
[kubernetes-httpclient-jdk|https://central.sonatype.com/artifact/io.fabric8/kubernetes-httpclient-jdk]
supports the Java HttpClient available in Java 9 and following. Excluding the
{{kubernetes-httpclient-okhttp}} library and adding a dependency on the JDK
implementation enables the Fabric8 client to use the JDK version based on
Service Provider discovery.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13706) Handle Exceptions Fetching Parameters on Startup
[ https://issues.apache.org/jira/browse/NIFI-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13706: Status: Patch Available (was: Open) > Handle Exceptions Fetching Parameters on Startup > > > Key: NIFI-13706 > URL: https://issues.apache.org/jira/browse/NIFI-13706 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Following recent changes to fetch parameters from Parameter Providers on > startup, configuration problems or connectivity issues can throw exceptions, > causing the NiFi application process to fail on initialization. > Fetching parameters already handles missing parameters, logging a warning. > Adding exception handling to the parameter fetching method will allow NiFi to > start with logs indicating missing parameters. Although the flow > configuration may be missing parameters when NiFi starts, allowing the > application start permits an authorized user to correct the Parameter > Provider configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13706) Handle Exceptions Fetching Parameters on Startup
David Handermann created NIFI-13706: --- Summary: Handle Exceptions Fetching Parameters on Startup Key: NIFI-13706 URL: https://issues.apache.org/jira/browse/NIFI-13706 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: David Handermann Assignee: David Handermann Following recent changes to fetch parameters from Parameter Providers on startup, configuration problems or connectivity issues can throw exceptions, causing the NiFi application process to fail on initialization. Fetching parameters already handles missing parameters, logging a warning. Adding exception handling to the parameter fetching method will allow NiFi to start with logs indicating missing parameters. Although the flow configuration may be missing parameters when NiFi starts, allowing the application start permits an authorized user to correct the Parameter Provider configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13705) Refactor Stateless Engine using Web Client Service
[
https://issues.apache.org/jira/browse/NIFI-13705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13705:
Status: Patch Available (was: In Progress)
> Refactor Stateless Engine using Web Client Service
> --
>
> Key: NIFI-13705
> URL: https://issues.apache.org/jira/browse/NIFI-13705
> Project: Apache NiFi
> Issue Type: Improvement
> Components: NiFi Stateless
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The NiFi Stateless Engine module currently uses OkHttp for retrieving Flow
> Definitions and Extension Bundles. With the implementation of
> {{nifi-web-client-api}} and refactoring of the {{nifi-web-client}} module
> using the Java HttpClient, use of OkHttp should be replaced with the NiFi Web
> Client libraries, removing the dependency on OkHttp.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13705) Refactor Stateless Engine using Web Client Service
David Handermann created NIFI-13705:
---
Summary: Refactor Stateless Engine using Web Client Service
Key: NIFI-13705
URL: https://issues.apache.org/jira/browse/NIFI-13705
Project: Apache NiFi
Issue Type: Improvement
Components: NiFi Stateless
Reporter: David Handermann
Assignee: David Handermann
The NiFi Stateless Engine module currently uses OkHttp for retrieving Flow
Definitions and Extension Bundles. With the implementation of
{{nifi-web-client-api}} and refactoring of the {{nifi-web-client}} module using
the Java HttpClient, use of OkHttp should be replaced with the NiFi Web Client
libraries, removing the dependency on OkHttp.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-13701) Remove deprecated property CACHE_SCHEMA from QueryRecord
[
https://issues.apache.org/jira/browse/NIFI-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann resolved NIFI-13701.
-
Fix Version/s: 2.0.0-M5
Resolution: Fixed
> Remove deprecated property CACHE_SCHEMA from QueryRecord
>
>
> Key: NIFI-13701
> URL: https://issues.apache.org/jira/browse/NIFI-13701
> Project: Apache NiFi
> Issue Type: Task
>Reporter: endzeit
>Assignee: endzeit
>Priority: Minor
> Fix For: 2.0.0-M5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The property CACHE_SCHEMA has been marked deprecated in QueryRecord.
> With the introduction of {{migrateProperties}} and in the light of NiFi 2.0,
> the removal of such as deprecated property sounds reasonable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-12852) Refactor TestRecordPath
[ https://issues.apache.org/jira/browse/NIFI-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-12852. - Fix Version/s: 2.0.0-M5 Resolution: Fixed > Refactor TestRecordPath > --- > > Key: NIFI-12852 > URL: https://issues.apache.org/jira/browse/NIFI-12852 > Project: Apache NiFi > Issue Type: Task >Reporter: endzeit >Assignee: endzeit >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The tests for RecordPath contain quite some duplication and can be tidied up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13702) Remove deprecated property STATE_UPDATE_INTERVAL from CaptureChangeMySQL
[ https://issues.apache.org/jira/browse/NIFI-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13702. - Fix Version/s: 2.0.0-M5 Resolution: Fixed > Remove deprecated property STATE_UPDATE_INTERVAL from CaptureChangeMySQL > > > Key: NIFI-13702 > URL: https://issues.apache.org/jira/browse/NIFI-13702 > Project: Apache NiFi > Issue Type: Task >Reporter: endzeit >Assignee: endzeit >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > The property STATE_UPDATE_INTERVAL has been marked deprecated in > CaptureChangeMySQL. > With the introduction of migrateProperties and in the light of NiFi 2.0, the > removal of such as deprecated property sounds reasonable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13578) Add schema branch name and schema version in ValidateRecord
[ https://issues.apache.org/jira/browse/NIFI-13578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13578: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Add schema branch name and schema version in ValidateRecord > --- > > Key: NIFI-13578 > URL: https://issues.apache.org/jira/browse/NIFI-13578 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M4 >Reporter: Julien G. >Assignee: Julien G. >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > In the ValidateRecord processor, we can provide a Schema Name or a Schema > Text but we can't providate a Schema Branch Name and a Schema Version in case > of using a Schema Name as it's possible in the differents RecordReaders and > RecordSetWriters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13578) Add schema branch name and schema version in ValidateRecord
[ https://issues.apache.org/jira/browse/NIFI-13578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13578: Affects Version/s: (was: 2.0.0-M4) > Add schema branch name and schema version in ValidateRecord > --- > > Key: NIFI-13578 > URL: https://issues.apache.org/jira/browse/NIFI-13578 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Julien G. >Assignee: Julien G. >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > In the ValidateRecord processor, we can provide a Schema Name or a Schema > Text but we can't providate a Schema Branch Name and a Schema Version in case > of using a Schema Name as it's possible in the differents RecordReaders and > RecordSetWriters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13664) Component bundle ID should be searchable
[ https://issues.apache.org/jira/browse/NIFI-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13664: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Component bundle ID should be searchable > > > Key: NIFI-13664 > URL: https://issues.apache.org/jira/browse/NIFI-13664 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > It would be nice to search and find all components located in a specific NAR. > For example, if I type "nifi-slack-nar" or partial "nifi-slack" or even just > "slack", I would like to see all processors and services in my flow that are > provided by that NAR. This can be useful for knowing when I can potentially > remove a NAR from my NiFi installation, especially for NARs that I have added > as extensions. > This feature is documented in the User Guide under the "Search Components in > DataFlow" section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12080) Add KV 2 Support to HashiCorp Vault Parameter Provider
[jira] [Updated] (NIFI-12080) HashiCorp Vault parameter context kv2 compatability.
[
https://issues.apache.org/jira/browse/NIFI-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12080:
Fix Version/s: 2.0.0-M5
Resolution: Fixed
Status: Resolved (was: Patch Available)
> HashiCorp Vault parameter context kv2 compatability.
>
>
> Key: NIFI-12080
> URL: https://issues.apache.org/jira/browse/NIFI-12080
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Environment: Tested on OpenShift 4.11 and local environment.
>Reporter: Robert D
>Assignee: Pierre Villard
>Priority: Minor
> Fix For: 2.0.0-M5
>
> Attachments: image-2023-09-18-15-54-55-187.png,
> image-2023-09-18-15-55-10-366.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When trying to use hashicorp vault with a kv2 backend I can successfully
> authenticate with vault but trying to use a parameter provider it can't list
> any secrets.
> I believe it's because {{KeyValueBackend.KV_1}} is hardcoded in the
> {{listKeyValueSecrets}} function instead of using the member variable
> {{{}keyValueBackend{}}}.
> The code can be seen
> [here|https://github.com/apache/nifi/blob/main/nifi-commons/nifi-hashicorp-vault/src/main/java/org/apache/nifi/vault/hashicorp/StandardHashiCorpVaultCommunicationService.java#L148].
> !image-2023-09-18-15-54-55-187.png!
>
> !image-2023-09-18-15-55-10-366.png!
>
> After that is changed to {{keyValueBackend}} another issue that comes up is
> that it can only list the top level secrets.
> This is because {{listKeyValueSecrets}} hardcodes the path to the [root
> path|https://github.com/apache/nifi/blob/main/nifi-commons/nifi-hashicorp-vault/src/main/java/org/apache/nifi/vault/hashicorp/StandardHashiCorpVaultCommunicationService.java#L149].
> For example if there is a secret under the path {{shared/test}} it is
> inaccessible.
> Adding the {{shared}} path to the Key/Value path parameter also doesn't fix
> it because Vault expects the metadata path after the kv engine.
> A valid path would be {{/kv/metadata/shared/?list=true}} adding {{shared }}to
> the Key/Value path makes a request to {{{}/kv/shared/metadata/?list=true{}}}.
> Adding a parameter to the {{listKeyValueSecrets}} function to specify the
> secret path fixes it.
>
> In the parameter provider it says it's for Key/Value version 1 secrets but
> after these changes I could use it with a kv2 backend. The only downside is
> that it can only get the latest version of the secret but that is good enough
> for my usecase.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12080) HashiCorp Vault parameter context kv2 compatability.
[
https://issues.apache.org/jira/browse/NIFI-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12080:
Affects Version/s: (was: 1.20.0)
> HashiCorp Vault parameter context kv2 compatability.
>
>
> Key: NIFI-12080
> URL: https://issues.apache.org/jira/browse/NIFI-12080
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Environment: Tested on OpenShift 4.11 and local environment.
>Reporter: Robert D
>Assignee: Pierre Villard
>Priority: Minor
> Attachments: image-2023-09-18-15-54-55-187.png,
> image-2023-09-18-15-55-10-366.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When trying to use hashicorp vault with a kv2 backend I can successfully
> authenticate with vault but trying to use a parameter provider it can't list
> any secrets.
> I believe it's because {{KeyValueBackend.KV_1}} is hardcoded in the
> {{listKeyValueSecrets}} function instead of using the member variable
> {{{}keyValueBackend{}}}.
> The code can be seen
> [here|https://github.com/apache/nifi/blob/main/nifi-commons/nifi-hashicorp-vault/src/main/java/org/apache/nifi/vault/hashicorp/StandardHashiCorpVaultCommunicationService.java#L148].
> !image-2023-09-18-15-54-55-187.png!
>
> !image-2023-09-18-15-55-10-366.png!
>
> After that is changed to {{keyValueBackend}} another issue that comes up is
> that it can only list the top level secrets.
> This is because {{listKeyValueSecrets}} hardcodes the path to the [root
> path|https://github.com/apache/nifi/blob/main/nifi-commons/nifi-hashicorp-vault/src/main/java/org/apache/nifi/vault/hashicorp/StandardHashiCorpVaultCommunicationService.java#L149].
> For example if there is a secret under the path {{shared/test}} it is
> inaccessible.
> Adding the {{shared}} path to the Key/Value path parameter also doesn't fix
> it because Vault expects the metadata path after the kv engine.
> A valid path would be {{/kv/metadata/shared/?list=true}} adding {{shared }}to
> the Key/Value path makes a request to {{{}/kv/shared/metadata/?list=true{}}}.
> Adding a parameter to the {{listKeyValueSecrets}} function to specify the
> secret path fixes it.
>
> In the parameter provider it says it's for Key/Value version 1 secrets but
> after these changes I could use it with a kv2 backend. The only downside is
> that it can only get the latest version of the secret but that is good enough
> for my usecase.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13695) Redirect issue when opening custom UI when running behind a proxy
[ https://issues.apache.org/jira/browse/NIFI-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13695: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Redirect issue when opening custom UI when running behind a proxy > - > > Key: NIFI-13695 > URL: https://issues.apache.org/jira/browse/NIFI-13695 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI, Extensions >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > When attempting to open a custom ui when running behind a proxy, jetty will > attempt to perform a redirect from "/proxy/path/context-path" to > "/context-path/". This redirect can result in the loss of the proxy path and > a resulting 404. This redirection can be avoided by including the trailing > slash. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13694) Remove MissingComponentsCheck from flow synchronization
[ https://issues.apache.org/jira/browse/NIFI-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13694: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Remove MissingComponentsCheck from flow synchronization > --- > > Key: NIFI-13694 > URL: https://issues.apache.org/jira/browse/NIFI-13694 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement the change described here: > https://cwiki.apache.org/confluence/display/NIFI/Remove+MissingComponentsCheck+from+Flow+Synchronization -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13688) NiFi can't start when Parameter Provider depends on controller service
[
https://issues.apache.org/jira/browse/NIFI-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877874#comment-17877874
]
David Handermann commented on NIFI-13688:
-
Thanks for the feedback [~pvillard], good catch on other providers. I submitted
a second pull request to address that behavior.
> NiFi can't start when Parameter Provider depends on controller service
> --
>
> Key: NIFI-13688
> URL: https://issues.apache.org/jira/browse/NIFI-13688
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Extensions
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M5
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Following NIFI-13560, it appears that NiFi can't start when a Parameter
> Provider is configured and this parameter provider depends on a controller
> service. In this case, fetching parameters will fail because the referenced
> controller service is still enabling. This is the case with the HashiCorp
> parameter provider.
> {code:java}
> 2024-08-28 15:17:15,752 ERROR [main] org.apache.nifi.web.server.JettyServer
> Failed to start Server
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Error fetching parameters for
> ParameterProvider[id=98c9d5c5-0191-1000-624e-84083ed8842e]: Cannot invoke
> method public abstract
> org.apache.nifi.vault.hashicorp.HashiCorpVaultCommunicationService
> org.apache.nifi.vault.hashicorp.HashiCorpVaultClientService.getHashiCorpVaultCommunicationService()
> on Controller Service with identifier 98cab32e-0191-1000-4aa7-fda19202e9c5
> because the Controller Service's State is currently ENABLING
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:465)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:229)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1800)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:817)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:538)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:1591)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.contextInitialized(ServletContextHandler.java:497)
> at
> org.eclipse.jetty.ee10.servlet.ServletHandler.initialize(ServletHandler.java:670)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.startContext(ServletContextHandler.java:1325)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startWebapp(WebAppContext.java:1342)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startContext(WebAppContext.java:1300)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.lambda$doStart$0(ServletContextHandler.java:1047)
> at
> org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1446)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.doStart(ServletContextHandler.java:1044)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:624)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Hand
[jira] [Updated] (NIFI-13688) NiFi can't start when Parameter Provider depends on controller service
[
https://issues.apache.org/jira/browse/NIFI-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13688:
Status: Patch Available (was: Reopened)
> NiFi can't start when Parameter Provider depends on controller service
> --
>
> Key: NIFI-13688
> URL: https://issues.apache.org/jira/browse/NIFI-13688
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Extensions
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M5
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Following NIFI-13560, it appears that NiFi can't start when a Parameter
> Provider is configured and this parameter provider depends on a controller
> service. In this case, fetching parameters will fail because the referenced
> controller service is still enabling. This is the case with the HashiCorp
> parameter provider.
> {code:java}
> 2024-08-28 15:17:15,752 ERROR [main] org.apache.nifi.web.server.JettyServer
> Failed to start Server
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Error fetching parameters for
> ParameterProvider[id=98c9d5c5-0191-1000-624e-84083ed8842e]: Cannot invoke
> method public abstract
> org.apache.nifi.vault.hashicorp.HashiCorpVaultCommunicationService
> org.apache.nifi.vault.hashicorp.HashiCorpVaultClientService.getHashiCorpVaultCommunicationService()
> on Controller Service with identifier 98cab32e-0191-1000-4aa7-fda19202e9c5
> because the Controller Service's State is currently ENABLING
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:465)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:229)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1800)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:817)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:538)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:1591)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.contextInitialized(ServletContextHandler.java:497)
> at
> org.eclipse.jetty.ee10.servlet.ServletHandler.initialize(ServletHandler.java:670)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.startContext(ServletContextHandler.java:1325)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startWebapp(WebAppContext.java:1342)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startContext(WebAppContext.java:1300)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.lambda$doStart$0(ServletContextHandler.java:1047)
> at
> org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1446)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.doStart(ServletContextHandler.java:1044)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:624)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at org.eclipse.jetty.server.Server.doStart(Server.java:565)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle
[jira] [Updated] (NIFI-13689) Add Watch Delay to Bootstrap Start Command
[
https://issues.apache.org/jira/browse/NIFI-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13689:
Status: Patch Available (was: Open)
> Add Watch Delay to Bootstrap Start Command
> --
>
> Key: NIFI-13689
> URL: https://issues.apache.org/jira/browse/NIFI-13689
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following the changes in NIFI-13665, in case NiFi cannot start successfully
> (flow not loading successfully for some reasons - like the example in
> NIFI-13688), then
> {code:java}
> nifi.sh start
> {code}
> will trigger an infinite loop of trying to start NiFi (until executing
> nifi.sh stop).
> It might be worth considering an improvement where a maximum number of
> attempts is configurable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13689) Add Watch Delay to Bootstrap Start Command
[
https://issues.apache.org/jira/browse/NIFI-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13689:
Summary: Add Watch Delay to Bootstrap Start Command (was: Add configurable
max attempts to avoid infinite starting loop for nifi.sh start)
> Add Watch Delay to Bootstrap Start Command
> --
>
> Key: NIFI-13689
> URL: https://issues.apache.org/jira/browse/NIFI-13689
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
>
> Following the changes in NIFI-13665, in case NiFi cannot start successfully
> (flow not loading successfully for some reasons - like the example in
> NIFI-13688), then
> {code:java}
> nifi.sh start
> {code}
> will trigger an infinite loop of trying to start NiFi (until executing
> nifi.sh stop).
> It might be worth considering an improvement where a maximum number of
> attempts is configurable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13686) Intermittent Unit Test Failure in TestListFile.testFilterAge()
[ https://issues.apache.org/jira/browse/NIFI-13686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13686: Fix Version/s: 1.28.0 > Intermittent Unit Test Failure in TestListFile.testFilterAge() > -- > > Key: NIFI-13686 > URL: https://issues.apache.org/jira/browse/NIFI-13686 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.27.0, 2.0.0-M4 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Major > Fix For: 1.28.0, 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > This unit test only works when execution speed is very fast. If there is more > than a small fraction of a second delay while the unit test is running, then > it intermittently gives a false assertion failure even though the > ListFile.java class is unchanged and correct. I will make the unit test more > robust by making larger time differences between the test objects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13692) ResizeImage fails to catch exceptions in many cases
[ https://issues.apache.org/jira/browse/NIFI-13692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13692. - Resolution: Fixed > ResizeImage fails to catch exceptions in many cases > --- > > Key: NIFI-13692 > URL: https://issues.apache.org/jira/browse/NIFI-13692 > Project: Apache NiFi > Issue Type: Bug >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Fix For: 1.28.0, 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > After heavily using ResizeImage, we have discovered a number of edge cases > where invalid data would cause exceptions that pass through the try/catch > blocks. The solution that we found was to widen the catch blocks to just > Exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13659) Issue migrating properties during rolling upgrade
[ https://issues.apache.org/jira/browse/NIFI-13659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13659: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Issue migrating properties during rolling upgrade > - > > Key: NIFI-13659 > URL: https://issues.apache.org/jira/browse/NIFI-13659 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 2.0.0-M4 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > The following scenario causes property migration to not work as expected: > * Multi node cluster, 3 nodes running version X > * A component from version Y has implemented migrateProperties, say a > processor converts a property to a controller service for example > * Start performing a rolling upgrade... > * Stop node 3, upgrade libs, start node 3 > * Node 3 loads flow from disk and converts old properties to new (makes new > CS) > * Node 3 connects to cluster and gets the coordinator's flow which has this > component with it's old config > * It runs flow synchronization which undoes the migration and puts the > config back how it was before, which now makes the processors on node 3 > invalid > * Proceed with the remaining nodes and they will all end up in the same state > * Only way to fully correct is for all nodes to go down at the same time so > they can all migrate before any node joins the cluster > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13690) Upgrade AWS SDK to 2.27.14 and other dependencies
[ https://issues.apache.org/jira/browse/NIFI-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13690: Fix Version/s: 1.28.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade AWS SDK to 2.27.14 and other dependencies > - > > Key: NIFI-13690 > URL: https://issues.apache.org/jira/browse/NIFI-13690 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.28.0, 2.0.0-M5 > > Time Spent: 1h > Remaining Estimate: 0h > > ch.qos.logback 1.5.6 1.5.7 > com.aayushatharva.brotli4j1.16.0 1.17.0 > com.amazonaws 1.12.767 1.12.770 > com.h2database 2.3.230 2.3.232 > commons-cli 1.8.0 1.9.0 > io.dropwizard.metrics metrics-core/metrics-jvm 4.2.26 4.2.27 > io.fabric8 6.13.2 6.13.3 > io.projectreactor.netty 1.1.21 1.1.22 > io.swagger.core.v3 2.2.22 2.2.23 > org.apache.commons commons-compress 1.27.0 1.27.1 > org.mockito 5.12.0 5.13.0 > software.amazon.awssdk 2.27.1 2.27.14 > com.slack.api bolt-socket-mode 1.40.3 1.42.0 > io.projectreactor core/test 3.6.8 3.6.9 > org.apache.iceberg 1.6.0 1.6.1 > org.flywaydb 10.17.0 10.17.2 > org.kohsuke github-api 1.323 1.324 > org.postgresql 42.7.3 42.7.4 > org.springframework.integration 6.3.2 6.3.3 > org.springframework.retry 2.0.7 2.0.8 > org.springframework.vault 3.1.1 3.1.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13688) NiFi can't start when Parameter Provider depends on controller service
[
https://issues.apache.org/jira/browse/NIFI-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13688:
Status: Patch Available (was: In Progress)
> NiFi can't start when Parameter Provider depends on controller service
> --
>
> Key: NIFI-13688
> URL: https://issues.apache.org/jira/browse/NIFI-13688
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Extensions
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following NIFI-13560, it appears that NiFi can't start when a Parameter
> Provider is configured and this parameter provider depends on a controller
> service. In this case, fetching parameters will fail because the referenced
> controller service is still enabling. This is the case with the HashiCorp
> parameter provider.
> {code:java}
> 2024-08-28 15:17:15,752 ERROR [main] org.apache.nifi.web.server.JettyServer
> Failed to start Server
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Error fetching parameters for
> ParameterProvider[id=98c9d5c5-0191-1000-624e-84083ed8842e]: Cannot invoke
> method public abstract
> org.apache.nifi.vault.hashicorp.HashiCorpVaultCommunicationService
> org.apache.nifi.vault.hashicorp.HashiCorpVaultClientService.getHashiCorpVaultCommunicationService()
> on Controller Service with identifier 98cab32e-0191-1000-4aa7-fda19202e9c5
> because the Controller Service's State is currently ENABLING
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:465)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:229)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1800)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:817)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:538)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:1591)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.contextInitialized(ServletContextHandler.java:497)
> at
> org.eclipse.jetty.ee10.servlet.ServletHandler.initialize(ServletHandler.java:670)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.startContext(ServletContextHandler.java:1325)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startWebapp(WebAppContext.java:1342)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startContext(WebAppContext.java:1300)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.lambda$doStart$0(ServletContextHandler.java:1047)
> at
> org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1446)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.doStart(ServletContextHandler.java:1044)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:624)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at org.eclipse.jetty.server.Server.doStart(Server.java:565)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:9
[jira] [Updated] (NIFI-13690) Upgrade AWS SDK to 2.27.14 and other dependencies
[ https://issues.apache.org/jira/browse/NIFI-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13690: Summary: Upgrade AWS SDK to 2.27.14 and other dependencies (was: Update various dependencies) > Upgrade AWS SDK to 2.27.14 and other dependencies > - > > Key: NIFI-13690 > URL: https://issues.apache.org/jira/browse/NIFI-13690 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ch.qos.logback 1.5.6 1.5.7 > com.aayushatharva.brotli4j1.16.0 1.17.0 > com.amazonaws 1.12.767 1.12.770 > com.h2database 2.3.230 2.3.232 > commons-cli 1.8.0 1.9.0 > io.dropwizard.metrics metrics-core/metrics-jvm 4.2.26 4.2.27 > io.fabric8 6.13.2 6.13.3 > io.projectreactor.netty 1.1.21 1.1.22 > io.swagger.core.v3 2.2.22 2.2.23 > org.apache.commons commons-compress 1.27.0 1.27.1 > org.mockito 5.12.0 5.13.0 > software.amazon.awssdk 2.27.1 2.27.14 > com.slack.api bolt-socket-mode 1.40.3 1.42.0 > io.projectreactor core/test 3.6.8 3.6.9 > org.apache.iceberg 1.6.0 1.6.1 > org.flywaydb 10.17.0 10.17.2 > org.kohsuke github-api 1.323 1.324 > org.postgresql 42.7.3 42.7.4 > org.springframework.integration 6.3.2 6.3.3 > org.springframework.retry 2.0.7 2.0.8 > org.springframework.vault 3.1.1 3.1.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13690) Update various dependencies
[ https://issues.apache.org/jira/browse/NIFI-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13690: Issue Type: Improvement (was: Bug) > Update various dependencies > --- > > Key: NIFI-13690 > URL: https://issues.apache.org/jira/browse/NIFI-13690 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ch.qos.logback 1.5.6 1.5.7 > com.aayushatharva.brotli4j1.16.0 1.17.0 > com.amazonaws 1.12.767 1.12.770 > com.h2database 2.3.230 2.3.232 > commons-cli 1.8.0 1.9.0 > io.dropwizard.metrics metrics-core/metrics-jvm 4.2.26 4.2.27 > io.fabric8 6.13.2 6.13.3 > io.projectreactor.netty 1.1.21 1.1.22 > io.swagger.core.v3 2.2.22 2.2.23 > org.apache.commons commons-compress 1.27.0 1.27.1 > org.mockito 5.12.0 5.13.0 > software.amazon.awssdk 2.27.1 2.27.14 > com.slack.api bolt-socket-mode 1.40.3 1.42.0 > io.projectreactor core/test 3.6.8 3.6.9 > org.apache.iceberg 1.6.0 1.6.1 > org.flywaydb 10.17.0 10.17.2 > org.kohsuke github-api 1.323 1.324 > org.postgresql 42.7.3 42.7.4 > org.springframework.integration 6.3.2 6.3.3 > org.springframework.retry 2.0.7 2.0.8 > org.springframework.vault 3.1.1 3.1.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-13689) Add configurable max attempts to avoid infinite starting loop for nifi.sh start
[
https://issues.apache.org/jira/browse/NIFI-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann reassigned NIFI-13689:
---
Assignee: David Handermann
> Add configurable max attempts to avoid infinite starting loop for nifi.sh
> start
> ---
>
> Key: NIFI-13689
> URL: https://issues.apache.org/jira/browse/NIFI-13689
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
>
> Following the changes in NIFI-13665, in case NiFi cannot start successfully
> (flow not loading successfully for some reasons - like the example in
> NIFI-13688), then
> {code:java}
> nifi.sh start
> {code}
> will trigger an infinite loop of trying to start NiFi (until executing
> nifi.sh stop).
> It might be worth considering an improvement where a maximum number of
> attempts is configurable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (NIFI-13688) NiFi can't start when Parameter Provider depends on controller service
[
https://issues.apache.org/jira/browse/NIFI-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann reassigned NIFI-13688:
---
Assignee: David Handermann
> NiFi can't start when Parameter Provider depends on controller service
> --
>
> Key: NIFI-13688
> URL: https://issues.apache.org/jira/browse/NIFI-13688
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Extensions
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
>
> Following NIFI-13560, it appears that NiFi can't start when a Parameter
> Provider is configured and this parameter provider depends on a controller
> service. In this case, fetching parameters will fail because the referenced
> controller service is still enabling. This is the case with the HashiCorp
> parameter provider.
> {code:java}
> 2024-08-28 15:17:15,752 ERROR [main] org.apache.nifi.web.server.JettyServer
> Failed to start Server
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Error fetching parameters for
> ParameterProvider[id=98c9d5c5-0191-1000-624e-84083ed8842e]: Cannot invoke
> method public abstract
> org.apache.nifi.vault.hashicorp.HashiCorpVaultCommunicationService
> org.apache.nifi.vault.hashicorp.HashiCorpVaultClientService.getHashiCorpVaultCommunicationService()
> on Controller Service with identifier 98cab32e-0191-1000-4aa7-fda19202e9c5
> because the Controller Service's State is currently ENABLING
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:465)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:229)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1800)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:817)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:538)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:1591)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.contextInitialized(ServletContextHandler.java:497)
> at
> org.eclipse.jetty.ee10.servlet.ServletHandler.initialize(ServletHandler.java:670)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.startContext(ServletContextHandler.java:1325)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startWebapp(WebAppContext.java:1342)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startContext(WebAppContext.java:1300)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.lambda$doStart$0(ServletContextHandler.java:1047)
> at
> org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1446)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.doStart(ServletContextHandler.java:1044)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:624)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at org.eclipse.jetty.server.Server.doStart(Server.java:565)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at org.apache.nifi.web.server.JettyServer.start(JettyS
[jira] [Commented] (NIFI-13688) NiFi can't start when Parameter Provider depends on controller service
[
https://issues.apache.org/jira/browse/NIFI-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877416#comment-17877416
]
David Handermann commented on NIFI-13688:
-
Thanks for describing the issue [~pvillard], I will take a closer look at the
behavior.
> NiFi can't start when Parameter Provider depends on controller service
> --
>
> Key: NIFI-13688
> URL: https://issues.apache.org/jira/browse/NIFI-13688
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Extensions
>Affects Versions: 2.0.0-M5
>Reporter: Pierre Villard
>Assignee: David Handermann
>Priority: Major
>
> Following NIFI-13560, it appears that NiFi can't start when a Parameter
> Provider is configured and this parameter provider depends on a controller
> service. In this case, fetching parameters will fail because the referenced
> controller service is still enabling. This is the case with the HashiCorp
> parameter provider.
> {code:java}
> 2024-08-28 15:17:15,752 ERROR [main] org.apache.nifi.web.server.JettyServer
> Failed to start Server
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Error fetching parameters for
> ParameterProvider[id=98c9d5c5-0191-1000-624e-84083ed8842e]: Cannot invoke
> method public abstract
> org.apache.nifi.vault.hashicorp.HashiCorpVaultCommunicationService
> org.apache.nifi.vault.hashicorp.HashiCorpVaultClientService.getHashiCorpVaultCommunicationService()
> on Controller Service with identifier 98cab32e-0191-1000-4aa7-fda19202e9c5
> because the Controller Service's State is currently ENABLING
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:465)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:229)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1800)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:817)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:538)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:1591)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.contextInitialized(ServletContextHandler.java:497)
> at
> org.eclipse.jetty.ee10.servlet.ServletHandler.initialize(ServletHandler.java:670)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.startContext(ServletContextHandler.java:1325)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startWebapp(WebAppContext.java:1342)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.startContext(WebAppContext.java:1300)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.lambda$doStart$0(ServletContextHandler.java:1047)
> at
> org.eclipse.jetty.server.handler.ContextHandler$ScopedContext.call(ContextHandler.java:1446)
> at
> org.eclipse.jetty.ee10.servlet.ServletContextHandler.doStart(ServletContextHandler.java:1044)
> at
> org.eclipse.jetty.ee10.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:624)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:120)
> at org.eclipse.jetty.server.Handler$Abstract.doStart(Handler.java:491)
> at org.eclipse.jetty.server.Server.doStart(Server.java:565)
> at
> org.eclipse.jetty.util.component.Ab
[jira] [Updated] (NIFI-13685) Upgrade Spring to 6.1.12 and Spring Security to 6.3.3
[ https://issues.apache.org/jira/browse/NIFI-13685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13685: Status: Patch Available (was: Open) > Upgrade Spring to 6.1.12 and Spring Security to 6.3.3 > - > > Key: NIFI-13685 > URL: https://issues.apache.org/jira/browse/NIFI-13685 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Spring Framework dependencies should be upgraded to > [6.1.12|https://github.com/spring-projects/spring-framework/releases/tag/v6.1.12] > and Spring Security dependencies should be upgraded to > [6.3.3|https://github.com/spring-projects/spring-security/releases/tag/6.3.3]. > Spring Boot for NiFi Registry should also be upgraded to > [3.3.3|https://github.com/spring-projects/spring-boot/releases/tag/v3.3.3]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13685) Upgrade Spring to 6.1.12 and Spring Security to 6.3.3
David Handermann created NIFI-13685: --- Summary: Upgrade Spring to 6.1.12 and Spring Security to 6.3.3 Key: NIFI-13685 URL: https://issues.apache.org/jira/browse/NIFI-13685 Project: Apache NiFi Issue Type: Improvement Components: Core Framework, NiFi Registry Reporter: David Handermann Assignee: David Handermann Spring Framework dependencies should be upgraded to [6.1.12|https://github.com/spring-projects/spring-framework/releases/tag/v6.1.12] and Spring Security dependencies should be upgraded to [6.3.3|https://github.com/spring-projects/spring-security/releases/tag/6.3.3]. Spring Boot for NiFi Registry should also be upgraded to [3.3.3|https://github.com/spring-projects/spring-boot/releases/tag/v3.3.3]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13681) Align Cluster Environment Variables in Docker with Property Names
[ https://issues.apache.org/jira/browse/NIFI-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13681. - Fix Version/s: 2.0.0-M5 Assignee: Malthe Borch Resolution: Fixed > Align Cluster Environment Variables in Docker with Property Names > - > > Key: NIFI-13681 > URL: https://issues.apache.org/jira/browse/NIFI-13681 > Project: Apache NiFi > Issue Type: Bug >Reporter: Malthe Borch >Assignee: Malthe Borch >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > The Kubernetes-related coordination settings draw on environment variables > that do not accurately reflect their property names, leading to confusion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13681) Align Cluster Environment Variables in Docker with Property Names
[ https://issues.apache.org/jira/browse/NIFI-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13681: Summary: Align Cluster Environment Variables in Docker with Property Names (was: Fix Kubernetes coordination environment variable names) > Align Cluster Environment Variables in Docker with Property Names > - > > Key: NIFI-13681 > URL: https://issues.apache.org/jira/browse/NIFI-13681 > Project: Apache NiFi > Issue Type: Bug >Reporter: Malthe Borch >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The Kubernetes-related coordination settings draw on environment variables > that do not accurately reflect their property names, leading to confusion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13684) Set Runtime Cluster Status Response Code based on Connection
[
https://issues.apache.org/jira/browse/NIFI-13684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13684:
Status: Patch Available (was: Open)
> Set Runtime Cluster Status Response Code based on Connection
>
>
> Key: NIFI-13684
> URL: https://issues.apache.org/jira/browse/NIFI-13684
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Recent improvements to the bootstrap and runtime process handling including
> the introduction of an HTTP management server to return application health
> and status.
> The {{/health/cluster}} path returns different status values based on cluster
> connection status, but the initial implementation returns HTTP 200 regardless
> of the connection status. This behavior should be changed to return more
> specific HTTP response codes for unhealthy connection states, such that
> connected and connecting status continue to return HTTP 200, but other states
> return an error code of HTTP 503.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13684) Set Runtime Cluster Status Response Code based on Connection
David Handermann created NIFI-13684:
---
Summary: Set Runtime Cluster Status Response Code based on
Connection
Key: NIFI-13684
URL: https://issues.apache.org/jira/browse/NIFI-13684
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Reporter: David Handermann
Assignee: David Handermann
Recent improvements to the bootstrap and runtime process handling including the
introduction of an HTTP management server to return application health and
status.
The {{/health/cluster}} path returns different status values based on cluster
connection status, but the initial implementation returns HTTP 200 regardless
of the connection status. This behavior should be changed to return more
specific HTTP response codes for unhealthy connection states, such that
connected and connecting status continue to return HTTP 200, but other states
return an error code of HTTP 503.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13675) Fix tooltip for Parameter description
[ https://issues.apache.org/jira/browse/NIFI-13675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13675: Resolution: Fixed Status: Resolved (was: Patch Available) > Fix tooltip for Parameter description > - > > Key: NIFI-13675 > URL: https://issues.apache.org/jira/browse/NIFI-13675 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.27.0 >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.28.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13677) Remove install command from nifi.sh
[ https://issues.apache.org/jira/browse/NIFI-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13677: Status: Patch Available (was: Open) > Remove install command from nifi.sh > --- > > Key: NIFI-13677 > URL: https://issues.apache.org/jira/browse/NIFI-13677 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The nifi.sh script includes an install command to create symbolic links on > Linux systems to run the application as a system service. With the removal of > support for RPM packaging in earlier versions of NiFi, and with the variety > of service initialization approaches across Linux distributions, the install > command should be removed. Container packaging is a supported convenience > build, and custom distributions outside of the project could maintain > convenience binary builds if necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13677) Remove install command from nifi.sh
David Handermann created NIFI-13677: --- Summary: Remove install command from nifi.sh Key: NIFI-13677 URL: https://issues.apache.org/jira/browse/NIFI-13677 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: David Handermann Assignee: David Handermann The nifi.sh script includes an install command to create symbolic links on Linux systems to run the application as a system service. With the removal of support for RPM packaging in earlier versions of NiFi, and with the variety of service initialization approaches across Linux distributions, the install command should be removed. Container packaging is a supported convenience build, and custom distributions outside of the project could maintain convenience binary builds if necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13665) Refactor Bootstrap Process Implementation
[
https://issues.apache.org/jira/browse/NIFI-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13665:
Status: Patch Available (was: In Progress)
> Refactor Bootstrap Process Implementation
> -
>
> Key: NIFI-13665
> URL: https://issues.apache.org/jira/browse/NIFI-13665
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current NiFi startup process includes the {{nifi-bootstrap}} module and
> the {{nifi-runtime}} module, together with the {{nifi-resources}} module,
> which provides the shell scripts for interacting with bootstrap commands.
> The existing architecture has remained relatively unchanged since the initial
> implementation, consisting of a long-running Java process to start and
> monitor the application process. Process communication takes place using a
> custom TCP socket protocol, with each process listening for connections and
> commands on a local address.
> Java 9 and following expanded platform capabilities to support greater
> control over operating system processes through the
> [ProcessHandle|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ProcessHandle.html]
> interface and related components. The ProcessHandle interface supports
> features such as enumerating processes and reading command arguments. Java 11
> introduced an
> [HttpClient|https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html],
> providing a number of improvements over the historical
> {{{}HttpURLConnection{}}}.
> With these language improvements, the NiFi bootstrap process should be
> refactored using improved process control and HTTP for process communication.
> This approach should eliminate the need for custom socket protocol handling
> while maintaining existing capabilities such as process health, diagnostics,
> and decommissioning cluster nodes.
> The NiFi process control scripts nifi.sh and nifi.cmd should remain
> relatively unchanged, minimizing the user-facing impact. Although the NiFi
> bootstrap process should continue support existing use cases for long-running
> process monitoring, refactoring should also support the option to run the
> NiFi application without a long-running monitor. This run strategy should
> provide a better fit with containerized deployments that have first-class
> process monitoring.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12991) Can't switch to Standard execution engine if there is a child process group inheriting
[ https://issues.apache.org/jira/browse/NIFI-12991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12991: Resolution: Fixed Status: Resolved (was: Patch Available) > Can't switch to Standard execution engine if there is a child process group > inheriting > --- > > Key: NIFI-12991 > URL: https://issues.apache.org/jira/browse/NIFI-12991 > Project: Apache NiFi > Issue Type: Bug > Components: NiFi Stateless >Affects Versions: 2.0.0-M2 >Reporter: Gabriel Orstadius-Bui >Assignee: Mark Payne >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > If process group "A" has child process group "B" which inherits its parent's > (A's) execution engine, switching A's execution engine to Stateless is no > problem. > However, thereafter switching A's execution engine back to Standard leads to > this error message being shown: > "A Process Group using the Standard Engine may not be the child of a Process > Group using the Stateless Engine. Cannot set Execution Engine of > StandardProcessGroup[identifier=f406cf3a-018d-1000-42a3-6a708991aab7,name=B] > to Standard because it is a child of > StandardProcessGroup[identifier=e574e59b-018d-1000-530e-0a9db5c39a6e,name=A]" > It seems as if NiFi in this case first tries to switch B's execution engine > to standard, which is not allowed because A is still using the Standard > execution engine. In this case, NiFi should instead first change A's > execution engine and thereafter B's. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13665) Refactor Bootstrap Process Implementation
[
https://issues.apache.org/jira/browse/NIFI-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13665:
Description:
The current NiFi startup process includes the {{nifi-bootstrap}} module and the
{{nifi-runtime}} module, together with the {{nifi-resources}} module, which
provides the shell scripts for interacting with bootstrap commands.
The existing architecture has remained relatively unchanged since the initial
implementation, consisting of a long-running Java process to start and monitor
the application process. Process communication takes place using a custom TCP
socket protocol, with each process listening for connections and commands on a
local address.
Java 9 and following expanded platform capabilities to support greater control
over operating system processes through the
[ProcessHandle|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ProcessHandle.html]
interface and related components. The ProcessHandle interface supports
features such as enumerating processes and reading command arguments. Java 11
introduced an
[HttpClient|https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html],
providing a number of improvements over the historical
{{{}HttpURLConnection{}}}.
With these language improvements, the NiFi bootstrap process should be
refactored using improved process control and HTTP for process communication.
This approach should eliminate the need for custom socket protocol handling
while maintaining existing capabilities such as process health, diagnostics,
and decommissioning cluster nodes.
The NiFi process control scripts nifi.sh and nifi.cmd should remain relatively
unchanged, minimizing the user-facing impact. Although the NiFi bootstrap
process should continue support existing use cases for long-running process
monitoring, refactoring should also support the option to run the NiFi
application without a long-running monitor. This run strategy should provide a
better fit with containerized deployments that have first-class process
monitoring.
was:
The current NiFi startup process includes the {{nifi-bootstrap}} module and the
{{nifi-runtime}} module, together with the {{nifi-resources}} module, which
provides the shell scripts for interacting with bootstrap commands.
The existing architecture has remained relatively unchanged since the initial
implementation, consisting of a long-running Java process to start and monitor
the application process. Process communication takes place using a custom TCP
socket protocol, which each process listening for connections and commands on a
local address.
Java 9 and following expanded platform capabilities to support greater control
over operating system processes through the
[ProcessHandle|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ProcessHandle.html]
interface and related components. The ProcessHandle interface supports
features such as enumerating processes and reading command arguments. Java 11
introduced an
[HttpClient|https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html],
providing a number of improvements over the historical
{{{}HttpURLConnection{}}}.
With these language improvements, the NiFi bootstrap process should be
refactored using improved process control and HTTP for process communication.
This approach should eliminate the need for custom socket protocol handling
while maintaining existing capabilities such as process health, diagnostics,
and decommissioning cluster nodes.
The NiFi process control scripts nifi.sh and nifi.cmd should remain relatively
unchanged, minimizing the user-facing impact. Although the NiFi bootstrap
process should continue support existing use cases for long-running process
monitoring, refactoring should also support the option to run the NiFi
application without a long-running monitor. This run strategy should provide a
better fit with containerized deployments that have first-class process
monitoring.
> Refactor Bootstrap Process Implementation
> -
>
> Key: NIFI-13665
> URL: https://issues.apache.org/jira/browse/NIFI-13665
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
>
> The current NiFi startup process includes the {{nifi-bootstrap}} module and
> the {{nifi-runtime}} module, together with the {{nifi-resources}} module,
> which provides the shell scripts for interacting with bootstrap commands.
> The existing architecture has remained relatively unchanged since the initial
> implementation, consisting of a long-running Java process to start and
> monitor the application process. Pr
[jira] [Created] (NIFI-13665) Refactor Bootstrap Process Implementation
David Handermann created NIFI-13665:
---
Summary: Refactor Bootstrap Process Implementation
Key: NIFI-13665
URL: https://issues.apache.org/jira/browse/NIFI-13665
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Reporter: David Handermann
Assignee: David Handermann
The current NiFi startup process includes the {{nifi-bootstrap}} module and the
{{nifi-runtime}} module, together with the {{nifi-resources}} module, which
provides the shell scripts for interacting with bootstrap commands.
The existing architecture has remained relatively unchanged since the initial
implementation, consisting of a long-running Java process to start and monitor
the application process. Process communication takes place using a custom TCP
socket protocol, which each process listening for connections and commands on a
local address.
Java 9 and following expanded platform capabilities to support greater control
over operating system processes through the
[ProcessHandle|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ProcessHandle.html]
interface and related components. The ProcessHandle interface supports
features such as enumerating processes and reading command arguments. Java 11
introduced an
[HttpClient|https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html],
providing a number of improvements over the historical
{{{}HttpURLConnection{}}}.
With these language improvements, the NiFi bootstrap process should be
refactored using improved process control and HTTP for process communication.
This approach should eliminate the need for custom socket protocol handling
while maintaining existing capabilities such as process health, diagnostics,
and decommissioning cluster nodes.
The NiFi process control scripts nifi.sh and nifi.cmd should remain relatively
unchanged, minimizing the user-facing impact. Although the NiFi bootstrap
process should continue support existing use cases for long-running process
monitoring, refactoring should also support the option to run the NiFi
application without a long-running monitor. This run strategy should provide a
better fit with containerized deployments that have first-class process
monitoring.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13661) Add Multipart Form-Data Handling to web-client-api
[ https://issues.apache.org/jira/browse/NIFI-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13661: Status: Patch Available (was: Open) > Add Multipart Form-Data Handling to web-client-api > -- > > Key: NIFI-13661 > URL: https://issues.apache.org/jira/browse/NIFI-13661 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > [RFC 7578|https://www.rfc-editor.org/rfc/rfc7578] Describes handling for > multipart/form-data over HTTP, which is a request format often used to pass a > combination of files and parameter values. The format consists of the > Content-Disposition request header with a boundary indicator, and one or more > request sections, delimited using the boundary indicator. > Libraries such as OkHttp provide wrappers around this format, and the > nifi-web-client-api library should include support for constructing an HTTP > request using a similar strategy. In order to support various use cases, the > implementation should support either byte array inputs or streams, enabling > requests with large sources without consuming large amounts of memory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13630) Avro MAP type doesn't work with the PutBigQuery processor
[
https://issues.apache.org/jira/browse/NIFI-13630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13630:
Fix Version/s: 2.0.0-M5
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Avro MAP type doesn't work with the PutBigQuery processor
> -
>
> Key: NIFI-13630
> URL: https://issues.apache.org/jira/browse/NIFI-13630
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Julien G.
>Assignee: Julien G.
>Priority: Major
> Fix For: 2.0.0-M5
>
> Attachments: bigquery.json, schema.avsc
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When writing a record with the map to BigQuery using the PutBigQuery
> processor. The processor fails to generate the Proto message with the
> following error. You can find the avro schema and the BigQuery schema
> attached to the issue.
> {code:java}
> 2024-08-05 14:51:23,493 ERROR [Timer-Driven Process Thread-10]
> o.a.n.p.gcp.bigquery.PutBigQuery
> PutBigQuery[id=f5225062-a703-1f89--ea37b541] Stream processing failed
> java.lang.ClassCastException: class java.util.HashMap cannot be cast to class
> java.util.Collection (java.util.HashMap and java.util.Collection are in
> module java.base of loader 'bootstrap')at
> org.apache.nifi.processors.gcp.bigquery.proto.ProtoUtils.createMessage(ProtoUtils.java:49)
>
> at
> org.apache.nifi.processors.gcp.bigquery.proto.ProtoUtils.createMessage(ProtoUtils.java:52)
>
> at
> org.apache.nifi.processors.gcp.bigquery.PutBigQuery.recordToProtoMessage(PutBigQuery.java:289)
>
> at
> org.apache.nifi.processors.gcp.bigquery.PutBigQuery.writeRecordsToStream(PutBigQuery.java:263)
>
> at
> org.apache.nifi.processors.gcp.bigquery.PutBigQuery.onTrigger(PutBigQuery.java:247)
>
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1361)
>
> at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:247)
>
>at
> org.apache.nifi.controller.scheduling.AbstractTimeBasedSchedulingAgent.lambda$doScheduleOnce$0(AbstractTimeBasedSchedulingAgent.java:59)
> at
> org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
>
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>
> at
> java.base/java.util.concurrent.FutureTask.run(Unknown Source)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.base/java.lang.Thread.run(Unknown Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13642) Add 'Delete Keys' property to `PutDatabaseRecord` processor
[ https://issues.apache.org/jira/browse/NIFI-13642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13642: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Add 'Delete Keys' property to `PutDatabaseRecord` processor > --- > > Key: NIFI-13642 > URL: https://issues.apache.org/jira/browse/NIFI-13642 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M5 >Reporter: Rajmund Takacs >Assignee: Rajmund Takacs >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 10m > Remaining Estimate: 0h > > Some database drivers do not report the primary keys, and key nullability in > DMD, so the DELETE statement fails. > Examples for this are Phoenix and Impala. > Letting users to define the key columns themselves works this problem around, > when needed. > Similar property already exists for UPDATE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12411) PublishAMQP: Put header values from attributes by matching Regex
[ https://issues.apache.org/jira/browse/NIFI-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-12411. - Fix Version/s: 2.0.0-M5 Resolution: Fixed > PublishAMQP: Put header values from attributes by matching Regex > > > Key: NIFI-12411 > URL: https://issues.apache.org/jira/browse/NIFI-12411 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.23.2 >Reporter: Umar Hussain >Assignee: Umar Hussain >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 2.5h > Remaining Estimate: 0h > > The focus of this ticket is to extend the PublishAMQP processor so that it > can take FlowFile attributes by matching a Regex and then put these > attributes as `headers` map in AMQP message. > Default behavior of the processor stays the same as version `1.23.2` i.e. it > will by default read headers from `amq$headers` attribute and put them in the > AMQP message. > For Regex based match of attributes, a new property is needed which can > switch between reading from `amq$headers` or put attributes matching the > Regex, or it can read from both sources. > In case headers can be read from both sources, an additional property is > needed to set precedence of the source so that if a key is found in both > sources, which will be set in output. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13661) Add Multipart Form-Data Handling to web-client-api
David Handermann created NIFI-13661: --- Summary: Add Multipart Form-Data Handling to web-client-api Key: NIFI-13661 URL: https://issues.apache.org/jira/browse/NIFI-13661 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Reporter: David Handermann Assignee: David Handermann [RFC 7578|https://www.rfc-editor.org/rfc/rfc7578] Describes handling for multipart/form-data over HTTP, which is a request format often used to pass a combination of files and parameter values. The format consists of the Content-Disposition request header with a boundary indicator, and one or more request sections, delimited using the boundary indicator. Libraries such as OkHttp provide wrappers around this format, and the nifi-web-client-api library should include support for constructing an HTTP request using a similar strategy. In order to support various use cases, the implementation should support either byte array inputs or streams, enabling requests with large sources without consuming large amounts of memory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13430) Add CopyS3Object and GetS3ObjectMetadata for AWS
[ https://issues.apache.org/jira/browse/NIFI-13430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13430: Fix Version/s: 1.28.0 > Add CopyS3Object and GetS3ObjectMetadata for AWS > > > Key: NIFI-13430 > URL: https://issues.apache.org/jira/browse/NIFI-13430 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Fix For: 1.28.0, 2.0.0-M5 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > This ticket will add CopyS3Object, a processor that will use the Copy API to > have S3 directly execute a copy without downloading the file and > ExistsS3Object which uses a light weight API that doesn't attempt a file > download in order to check the existence of a file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12709) UnpackContent should save attributes from the zip entries as flowfile attributes where possible
[ https://issues.apache.org/jira/browse/NIFI-12709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12709: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > UnpackContent should save attributes from the zip entries as flowfile > attributes where possible > --- > > Key: NIFI-12709 > URL: https://issues.apache.org/jira/browse/NIFI-12709 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joe Witt >Assignee: Daniel Stieglitz >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 40m > Remaining Estimate: 0h > > In an email from Jan 31st to users list titled 'ExecuteStreamCommand failing > to unzip incoming flowfiles' > Issue is that UnpackContent doesn't capture much useful metadata. The user > wants last modified date which is easily available, but also creator, > creation time, and owner which are less obviously avaialble at least not > consistently. But there is a concept of extra fields we can extract metadata > from. We have those same fields available from Tar files so it is natural > users would also want these. Given their names aren't standard though I see > why Tar is the only one we currently say we support pulling those for. If we > at least captured the metadata then flow builders can use it in their flows > as they wish whereas right now we dont expose that information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13651) Move extensions to nifi framework to its own folder 'nifi-framework-extensions'
[ https://issues.apache.org/jira/browse/NIFI-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13651. - Resolution: Fixed > Move extensions to nifi framework to its own folder > 'nifi-framework-extensions' > --- > > Key: NIFI-13651 > URL: https://issues.apache.org/jira/browse/NIFI-13651 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13532) Flow Configuration History loses its ability to sort after filter is applied
[ https://issues.apache.org/jira/browse/NIFI-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13532: Status: Patch Available (was: Open) > Flow Configuration History loses its ability to sort after filter is applied > > > Key: NIFI-13532 > URL: https://issues.apache.org/jira/browse/NIFI-13532 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Affects Versions: 2.0.0-M4 >Reporter: Michael W Moser >Assignee: David Handermann >Priority: Minor > Attachments: Screenshot 2024-07-10 at 5.53.07 PM.png, Screenshot > 2024-07-10 at 5.53.20 PM.png, image-2024-07-11-08-42-21-810.png > > Time Spent: 10m > Remaining Estimate: 0h > > Bring up the Flow Configuration History page and observe that each column can > be sorted ascending and descending. > Apply any filter that results in multiple rows. The columns can no longer be > sorted. Noticeably, the sort is by Date/Time ascending, which doesn't match > the default Date/Time descending. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13657) Processor Load Average has wrong value aggregator
[ https://issues.apache.org/jira/browse/NIFI-13657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13657: Fix Version/s: 2.0.0-M5 Resolution: Fixed Status: Resolved (was: Patch Available) > Processor Load Average has wrong value aggregator > - > > Key: NIFI-13657 > URL: https://issues.apache.org/jira/browse/NIFI-13657 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 2.0.0-M4 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: 2.0.0-M5 > > Time Spent: 20m > Remaining Estimate: 0h > > The descriptor for Processor Load Average has a value aggregator that pulls > out HEAP_UTILIZATION instead of PROCESSOR_LOAD_AVERAGE, this causes the > aggregated results for this metric to be incorrect and on the Node Status > History it shows all 0s under NiFi for the mean/min/max and on the Y Axis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13430) Add CopyS3Object and GetS3ObjectMetadata for AWS
[ https://issues.apache.org/jira/browse/NIFI-13430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-13430. - Fix Version/s: 2.0.0-M5 Resolution: Fixed > Add CopyS3Object and GetS3ObjectMetadata for AWS > > > Key: NIFI-13430 > URL: https://issues.apache.org/jira/browse/NIFI-13430 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Fix For: 2.0.0-M5 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > This ticket will add CopyS3Object, a processor that will use the Copy API to > have S3 directly execute a copy without downloading the file and > ExistsS3Object which uses a light weight API that doesn't attempt a file > download in order to check the existence of a file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
