[jira] [Updated] (NIFI-10853) UpdateAttribute - expression language syntax error not caught until processor runtime
[
https://issues.apache.org/jira/browse/NIFI-10853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10853:
Fix Version/s: 1.20.0
> UpdateAttribute - expression language syntax error not caught until processor
> runtime
> -
>
> Key: NIFI-10853
> URL: https://issues.apache.org/jira/browse/NIFI-10853
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
> Fix For: 1.20.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The UpdateAttribute will not show any alerts when the following expression
> language value is used for a property value:
> {code:java}
> ${filename:equals('testFile'}
> {code}
> This is also true when using the 'Verify Properties' button. (A green arrow
> is returned saying "Component Validation Passed").
> The processor will start, but when a flowfile passed through on runtime,
> though, it will fail
> with error
> {code}
> org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
> Invalid Expression: ${filename:equals('testFile'} due to Unexpected token
> '}' at line 1, column 28. Query: ${filename:equals(testFile}
> {code}
> (This is not the case with RouteOnAttribute, which will leave the processor
> in an invalid state, flagging this as an alert, until the expression is
> corrected.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11090) Remove jasypt test dependency
[ https://issues.apache.org/jira/browse/NIFI-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-11090: Resolution: Fixed Status: Resolved (was: Patch Available) > Remove jasypt test dependency > - > > Key: NIFI-11090 > URL: https://issues.apache.org/jira/browse/NIFI-11090 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Java Simplified Encryption library jasypt is a test dependency in the > framework bundle, but does not have any direct usage in current tests, so it > should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10580) Update NiFi to use SLF4j 2.x line instead of 1.x line
[ https://issues.apache.org/jira/browse/NIFI-10580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10580: Resolution: Fixed Status: Resolved (was: Patch Available) > Update NiFi to use SLF4j 2.x line instead of 1.x line > - > > Key: NIFI-10580 > URL: https://issues.apache.org/jira/browse/NIFI-10580 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: David Handermann >Priority: Major > Fix For: 1.20.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11089) Import from registry can create duplicate parameter providers
[jira] [Updated] (NIFI-11032) NPE during Import from Registry
[
https://issues.apache.org/jira/browse/NIFI-11032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-11032:
Fix Version/s: 1.20.0
> NPE during Import from Registry
> ---
>
> Key: NIFI-11032
> URL: https://issues.apache.org/jira/browse/NIFI-11032
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.19.1
>Reporter: Bryan Bende
>Assignee: Joe Gresock
>Priority: Minor
> Fix For: 1.20.0
>
>
> {color:#1d1c1d}upgraded NiFi and NiFi Registry from 1.16.0 to 1.19.1{color}
> {code:java}
> 2023-01-06 23:43:55,879 ERROR [NiFi Web Server-153]
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred:
> java.lang.NullPointerException. Returning Internal Server Error
> response.java.lang.NullPointerException: null at
> org.apache.nifi.web.api.FlowResource.populateRemainingRegistryClientEntityContent(FlowResource.java:1649)
> at
> org.apache.nifi.web.api.FlowResource.populateRemainingRegistryClientEntityContent(FlowResource.java:1661)
> at
> org.apache.nifi.web.api.FlowResource.getRegistryClients(FlowResource.java:1637)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at {code}
> {color:#1d1c1d}I do not get this error when I use the "Administrator"
> account.{color} {color:#1d1c1d}I think I solved it by adding the user account
> to the Access Policy "access the controller" with View permissions. The
> Administrator was already there. {color}{color:#1d1c1d}The error no longer
> occurs.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11088) Update Copyright for 2023
[ https://issues.apache.org/jira/browse/NIFI-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-11088: Resolution: Fixed Status: Resolved (was: Patch Available) > Update Copyright for 2023 > - > > Key: NIFI-11088 > URL: https://issues.apache.org/jira/browse/NIFI-11088 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10932) NiFi Toolkit CLI cannot connect to NiFi - trustAnchors parameter must be non-empty
[
https://issues.apache.org/jira/browse/NIFI-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10932:
Fix Version/s: 1.20.0
> NiFi Toolkit CLI cannot connect to NiFi - trustAnchors parameter must be
> non-empty
> --
>
> Key: NIFI-10932
> URL: https://issues.apache.org/jira/browse/NIFI-10932
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.19.0, 1.19.1
>Reporter: Chris Sampson
>Priority: Major
> Fix For: 1.20.0
>
>
> When running NiFi 1.19.0 using the {{apache/nifi}} docker image, the NiFi
> Toolkit is not able to connect to the running NiFi instance (with the default
> Single User Auth enabled).
> Having updated the NiFi Toolkit CLI properties file with the Truststore and
> Keystore details generated by NiFi (found within {{nifi.properties}}), then
> attempting to run a command using the NiFi Toolkit command line such as:
> {code:bash}
> /opt/nifi/nifi-toolkit-current/bin/cli.sh session set nifi
> /opt/nifi/nifi-toolkit-current/bin/cli.sh nifi get-services
> {code}
> The following error is returned:
> {quote}
> ERROR: Error executing command 'get-services' : Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
> must be non-empty
> {quote}
> This suggests something isn't working correctly with the NiFi Toolkit JVM
> process/configuration or such (e.g. the correct truststore is not being used,
> see https://www.baeldung.com/java-trustanchors-parameter-must-be-non-empty)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10932) NiFi Toolkit CLI cannot connect to NiFi - trustAnchors parameter must be non-empty
[
https://issues.apache.org/jira/browse/NIFI-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679886#comment-17679886
]
Joe Witt commented on NIFI-10932:
-
looks like an unintended regression - gonna tag to 1.20.
> NiFi Toolkit CLI cannot connect to NiFi - trustAnchors parameter must be
> non-empty
> --
>
> Key: NIFI-10932
> URL: https://issues.apache.org/jira/browse/NIFI-10932
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.19.0, 1.19.1
>Reporter: Chris Sampson
>Priority: Major
> Fix For: 1.20.0
>
>
> When running NiFi 1.19.0 using the {{apache/nifi}} docker image, the NiFi
> Toolkit is not able to connect to the running NiFi instance (with the default
> Single User Auth enabled).
> Having updated the NiFi Toolkit CLI properties file with the Truststore and
> Keystore details generated by NiFi (found within {{nifi.properties}}), then
> attempting to run a command using the NiFi Toolkit command line such as:
> {code:bash}
> /opt/nifi/nifi-toolkit-current/bin/cli.sh session set nifi
> /opt/nifi/nifi-toolkit-current/bin/cli.sh nifi get-services
> {code}
> The following error is returned:
> {quote}
> ERROR: Error executing command 'get-services' : Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
> must be non-empty
> {quote}
> This suggests something isn't working correctly with the NiFi Toolkit JVM
> process/configuration or such (e.g. the correct truststore is not being used,
> see https://www.baeldung.com/java-trustanchors-parameter-must-be-non-empty)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11088) Update Copyright for 2023
[ https://issues.apache.org/jira/browse/NIFI-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-11088: Fix Version/s: 1.20.0 > Update Copyright for 2023 > - > > Key: NIFI-11088 > URL: https://issues.apache.org/jira/browse/NIFI-11088 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (NIFI-11064) TestPutSFTP contains brittle test - testRunTransitUriDifferentHosts
[ https://issues.apache.org/jira/browse/NIFI-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt reopened NIFI-11064: - > TestPutSFTP contains brittle test - testRunTransitUriDifferentHosts > --- > > Key: NIFI-11064 > URL: https://issues.apache.org/jira/browse/NIFI-11064 > Project: Apache NiFi > Issue Type: Bug > Environment: Apache Maven 3.8.6 > (84538c9988a25aec085021c365c560670ad80f63) > Java version: 1.8.0_345, vendor: Azul Systems, Inc., runtime: > /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "13.1", arch: "aarch64", family: "mac" >Reporter: Joe Witt >Assignee: David Handermann >Priority: Major > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > --- > Test set: org.apache.nifi.processors.standard.TestPutSFTP > --- > Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.397 s <<< > FAILURE! - in org.apache.nifi.processors.standard.TestPutSFTP > org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts > Time elapsed: 0.07 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <2> but was: <1> > at > org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) > at > org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) > at > org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) > at > org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) > at > org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) > at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528) > at > org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:395) > at > org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts(TestPutSFTP.java:227) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) > at > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) > at > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) > at >
[jira] [Commented] (NIFI-11064) TestPutSFTP contains brittle test - testRunTransitUriDifferentHosts
[ https://issues.apache.org/jira/browse/NIFI-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679875#comment-17679875 ] Joe Witt commented on NIFI-11064: - Hello I just reopened this because the previous commit has not resolved the issue completely. I just hit it again. [ERROR] Failures: [ERROR] TestPutSFTP.testRunTransitUriDifferentHosts:228 expected: <2> but was: <1> [INFO] [ERROR] Tests run: 1741, Failures: 1, Errors: 0, Skipped: 4 9:06 [ERROR] Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.411 s <<< FAILURE! - in org.apache.nifi.processors.standard.TestPutSFTP [ERROR] org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts Time elapsed: 0.051 s <<< FAILURE! org.opentest4j.AssertionFailedError: expected: <2> but was: <1> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528) at org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:395) at org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts(TestPutSFTP.java:228) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at > TestPutSFTP contains brittle test - testRunTransitUriDifferentHosts > --- > > Key: NIFI-11064 > URL: https://issues.apache.org/jira/browse/NIFI-11064 > Project: Apache NiFi > Issue Type: Bug > Environment: Apache Maven 3.8.6 > (84538c9988a25aec085021c365c560670ad80f63) > Java version: 1.8.0_345, vendor: Azul Systems, Inc., runtime: > /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "13.1", arch: "aarch64", family: "mac" >Reporter: Joe Witt >Assignee: David Handermann >Priority: Major > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > --- > Test set: org.apache.nifi.processors.standard.TestPutSFTP > --- > Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.397 s <<< > FAILURE! - in org.apache.nifi.processors.standard.TestPutSFTP > org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts > Time elapsed: 0.07 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <2> but was: <1> > at > org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) > at > org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) > at > org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) > at > org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) > at > org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) > at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528) > at > org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:395) > at
[jira] [Updated] (NIFI-10993) PublishKafkaRecord should write key record (when configured) using correct schema
[ https://issues.apache.org/jira/browse/NIFI-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10993: Fix Version/s: 1.20.0 > PublishKafkaRecord should write key record (when configured) using correct > schema > - > > Key: NIFI-10993 > URL: https://issues.apache.org/jira/browse/NIFI-10993 > Project: Apache NiFi > Issue Type: Bug >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > community report via > (https://www.mail-archive.com/users@nifi.apache.org/msg15668.html) > to us...@nifi.apache.org > To whom it may concern, > Hello, I would like to report an issue for Nifi. But, following the new Jira > Guidelines, I would therefore like to request that an account for ASF Jira in > order to create a ticket. > In regards to the bug, using Nifi 1.19.1 I would like to send a tombstone > message (null payload) to Kafka and using the Confluent JDBC sink connector > (with delete.enabled=true) to delete a record in our Postgres database. I > believe as of Nifi 1.19, PublishKafkaRecord_2_6 now supports the 'Publish > Strategy: Use Wrapper' feature which allows setting the Kafka message key and > value (Primary Key as the Kafka key, null for the Kafka value). For the > Record Key Writer, I'm using an AvroRecordSetWriter to validate and serialize > the key against the confluent schema registry (Schema Write Strategy: > Confluent Schema Registry Reference, Schema Access Strategy: Use 'Schema > Name' Property) but sending the message I come across the error: > PublishKafkaRecord_2_6[id=XXX] Failed to send FlowFile[filename=XXX] to > Kafka: org.apache.nifi.processor.exception.ProcessException: Could not > determine the Avro Schema to use for writing the content > - Caused by: org.apache.nifi.schema.access.SchemaNotFoundException: Cannot > write Confluent Schema Registry Reference because the Schema Identifier is > not known > I can confirm the configuration for the for the AvroRecordSetWriter, > ConfluentSchemaRegistry controllers, and PublishKafkaRecord processor are all > configured correctly, as I can send the Kafka message just fine using the > default Publish Strategy (Use Content as Record Value). It only occurs using > Use Wrapper, and the ConfluentSchemaRegistry. > A workaround that has worked was for using JsonRecordSetWriter w/ embedded > JSON schemas, but it would be nice to continue using our Avro Schema Registry > for this. > I'd appreciate if someone had any advice or experience with this issue, > otherwise I'd like to log an issue in JIRA. > Thank you, > Austin Tao -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10580) Update NiFi to use SLF4j 2.x line instead of 1.x line
[ https://issues.apache.org/jira/browse/NIFI-10580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10580: Fix Version/s: 1.20.0 > Update NiFi to use SLF4j 2.x line instead of 1.x line > - > > Key: NIFI-10580 > URL: https://issues.apache.org/jira/browse/NIFI-10580 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: David Handermann >Priority: Major > Fix For: 1.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10580) Update NiFi to use SLF4j 2.x line instead of 1.x line
[ https://issues.apache.org/jira/browse/NIFI-10580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679861#comment-17679861 ] Joe Witt commented on NIFI-10580: - reviewing. > Update NiFi to use SLF4j 2.x line instead of 1.x line > - > > Key: NIFI-10580 > URL: https://issues.apache.org/jira/browse/NIFI-10580 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: David Handermann >Priority: Major > Fix For: 1.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10973) NiFi Registry Client with Nested PGs/Flows - sync issue (again)
[
https://issues.apache.org/jira/browse/NIFI-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10973:
Fix Version/s: 1.20.0
> NiFi Registry Client with Nested PGs/Flows - sync issue (again)
> ---
>
> Key: NIFI-10973
> URL: https://issues.apache.org/jira/browse/NIFI-10973
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.19.1
>Reporter: Josef Zahner
>Assignee: Simon Bence
>Priority: Critical
> Fix For: 1.20.0
>
> Attachments: Nested_PG_Test.xml, Sync_issue_State.png,
> Sync_issue_local_changes.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We just upgraded to NiFi 1.19.1 and we have an issue with the NiFi Registry
> Client in combination with nested PGs (parent PG and child PGs are both
> commited as NiFi Registry flows).
> Steps to reproduce the issue (based on the attached template xml):
> Hint: {color:#57d9a3}Green Color {color}-> NiFi Registry flow Master;
> {color:#4c9aff}Blue Color{color} -> Secondary NiFi/Canvas where you import
> the flow from Registry
> * {color:#57d9a3}Import the XML template{color}
> * {color:#57d9a3}Start Version Control for "Child PG"{color}
> * {color:#57d9a3}Start Version Control for "Parent PG"{color}
> * {color:#4c9aff}On an independent canvas/nifi click "Add Process Group" and
> "Import from Registry", select the "Parent PG" flow{color}
> * {color:#57d9a3}On the original "Child PG" rename the only existing
> processor, eg. to "UpdateCounter New"{color}
> * {color:#57d9a3}Commit the change for the "Child PG" (Processor
> Rename){color}
> * {color:#57d9a3}Commit the change for the "Parent PG" (Version change of
> "Child PG"){color}
> * {color:#4c9aff}Now click "Change Version" on the other NiFi/Canvas and
> switch to the newest version for the "Parent PG", which seems to be
> successful. *However* *now we are hitting the issue, NiFi shows a successful
> change, but NiFi shows as well "Local Changes" for the "Child PG" (not for
> the "Parent PG"). To get a good state you have to click to "Revert Local
> Changes" on the "Child PG" which makes no sense, it should directly sync the
> "Child PG" according to the commited version. At least the version number of
> the "Child PG" has been changed but not the real configuration as you see
> below in the screenshots. It shows that there has been a component name
> change, which is true for the version but to get to the new version we have
> to revert the local changes*{color}
>
> Screenshots with the Failure State below, "Parent PG" is in sync, but not the
> "Child PG". The only thing I've done is to change the Version on the "Parent
> PG":
> {color:#4c9aff}*!Sync_issue_State.png!*{color}
>
> {color:#4c9aff}*!Sync_issue_local_changes.png!*{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10934) Add name validation for registry client creation
[ https://issues.apache.org/jira/browse/NIFI-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10934: Fix Version/s: 1.20.0 > Add name validation for registry client creation > > > Key: NIFI-10934 > URL: https://issues.apache.org/jira/browse/NIFI-10934 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Minor > Fix For: 1.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently when a Registry Client is added to the NiFi, it allows to reuse an > existing name. In a later step, when the Registry Client properties are > edited, a validation happens and the name collusion is listed as validation > issue. > It would be preferred to check for name collusion during creation. > Expected behaviour: > Given a Registry Client is added to NiFi with name R1 > When an other Registry Client is added to NiFi with name R1 > Then the creation is unsuccessful, and an error message is returned on the UI -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11039) Importing flow should handle missing parameter provider
[
https://issues.apache.org/jira/browse/NIFI-11039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-11039:
Fix Version/s: 1.20.0
> Importing flow should handle missing parameter provider
> ---
>
> Key: NIFI-11039
> URL: https://issues.apache.org/jira/browse/NIFI-11039
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.18.0, 1.19.0, 1.19.1
>Reporter: Bryan Bende
>Assignee: Joe Gresock
>Priority: Major
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From Apache Slack:
> {color:#1d1c1d}We have been using deployment of Parameter Contexts using
> Parameter Providers in Nifi v1.18.0. We are also using the NiFi registry to
> save Processor Groups and restore them into the current flow. There is an
> issue where if a Process Group is saved with a Parameter Context, that has
> been created via a Parameter Provider and the Provider has been deleted, the
> flow fails to deploy saying the provider does not exist. I guess I would
> expect the behavior to create the Parameter Provider if it doesn't exist,
> just like when the Parameter Contexts, Controller Services ect. Even if the
> desired behavior is to not create Parameter Providers, the import from the
> registry should still fail gracefully and allow the remaining flow to be
> imported, ignoring the missing Provider. If I get a flow into this state, I
> either have to find an older version of the flow in the registry to recover,
> or I need to manually download, modify and re-upload the PG in order to get
> the flow deployed.{color}
> {color:#1d1c1d}Stacktrace:{color}
> {code:java}
> 2023-01-10 19:35:02,293 INFO [NiFi Web Server-43]
> o.a.n.w.a.c.IllegalArgumentExceptionMapper
> java.lang.IllegalArgumentException: Could not configure Parameter Provider
> 985860cf-0185-1000-dcb9-6a2c63edbdbf, which could not be found}. Returning
> Bad Request} response.java.lang.IllegalArgumentException: Could not configure
> Parameter Provider 985860cf-0185-1000-dcb9-6a2c63edbdbf, which could not be
> foundat
> org.apache.nifi.parameter.StandardParameterContext.configureParameterProvider(StandardParameterContext.java:482)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addMissingConfiguration(StandardVersionedComponentSynchronizer.java:2093)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.selectParameterContext(StandardVersionedComponentSynchronizer.java:2056)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$addMissingConfiguration$30(StandardVersionedComponentSynchronizer.java:2089)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11076) NiFi build locks up in stateless nifi tests due to deadlock
[ https://issues.apache.org/jira/browse/NIFI-11076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-11076: Attachment: hung-nifi.txt hung-nifi-other.txt > NiFi build locks up in stateless nifi tests due to deadlock > --- > > Key: NIFI-11076 > URL: https://issues.apache.org/jira/browse/NIFI-11076 > Project: Apache NiFi > Issue Type: Bug > Environment: windows/osx. Env seems not important >Reporter: Joe Witt >Priority: Blocker > Fix For: 1.20.0 > > Attachments: hung-nifi-other.txt, hung-nifi.txt > > > Will attach two thread dumps from the running build processes/forked > execution which show deadlock. Likely the same problem hit on github ci the > other day too for the windows build > https://github.com/apache/nifi/actions/runs/3958072460/jobs/6779197263 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11076) NiFi build locks up in stateless nifi tests due to deadlock
Joe Witt created NIFI-11076: --- Summary: NiFi build locks up in stateless nifi tests due to deadlock Key: NIFI-11076 URL: https://issues.apache.org/jira/browse/NIFI-11076 Project: Apache NiFi Issue Type: Bug Environment: windows/osx. Env seems not important Reporter: Joe Witt Fix For: 1.20.0 Will attach two thread dumps from the running build processes/forked execution which show deadlock. Likely the same problem hit on github ci the other day too for the windows build https://github.com/apache/nifi/actions/runs/3958072460/jobs/6779197263 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11048) NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8
[ https://issues.apache.org/jira/browse/NIFI-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-11048: Fix Version/s: 1.20.0 Resolution: Fixed Status: Resolved (was: Patch Available) much rejoicing! Thanks David. +1 merged to main > NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8 > > > Key: NIFI-11048 > URL: https://issues.apache.org/jira/browse/NIFI-11048 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build > Environment: Apache Maven 3.8.7 > (b89d5959fcde851dcb1c8946a785a163f14e1e29) > Maven home: /development/tools/apache-maven-3.8.7 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: > "unix" >Reporter: Joe Witt >Assignee: David Handermann >Priority: Major > Fix For: 1.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > In the nifi-toolkit-cli module the nifi build locks up. The stack trace is > below. The issue appears to be when CLICompleter.java line 200 is called > during tests in TestCLICompleter.java such as > 'testCompletionWithFileArguments' and > 'testCompletionForSessionVariableWithFiles'. The specific line in question > was found in a debug session. The call stack is so deep you wont find this > in there -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11064) TestPutSFTP contains brittle test - testRunTransitUriDifferentHosts
Joe Witt created NIFI-11064: --- Summary: TestPutSFTP contains brittle test - testRunTransitUriDifferentHosts Key: NIFI-11064 URL: https://issues.apache.org/jira/browse/NIFI-11064 Project: Apache NiFi Issue Type: Bug Environment: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Java version: 1.8.0_345, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.1", arch: "aarch64", family: "mac" Reporter: Joe Witt --- Test set: org.apache.nifi.processors.standard.TestPutSFTP --- Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.397 s <<< FAILURE! - in org.apache.nifi.processors.standard.TestPutSFTP org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts Time elapsed: 0.07 s <<< FAILURE! org.opentest4j.AssertionFailedError: expected: <2> but was: <1> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528) at org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:395) at org.apache.nifi.processors.standard.TestPutSFTP.testRunTransitUriDifferentHosts(TestPutSFTP.java:227) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at
[jira] [Commented] (NIFI-11048) NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8
[ https://issues.apache.org/jira/browse/NIFI-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676295#comment-17676295 ] Joe Witt commented on NIFI-11048: - this issue does not occur on Java 17 Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29) Maven home: /development/tools/apache-maven-3.8.7 Java version: 17.0.5, vendor: Azul Systems, Inc., runtime: /usr/lib/jvm/zulu17.38.21-ca-jdk17.0.5-linux_x64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: "unix" > NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8 > > > Key: NIFI-11048 > URL: https://issues.apache.org/jira/browse/NIFI-11048 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build > Environment: Apache Maven 3.8.7 > (b89d5959fcde851dcb1c8946a785a163f14e1e29) > Maven home: /development/tools/apache-maven-3.8.7 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: > "unix" >Reporter: Joe Witt >Priority: Major > > In the nifi-toolkit-cli module the nifi build locks up. The stack trace is > below. The issue appears to be when CLICompleter.java line 200 is called > during tests in TestCLICompleter.java such as > 'testCompletionWithFileArguments' and > 'testCompletionForSessionVariableWithFiles'. The specific line in question > was found in a debug session. The call stack is so deep you wont find this > in there -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11048) NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8
[ https://issues.apache.org/jira/browse/NIFI-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676288#comment-17676288 ] Joe Witt commented on NIFI-11048: - this issue does not occur on Java 11 Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29) Maven home: /development/tools/apache-maven-3.8.7 Java version: 11.0.17, vendor: Azul Systems, Inc., runtime: /usr/lib/jvm/zulu11.60.19-ca-jdk11.0.17-linux_x64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: "unix" > NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8 > > > Key: NIFI-11048 > URL: https://issues.apache.org/jira/browse/NIFI-11048 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build > Environment: Apache Maven 3.8.7 > (b89d5959fcde851dcb1c8946a785a163f14e1e29) > Maven home: /development/tools/apache-maven-3.8.7 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: > "unix" >Reporter: Joe Witt >Priority: Major > > In the nifi-toolkit-cli module the nifi build locks up. The stack trace is > below. The issue appears to be when CLICompleter.java line 200 is called > during tests in TestCLICompleter.java such as > 'testCompletionWithFileArguments' and > 'testCompletionForSessionVariableWithFiles'. The specific line in question > was found in a debug session. The call stack is so deep you wont find this > in there -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11048) NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8
[ https://issues.apache.org/jira/browse/NIFI-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-11048: Summary: NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8 (was: NiFi build locks up in nifi-toolkit-cli on Fedora 37) > NiFi build locks up in nifi-toolkit-cli on Fedora 37 with Java 8 > > > Key: NIFI-11048 > URL: https://issues.apache.org/jira/browse/NIFI-11048 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build > Environment: Apache Maven 3.8.7 > (b89d5959fcde851dcb1c8946a785a163f14e1e29) > Maven home: /development/tools/apache-maven-3.8.7 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: > "unix" >Reporter: Joe Witt >Priority: Major > > In the nifi-toolkit-cli module the nifi build locks up. The stack trace is > below. The issue appears to be when CLICompleter.java line 200 is called > during tests in TestCLICompleter.java such as > 'testCompletionWithFileArguments' and > 'testCompletionForSessionVariableWithFiles'. The specific line in question > was found in a debug session. The call stack is so deep you wont find this > in there -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11048) NiFi build locks up in nifi-toolkit-cli on Fedora 37
[ https://issues.apache.org/jira/browse/NIFI-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676285#comment-17676285 ] Joe Witt commented on NIFI-11048: - "main" #1 prio=5 os_prio=0 tid=0x7f91bc00a000 nid=0x30d8a runnable [0x7f91c05b5000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4818) at java.util.regex.Pattern$Prolog.match(Pattern.java:4755) at java.util.regex.Pattern$Branch.match(Pattern.java:4616) at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582) at java.util.regex.Pattern$Curly.match0(Pattern.java:4286) at java.util.regex.Pattern$Curly.match(Pattern.java:4248) at java.util.regex.Pattern$Slice.match(Pattern.java:3986) at java.util.regex.Pattern$Branch.match(Pattern.java:4618) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) at java.util.regex.Pattern$Loop.match(Pattern.java:4799) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4820) at java.util.regex.Pattern$Prolog.match(Pattern.java:4755) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) at java.util.regex.Pattern$Curly.match0(Pattern.java:4286) at java.util.regex.Pattern$Curly.match(Pattern.java:4248) at java.util.regex.Pattern$Curly.match0(Pattern.java:4286) at java.util.regex.Pattern$Curly.match(Pattern.java:4248) at java.util.regex.Pattern$Ques.match(Pattern.java:4196) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) at java.util.regex.Pattern$Branch.match(Pattern.java:4618) at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582) at java.util.regex.Pattern$Curly.match0(Pattern.java:4286) at java.util.regex.Pattern$Curly.match(Pattern.java:4248) at java.util.regex.Pattern$Slice.match(Pattern.java:3986) at java.util.regex.Pattern$Branch.match(Pattern.java:4618) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) at java.util.regex.Pattern$Loop.match(Pattern.java:4799) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4820) at java.util.regex.Pattern$Prolog.match(Pattern.java:4755) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) many lines removed at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582) at java.util.regex.Pattern$Curly.match0(Pattern.java:4286) at java.util.regex.Pattern$Curly.match(Pattern.java:4248) at java.util.regex.Pattern$Slice.match(Pattern.java:3986) at java.util.regex.Pattern$Branch.match(Pattern.java:4618) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672) > NiFi build locks up in nifi-toolkit-cli on Fedora 37 > > > Key: NIFI-11048 > URL: https://issues.apache.org/jira/browse/NIFI-11048 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build > Environment: Apache Maven 3.8.7 > (b89d5959fcde851dcb1c8946a785a163f14e1e29) > Maven home: /development/tools/apache-maven-3.8.7 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: > "unix" >Reporter: Joe Witt >Priority: Major > > In the nifi-toolkit-cli module the nifi build locks up. The stack trace is > below. The issue appears to be when CLICompleter.java line 200 is called > during tests in TestCLICompleter.java such as > 'testCompletionWithFileArguments' and > 'testCompletionForSessionVariableWithFiles'. The specific line
[jira] [Created] (NIFI-11049) PutDropboxTest is an unreliable test
Joe Witt created NIFI-11049: --- Summary: PutDropboxTest is an unreliable test Key: NIFI-11049 URL: https://issues.apache.org/jira/browse/NIFI-11049 Project: Apache NiFi Issue Type: Bug Environment: Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29) Maven home: /development/tools/apache-maven-3.8.7 Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: "unix" Reporter: Joe Witt [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.024 s <<< FAILURE! - in org.apache.nifi.processors.dropbox.PutDropboxTest [ERROR] org.apache.nifi.processors.dropbox.PutDropboxTest.testFileUploadLargeFile Time elapsed: 0.132 s <<< FAILURE! org.opentest4j.AssertionFailedError: Expected all Transferred FlowFiles to go to success but 1 were routed to failure at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38) at org.junit.jupiter.api.Assertions.fail(Assertions.java:135) at org.apache.nifi.util.MockProcessSession.assertAllFlowFilesTransferred(MockProcessSession.java:1294) at org.apache.nifi.util.StandardProcessorTestRunner.assertAllFlowFilesTransferred(StandardProcessorTestRunner.java:310) at org.apache.nifi.util.StandardProcessorTestRunner.assertAllFlowFilesTransferred(StandardProcessorTestRunner.java:389) at org.apache.nifi.processors.dropbox.PutDropboxTest.testFileUploadLargeFile(PutDropboxTest.java:274) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at
[jira] [Created] (NIFI-11048) NiFi build locks up in nifi-toolkit-cli on Fedora 37
Joe Witt created NIFI-11048: --- Summary: NiFi build locks up in nifi-toolkit-cli on Fedora 37 Key: NIFI-11048 URL: https://issues.apache.org/jira/browse/NIFI-11048 Project: Apache NiFi Issue Type: Bug Components: Tools and Build Environment: Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29) Maven home: /development/tools/apache-maven-3.8.7 Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: /usr/lib/jvm/zulu8.66.0.15-ca-jdk8.0.352-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.0.18-300.fc37.x86_64", arch: "amd64", family: "unix" Reporter: Joe Witt In the nifi-toolkit-cli module the nifi build locks up. The stack trace is below. The issue appears to be when CLICompleter.java line 200 is called during tests in TestCLICompleter.java such as 'testCompletionWithFileArguments' and 'testCompletionForSessionVariableWithFiles'. The specific line in question was found in a debug session. The call stack is so deep you wont find this in there -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10944) TestConvertAvroToParquet.testData is a flaky test
[
https://issues.apache.org/jira/browse/NIFI-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675652#comment-17675652
]
Joe Witt commented on NIFI-10944:
-
[~TheGreatRandall] Please stop setting fix versions on PRs. We might not
include a given PR on a given fix version and in cases like this it changes
what the release notes would show for a given release.
> TestConvertAvroToParquet.testData is a flaky test
> -
>
> Key: NIFI-10944
> URL: https://issues.apache.org/jira/browse/NIFI-10944
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Haoran Jiang
>Priority: Trivial
> Fix For: 1.19.0
>
> Attachments:
> org.apache.nifi.processors.parquet.TestConvertAvroToParquet.testData.rtf
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.nifi.processors.parquet.TestConvertAvroToParquet.testData {code}
> Hi Community,
>
> This is the flaky test. It can pass maven-test while testing failed under
> [NonDex|[https://github.com/TestingResearchIllinois/NonDex]].
> This is the log for the result.
> {code:java}
> ---
> Test set: org.apache.nifi.processors.parquet.TestConvertAvroToParquet
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.694 s <<<
> FAILURE! - in org.apache.nifi.processors.parquet.TestConvertAvroToParquet
> org.apache.nifi.processors.parquet.TestConvertAvroToParquet.testData Time
> elapsed: 1.664 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <2> but was: <1> {code}
> *Steps to reporduce the failure:*
> 1:intall [Nondex|[https://github.com/TestingResearchIllinois/NonDex]]
> 2. Run the command in nifi:
> {code:java}
> mvn -pl nifi-nar-bundles/nifi-parquet-bundle/nifi-parquet-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.parquet.TestConvertAvroToParquet#testData
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10968) TestFetchDistributedMapCache.testMultipleKeysOneNotFound
[
https://issues.apache.org/jira/browse/NIFI-10968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675654#comment-17675654
]
Joe Witt commented on NIFI-10968:
-
[~TheGreatRandall] Please stop setting fix versions on PRs. We might not
include a given PR on a given fix version and in cases like this it changes
what the release notes would show for a given release.
> TestFetchDistributedMapCache.testMultipleKeysOneNotFound
>
>
> Key: NIFI-10968
> URL: https://issues.apache.org/jira/browse/NIFI-10968
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Haoran Jiang
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.processors.standard.TestFetchDistributedMapCache.testMultipleKeysOneNotFound
> {code}
> Hi Community, This is the flaky test. It can pass maven-test while testing
> failed under [NonDex|[https://github.com/TestingResearchIllinois/NonDex].]
> This is the log for the result.
>
> {code:java}
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] TestFetchDistributedMapCache.testMultipleKeysOneNotFound:209
> Expected attribute test.key1 to be value1 but instead it was null ==>
> expected: but was:
> [INFO]
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 {code}
> *Steps to reporduce the failure:*
>
> 1:intall [Nondex|[https://github.com/TestingResearchIllinois/NonDex]]
> 2.Run the command in nifi:
> {code:java}
> mvn -pl nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.standard.TestFetchDistributedMapCache#testMultipleKeysOneNotFound
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10952) TestScriptedPartitionRecord.testWhenMultiplePartitions is a flaky test
[
https://issues.apache.org/jira/browse/NIFI-10952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675653#comment-17675653
]
Joe Witt commented on NIFI-10952:
-
[~TheGreatRandall] Please stop setting fix versions on PRs. We might not
include a given PR on a given fix version and in cases like this it changes
what the release notes would show for a given release.
> TestScriptedPartitionRecord.testWhenMultiplePartitions is a flaky test
> --
>
> Key: NIFI-10952
> URL: https://issues.apache.org/jira/browse/NIFI-10952
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Haoran Jiang
>Priority: Trivial
> Attachments:
> org.apache.nifi.processors.script.TestScriptedPartitionRecord.rtf
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.nifi.processors.script.TestScriptedPartitionRecord.testWhenMultiplePartitions
> {code}
> Hi Community,
>
>
> This is the flaky test. It can pass maven-test while tesing failed under
> [NonDex|[https://github.com/TestingResearchIllinois/NonDex]].
> This is the log for the result.
>
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]
> TestScriptedPartitionRecord.testWhenMultiplePartitions:96->thenPartitionContains:171
> expected:<[0]> but was:<[1]>
> [INFO]
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO] {code}
> *Steps to reporduce the failure:*
>
> 1:1:intall [Nondex|[https://github.com/TestingResearchIllinois/NonDex]]
> 2: Run he command in nifi:
> {code:java}
> mvn -pl nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.script.TestScriptedPartitionRecord#testWhenMultiplePartitions
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10968) TestFetchDistributedMapCache.testMultipleKeysOneNotFound
[
https://issues.apache.org/jira/browse/NIFI-10968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10968:
Fix Version/s: (was: 1.19.0)
> TestFetchDistributedMapCache.testMultipleKeysOneNotFound
>
>
> Key: NIFI-10968
> URL: https://issues.apache.org/jira/browse/NIFI-10968
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Haoran Jiang
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.processors.standard.TestFetchDistributedMapCache.testMultipleKeysOneNotFound
> {code}
> Hi Community, This is the flaky test. It can pass maven-test while testing
> failed under [NonDex|[https://github.com/TestingResearchIllinois/NonDex].]
> This is the log for the result.
>
> {code:java}
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] TestFetchDistributedMapCache.testMultipleKeysOneNotFound:209
> Expected attribute test.key1 to be value1 but instead it was null ==>
> expected: but was:
> [INFO]
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 {code}
> *Steps to reporduce the failure:*
>
> 1:intall [Nondex|[https://github.com/TestingResearchIllinois/NonDex]]
> 2.Run the command in nifi:
> {code:java}
> mvn -pl nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.standard.TestFetchDistributedMapCache#testMultipleKeysOneNotFound
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10944) TestConvertAvroToParquet.testData is a flaky test
[
https://issues.apache.org/jira/browse/NIFI-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10944:
Fix Version/s: (was: 1.19.0)
> TestConvertAvroToParquet.testData is a flaky test
> -
>
> Key: NIFI-10944
> URL: https://issues.apache.org/jira/browse/NIFI-10944
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Haoran Jiang
>Priority: Trivial
> Attachments:
> org.apache.nifi.processors.parquet.TestConvertAvroToParquet.testData.rtf
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.nifi.processors.parquet.TestConvertAvroToParquet.testData {code}
> Hi Community,
>
> This is the flaky test. It can pass maven-test while testing failed under
> [NonDex|[https://github.com/TestingResearchIllinois/NonDex]].
> This is the log for the result.
> {code:java}
> ---
> Test set: org.apache.nifi.processors.parquet.TestConvertAvroToParquet
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.694 s <<<
> FAILURE! - in org.apache.nifi.processors.parquet.TestConvertAvroToParquet
> org.apache.nifi.processors.parquet.TestConvertAvroToParquet.testData Time
> elapsed: 1.664 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <2> but was: <1> {code}
> *Steps to reporduce the failure:*
> 1:intall [Nondex|[https://github.com/TestingResearchIllinois/NonDex]]
> 2. Run the command in nifi:
> {code:java}
> mvn -pl nifi-nar-bundles/nifi-parquet-bundle/nifi-parquet-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.parquet.TestConvertAvroToParquet#testData
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10952) TestScriptedPartitionRecord.testWhenMultiplePartitions is a flaky test
[
https://issues.apache.org/jira/browse/NIFI-10952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10952:
Fix Version/s: (was: 1.19.0)
> TestScriptedPartitionRecord.testWhenMultiplePartitions is a flaky test
> --
>
> Key: NIFI-10952
> URL: https://issues.apache.org/jira/browse/NIFI-10952
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Haoran Jiang
>Priority: Trivial
> Attachments:
> org.apache.nifi.processors.script.TestScriptedPartitionRecord.rtf
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.nifi.processors.script.TestScriptedPartitionRecord.testWhenMultiplePartitions
> {code}
> Hi Community,
>
>
> This is the flaky test. It can pass maven-test while tesing failed under
> [NonDex|[https://github.com/TestingResearchIllinois/NonDex]].
> This is the log for the result.
>
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]
> TestScriptedPartitionRecord.testWhenMultiplePartitions:96->thenPartitionContains:171
> expected:<[0]> but was:<[1]>
> [INFO]
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO] {code}
> *Steps to reporduce the failure:*
>
> 1:1:intall [Nondex|[https://github.com/TestingResearchIllinois/NonDex]]
> 2: Run he command in nifi:
> {code:java}
> mvn -pl nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.script.TestScriptedPartitionRecord#testWhenMultiplePartitions
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10982) Update org.springframework_spring-web
[ https://issues.apache.org/jira/browse/NIFI-10982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647657#comment-17647657 ] Joe Witt commented on NIFI-10982: - Spring 6 requires a baseline of Java 17. We cannot move to Spring 6 until we also have a Java 17 baseline. > Update org.springframework_spring-web > - > > Key: NIFI-10982 > URL: https://issues.apache.org/jira/browse/NIFI-10982 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.1 >Reporter: Phil Lee >Priority: Major > > Update org.springframework_spring-web from 5.3.24 to 6.0.0. This will > remediate > [CVE-2016-127|[https://nvd.nist.gov/vuln/detail/CVE-2016-127]] > Twistlock scan reported this as critical severity vulnerability in NiFi > Toolkit (which is included in NiFi version 1.19.1). > Impacted versions: <6.0.0 > Discovered: 2 days ago > Published: more than 2 years ago > Pivotal Spring Framework through 5.3.16 suffers from a potential remote code > execution (RCE) issue if used for Java deserialization of untrusted data. > Depending on how the library is implemented within a product, this issue may > or not occur, and authentication may be required. NOTE: the vendor\'s > position is that untrusted data is not an intended use case. The product\'s > behavior will not be changed because some users rely on deserialization of > trusted data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-9559) in AWS - Zookeeper Client Can't Reconnect - Session timeout has elapsed while SUSPENDED
[ https://issues.apache.org/jira/browse/NIFI-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-9559: --- Summary: in AWS - Zookeeper Client Can't Reconnect - Session timeout has elapsed while SUSPENDED (was: Zookeeper Client Can't Reconnect - Session timeout has elapsed while SUSPENDED) > in AWS - Zookeeper Client Can't Reconnect - Session timeout has elapsed while > SUSPENDED > --- > > Key: NIFI-9559 > URL: https://issues.apache.org/jira/browse/NIFI-9559 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Matt Burgess >Priority: Minor > Attachments: nifi_and_zookeeper_logs.txt, nifi_error.log > > > After a loss of connection to Zookeeper a NiFi node never successfully > reconnects to the Zookeeper or the Cluster and instead returns errors about > no Cluster Coordinator and a Session timeout has elapsed while SUSPENDED > repeatedly until you restart NiFi. > The error described is the same one at > https://issues.apache.org/jira/browse/CURATOR-405 however that patch has been > in NiFi for several versions now. > NiFi version is 1.15.3 and Zookeeper 3.6.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-9559) in AWS - Zookeeper Client Can't Reconnect - Session timeout has elapsed while SUSPENDED
[ https://issues.apache.org/jira/browse/NIFI-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-9559. Resolution: Information Provided > in AWS - Zookeeper Client Can't Reconnect - Session timeout has elapsed while > SUSPENDED > --- > > Key: NIFI-9559 > URL: https://issues.apache.org/jira/browse/NIFI-9559 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Matt Burgess >Priority: Minor > Attachments: nifi_and_zookeeper_logs.txt, nifi_error.log > > > After a loss of connection to Zookeeper a NiFi node never successfully > reconnects to the Zookeeper or the Cluster and instead returns errors about > no Cluster Coordinator and a Session timeout has elapsed while SUSPENDED > repeatedly until you restart NiFi. > The error described is the same one at > https://issues.apache.org/jira/browse/CURATOR-405 however that patch has been > in NiFi for several versions now. > NiFi version is 1.15.3 and Zookeeper 3.6.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-9559) Zookeeper Client Can't Reconnect - Session timeout has elapsed while SUSPENDED
[ https://issues.apache.org/jira/browse/NIFI-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644967#comment-17644967 ] Joe Witt commented on NIFI-9559: Anyone news to the issue https://issues.apache.org/jira/browse/NIFI-9559 We have also an 3-node Nifi Cluster (1.19.0) on AWS ECS Fargate and external Zookeeper (3.8.0 - 3 ZK nodes) and have the same issue. On high load leading node lost connection to cluster and not correctly reconnecting. (edited) the load was high on the ZK node or high on the NiFI node? Only in the Nifi node. So I start the process on Nifi and after 20-30minutes connection breaks down. But memory and cpu on the node is okay. So task on ECS is still running and I can access the node via direkt IP. In Cluster Management it is displayed as disconnected. (edited) and once it breaks down it is unable to restore? right, task is running. And when I restart the task it breaks down and can not restore. yeesh that is brutal. How do you get it back in? not really back in a working state. Shutting down the node and delete flow.xml.gz and I can start the node and it reconnects to the cluster. But the whole canvas is lost. So at the moment I have no procedure for a recover Why would you have to delete the flow.xml.gz and/or why wouldn't that node rejoin the cluster and inherit the flow... ? so after connection loss to the cluster that happens in a toggling way for all nodes. Node 1 is leader => process load => after a few minutes it loses connection to cluster Node 2 becomes leader => after a few minutes it loses connection so restarting the node with untouched flow.xml.gz leads to a not starting task I could an error message in Flow Initialization can you share/attach those logs? and this desc in the jira yes, I will do. But I have to do it tomorrow :smile: but thanks for your time and questions Hi Joe, I want to update you. The problem is solved. Main issue was throttled troughput mode on AWS EFS. We are using EFS as storage for the data of nifi which has to persist (state, content_repository, flow.file, database_repository and so on) Here it was wrong configured as bursting and limit was reached very fast in time of processing. So because of throttling node lost connection to cluster. And then there was a ping pong because every node uses the same efs filesystem (but different folder). > Zookeeper Client Can't Reconnect - Session timeout has elapsed while SUSPENDED > -- > > Key: NIFI-9559 > URL: https://issues.apache.org/jira/browse/NIFI-9559 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Matt Burgess >Priority: Minor > Attachments: nifi_and_zookeeper_logs.txt, nifi_error.log > > > After a loss of connection to Zookeeper a NiFi node never successfully > reconnects to the Zookeeper or the Cluster and instead returns errors about > no Cluster Coordinator and a Session timeout has elapsed while SUSPENDED > repeatedly until you restart NiFi. > The error described is the same one at > https://issues.apache.org/jira/browse/CURATOR-405 however that patch has been > in NiFi for several versions now. > NiFi version is 1.15.3 and Zookeeper 3.6.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10913) Release NiFi 1.19.1
[ https://issues.apache.org/jira/browse/NIFI-10913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10913. - Resolution: Fixed > Release NiFi 1.19.1 > --- > > Key: NIFI-10913 > URL: https://issues.apache.org/jira/browse/NIFI-10913 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.19.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10921) Upgrade poi.version to 5.2.3
[ https://issues.apache.org/jira/browse/NIFI-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643498#comment-17643498 ] Joe Witt commented on NIFI-10921: - These libraries are a bit notorious for changing a good bit between releases and have at times had questionable inclusions. Have you compared the nar contents before/after this change for any changes to jars and whether we have new/changed license/notice requirements? > Upgrade poi.version to 5.2.3 > > > Key: NIFI-10921 > URL: https://issues.apache.org/jira/browse/NIFI-10921 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade poi.version to 5.2.3 [History of Changes > (apache.org)|https://poi.apache.org/changes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10921) Upgrade poi.version to 5.2.3
[ https://issues.apache.org/jira/browse/NIFI-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643499#comment-17643499 ] Joe Witt commented on NIFI-10921: - They show version changes on their listing you linked (thank you). They might have transitive deps and those are usually what get us. Can you check the resulting nar content before/after? > Upgrade poi.version to 5.2.3 > > > Key: NIFI-10921 > URL: https://issues.apache.org/jira/browse/NIFI-10921 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade poi.version to 5.2.3 [History of Changes > (apache.org)|https://poi.apache.org/changes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10920) Upgrade Jettison to 1.5.2
[ https://issues.apache.org/jira/browse/NIFI-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10920: Fix Version/s: 1.19.1 > Upgrade Jettison to 1.5.2 > - > > Key: NIFI-10920 > URL: https://issues.apache.org/jira/browse/NIFI-10920 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Upgrade Jettison to 1.5.2. Changes can be found here: [Comparing > jettison-1.5.1...jettison-1.5.2 · jettison-json/jettison > (github.com)|https://github.com/jettison-json/jettison/compare/jettison-1.5.1...jettison-1.5.2] > This most notably updates Woodstox-core to 6.4.0 from 6.2.8, which remediates > CVEs in the dependency -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10947) Upgrade Apache Commons Net to 3.9.0
[ https://issues.apache.org/jira/browse/NIFI-10947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10947: Fix Version/s: 1.20.0 1.19.1 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Apache Commons Net to 3.9.0 > --- > > Key: NIFI-10947 > URL: https://issues.apache.org/jira/browse/NIFI-10947 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Multiple Processors and framework support components use Apache Commons Net > for network client operations. Apache Commons Net 3.9.0 includes multiple bug > fixes and improvements, including a resolution for CVE-2021-37533, which can > impact FTP client behavior when connecting to a malicious server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10941) Remove TestNG
[
https://issues.apache.org/jira/browse/NIFI-10941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10941:
Fix Version/s: 1.19.1
> Remove TestNG
> -
>
> Key: NIFI-10941
> URL: https://issues.apache.org/jira/browse/NIFI-10941
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Tools and Build
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Several tests in {{nifi-framework-bundle}} reference TestNG assertions
> instead of JUnit assertions, and several {{nifi-toolkit}} modules include
> TestNG transitive dependencies through {{groovy-all}}. All test references
> should be converted to JUnit 5, and TestNG should be excluded from all
> modules to avoid inadvertent references.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10898) Remove unused Test Servlets
[
https://issues.apache.org/jira/browse/NIFI-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10898:
Fix Version/s: 1.20.0
1.19.1
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Remove unused Test Servlets
> ---
>
> Key: NIFI-10898
> URL: https://issues.apache.org/jira/browse/NIFI-10898
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Trivial
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{nifi-standard-processors}} module has several Java Servlet classes that
> were used for unit testing HTTP processors. These classes are no longer used
> with current test classes, and new tests make use of OkHttp MockWebServer for
> HTTP testing. These unused test classes should be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643095#comment-17643095 ] Joe Witt commented on NIFI-10939: - Gonna mark as resolved and get the RC going now. > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10939. - Resolution: Fixed > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643094#comment-17643094 ] Joe Witt commented on NIFI-10939: - Once you commit that inner process group you now have the inner process group at the next version which is different than the version the parent PG was pointing at. Thus the parent needs to be committed as well to reflect this change if that is also desired. You have to keep in mind someone else might also be using that versioned parent process group on their flow and this mechanism needs to make all of that able to be in sync. This is an important part of this fairly complex nested versioned group mechanism. > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642760#comment-17642760 ] Joe Witt commented on NIFI-10939: - nevermind - this actually makes perfect sense. Outer shows no changes. Inner does. Then inner is committed Outer then shows changes while inner doesnt. That is the outer needing you to confirm you want the new inner. This is correct. > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642761#comment-17642761 ] Joe Witt commented on NIFI-10939: - please do confirm Mark. i'll hold for that confirmatoin to start RC2 > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642759#comment-17642759 ] Joe Witt commented on NIFI-10939: - [~thenatog]what if you refresh the browser/page? Does it still get into a funky state? > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt reopened NIFI-10939: - reopening based on Nathan's last comments > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10918) If NiFi Registry URL changes, flows containing inner versioned flows cannot be fetched
[
https://issues.apache.org/jira/browse/NIFI-10918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt resolved NIFI-10918.
-
Resolution: Fixed
> If NiFi Registry URL changes, flows containing inner versioned flows cannot
> be fetched
> --
>
> Key: NIFI-10918
> URL: https://issues.apache.org/jira/browse/NIFI-10918
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was performing some testing of integration with NiFi Registry. I started
> with an insecure registry running on
> [http://localhost:18080|http://localhost:18080/]
> I created a simple dataflow, called 'Inner Flow'. I then versioned it.
> Afterwards I put its parent Process Group ('Outer Flow') under Version
> Control.
> Everything worked as expected. I then wanted to verify that things still
> worked when secured. I secured my registry, changing the URL to
> [https://localhost:18443|https://localhost:18443/]
> Unfortunately, this resulted in no longer being able to check out the flow
> 'Outer Flow'. It failed because when the flow was created, it stored the
> coordinates of 'Inner Flow' as [http://localhost:18080/] but now it can
> no longer find any Registry Client that can handle
> [http://localhost:18080/...] since the client has now been reconfigured to
> use the HTTPS based URL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10918) If NiFi Registry URL changes, flows containing inner versioned flows cannot be fetched
[
https://issues.apache.org/jira/browse/NIFI-10918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10918:
Fix Version/s: 1.19.1
> If NiFi Registry URL changes, flows containing inner versioned flows cannot
> be fetched
> --
>
> Key: NIFI-10918
> URL: https://issues.apache.org/jira/browse/NIFI-10918
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was performing some testing of integration with NiFi Registry. I started
> with an insecure registry running on
> [http://localhost:18080|http://localhost:18080/]
> I created a simple dataflow, called 'Inner Flow'. I then versioned it.
> Afterwards I put its parent Process Group ('Outer Flow') under Version
> Control.
> Everything worked as expected. I then wanted to verify that things still
> worked when secured. I secured my registry, changing the URL to
> [https://localhost:18443|https://localhost:18443/]
> Unfortunately, this resulted in no longer being able to check out the flow
> 'Outer Flow'. It failed because when the flow was created, it stored the
> coordinates of 'Inner Flow' as [http://localhost:18080/] but now it can
> no longer find any Registry Client that can handle
> [http://localhost:18080/...] since the client has now been reconfigured to
> use the HTTPS based URL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10933) Upgrade OWASP Dependency Check to 7.3.2
[ https://issues.apache.org/jira/browse/NIFI-10933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10933: Fix Version/s: 1.19.1 > Upgrade OWASP Dependency Check to 7.3.2 > --- > > Key: NIFI-10933 > URL: https://issues.apache.org/jira/browse/NIFI-10933 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The OWASP Maven Dependency Check Plugin should be up upgraded to version > 7.3.2, which includes corrections for a number of false positive findings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10925) Intermittent Failures in TestPutSFTP.testRunZeroByteFile
[
https://issues.apache.org/jira/browse/NIFI-10925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10925:
Fix Version/s: 1.19.1
> Intermittent Failures in TestPutSFTP.testRunZeroByteFile
>
>
> Key: NIFI-10925
> URL: https://issues.apache.org/jira/browse/NIFI-10925
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Project builds can fail intermittently on
> {{TestPutSFTP.testRunZeroByteFile()}} with the following error:
> {noformat}
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.456
> s <<< FAILURE! - in org.apache.nifi.processors.standard.TestPutSFTP
> [ERROR] org.apache.nifi.processors.standard.TestPutSFTP.testRunZeroByteFile
> Time elapsed: 0.052 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <1> but was: <0>
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at
> org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:395)
> at
> org.apache.nifi.processors.standard.TestPutSFTP.testRunZeroByteFile(TestPutSFTP.java:119)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10939. - Fix Version/s: 1.20.0 1.19.1 Resolution: Fixed > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10936) Upgrade bcprov-jdk18on to 1.72
[ https://issues.apache.org/jira/browse/NIFI-10936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642601#comment-17642601 ] Joe Witt commented on NIFI-10936: - thanks Mike > Upgrade bcprov-jdk18on to 1.72 > -- > > Key: NIFI-10936 > URL: https://issues.apache.org/jira/browse/NIFI-10936 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Priority: Major > > Upgrade bcprov-jdk18on to 1.72 from 1.71 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10936) Upgrade bcprov-jdk18on to 1.72
[ https://issues.apache.org/jira/browse/NIFI-10936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642589#comment-17642589 ] Joe Witt commented on NIFI-10936: - [~msr1716]this is a really good example of the danger of bumping versions with the hope/belief that projects follow things like semantic versioning. For some you can count on it but for many, including many important ones, we cannot. What I'd ask is that in addition to flagging opportunities to change from one version to another you please include some findings on what the documentation for these releases say. It is mentioned in bouncycastle pages what David is talking about and indeed we found the size change to be shocking (happily in their next release we're going to be ok again it seems). Thanks > Upgrade bcprov-jdk18on to 1.72 > -- > > Key: NIFI-10936 > URL: https://issues.apache.org/jira/browse/NIFI-10936 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Priority: Major > > Upgrade bcprov-jdk18on to 1.72 from 1.71 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10919) Regression in SCRAM SASL Mechanism handling in Kafka Processors
[
https://issues.apache.org/jira/browse/NIFI-10919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10919:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Regression in SCRAM SASL Mechanism handling in Kafka Processors
> ---
>
> Key: NIFI-10919
> URL: https://issues.apache.org/jira/browse/NIFI-10919
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.19.0
>Reporter: Anders
>Assignee: David Handermann
>Priority: Critical
> Fix For: 1.19.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Just attempted to upgrade from version 1.17.0 to 1.19.0, and I'm now getting
> the following error message in ConsumeKafkaRecord_2_6:
> {code}
> 2022-12-01 13:16:31,886 ERROR [Timer-Driven Process Thread-10]
> o.a.n.p.k.pubsub.ConsumeKafkaRecord_2_6
> ConsumeKafkaRecord_2_6[id=8cd134b7-ae49-19d2--7edbb2f4] Processing
> halted: yielding [1 sec]
> java.lang.IllegalArgumentException: No enum constant
> org.apache.nifi.kafka.shared.property.SaslMechanism.SCRAM-SHA-512
> at java.base/java.lang.Enum.valueOf(Enum.java:240)
> at
> org.apache.nifi.kafka.shared.property.SaslMechanism.valueOf(SaslMechanism.java:24)
> at
> org.apache.nifi.kafka.shared.login.DelegatingLoginConfigProvider.getConfiguration(DelegatingLoginConfigProvider.java:50)
> at
> org.apache.nifi.kafka.shared.property.provider.StandardKafkaPropertyProvider.setSecurityProperties(StandardKafkaPropertyProvider.java:83)
> at
> org.apache.nifi.kafka.shared.property.provider.StandardKafkaPropertyProvider.getProperties(StandardKafkaPropertyProvider.java:72)
> at
> org.apache.nifi.processors.kafka.pubsub.ConsumeKafkaRecord_2_6.createConsumerPool(ConsumeKafkaRecord_2_6.java:427)
> at
> org.apache.nifi.processors.kafka.pubsub.ConsumeKafkaRecord_2_6.getConsumerPool(ConsumeKafkaRecord_2_6.java:399)
> at
> org.apache.nifi.processors.kafka.pubsub.ConsumeKafkaRecord_2_6.onTrigger(ConsumeKafkaRecord_2_6.java:519)
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1356)
> at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:246)
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> I'm guessing this might be related to
> https://issues.apache.org/jira/browse/NIFI-10819. I don't speak Java, but
> guessing it might further be related to
> https://github.com/apache/nifi/pull/6690/commits/23eac09f05354aa6775e8504fd94ca2bb8c44c62#diff-e3bf34d8321c19887e4e1d2d3474eccfeb55d13ee7f5efbcaaa8964813c2485aR31
> Should either the value be SCRAM_SHA_512 or the name of the
> property/variable/whateveritsnamedinjava be SCRAM-SHA-512?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10918) If NiFi Registry URL changes, flows containing inner versioned flows cannot be fetched
[
https://issues.apache.org/jira/browse/NIFI-10918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10918:
Fix Version/s: (was: 1.19.1)
> If NiFi Registry URL changes, flows containing inner versioned flows cannot
> be fetched
> --
>
> Key: NIFI-10918
> URL: https://issues.apache.org/jira/browse/NIFI-10918
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.20.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I was performing some testing of integration with NiFi Registry. I started
> with an insecure registry running on
> [http://localhost:18080|http://localhost:18080/]
> I created a simple dataflow, called 'Inner Flow'. I then versioned it.
> Afterwards I put its parent Process Group ('Outer Flow') under Version
> Control.
> Everything worked as expected. I then wanted to verify that things still
> worked when secured. I secured my registry, changing the URL to
> [https://localhost:18443|https://localhost:18443/]
> Unfortunately, this resulted in no longer being able to check out the flow
> 'Outer Flow'. It failed because when the flow was created, it stored the
> coordinates of 'Inner Flow' as [http://localhost:18080/] but now it can
> no longer find any Registry Client that can handle
> [http://localhost:18080/...] since the client has now been reconfigured to
> use the HTTPS based URL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10912) Upgrade JSLT To 0.1.14
[ https://issues.apache.org/jira/browse/NIFI-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10912. - Resolution: Fixed > Upgrade JSLT To 0.1.14 > -- > > Key: NIFI-10912 > URL: https://issues.apache.org/jira/browse/NIFI-10912 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Upgrade JSLT dependencies to 0.1.14 from 0.1.13. Release notes: [Release > Release 0.1.14: Bug fix · schibsted/jslt > (github.com)|https://github.com/schibsted/jslt/releases/tag/0.1.14] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10923) Upgrade Apache SSHD to 2.9.2
[ https://issues.apache.org/jira/browse/NIFI-10923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10923: Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Apache SSHD to 2.9.2 > > > Key: NIFI-10923 > URL: https://issues.apache.org/jira/browse/NIFI-10923 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > NiFi Standard Processors use Apache SSHD for testing SFTP components, and > NiFi Registry uses Apache SSHD as a transitive dependency of JGit. The > current version of NiFi references version 2.8.0 for standard processors, and > version 2.7.0 for Registry through JGit. JGit version 6 requires Java 11, so > upgrading JGit is not an option as of this writing. The transitive version > should be overridden and upgraded to 2.9.2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10912) Upgrade JSLT To 0.1.14
[ https://issues.apache.org/jira/browse/NIFI-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10912: Fix Version/s: 1.19.1 > Upgrade JSLT To 0.1.14 > -- > > Key: NIFI-10912 > URL: https://issues.apache.org/jira/browse/NIFI-10912 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Priority: Major > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Upgrade JSLT dependencies to 0.1.14 from 0.1.13. Release notes: [Release > Release 0.1.14: Bug fix · schibsted/jslt > (github.com)|https://github.com/schibsted/jslt/releases/tag/0.1.14] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10912) Upgrade JSLT To 0.1.14
[ https://issues.apache.org/jira/browse/NIFI-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10912: Fix Version/s: 1.20.0 > Upgrade JSLT To 0.1.14 > -- > > Key: NIFI-10912 > URL: https://issues.apache.org/jira/browse/NIFI-10912 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Priority: Major > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Upgrade JSLT dependencies to 0.1.14 from 0.1.13. Release notes: [Release > Release 0.1.14: Bug fix · schibsted/jslt > (github.com)|https://github.com/schibsted/jslt/releases/tag/0.1.14] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10923) Upgrade Apache SSHD to 2.9.2
[ https://issues.apache.org/jira/browse/NIFI-10923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10923: Fix Version/s: 1.20.0 1.19.1 > Upgrade Apache SSHD to 2.9.2 > > > Key: NIFI-10923 > URL: https://issues.apache.org/jira/browse/NIFI-10923 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > > NiFi Standard Processors use Apache SSHD for testing SFTP components, and > NiFi Registry uses Apache SSHD as a transitive dependency of JGit. The > current version of NiFi references version 2.8.0 for standard processors, and > version 2.7.0 for Registry through JGit. JGit version 6 requires Java 11, so > upgrading JGit is not an option as of this writing. The transitive version > should be overridden and upgraded to 2.9.2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10177) Nifi Registry logout via OIDC
[
https://issues.apache.org/jira/browse/NIFI-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt resolved NIFI-10177.
-
Resolution: Fixed
> Nifi Registry logout via OIDC
> -
>
> Key: NIFI-10177
> URL: https://issues.apache.org/jira/browse/NIFI-10177
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.16.3
>Reporter: kim myungwon
>Assignee: Emilio Setiadarma
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Attachments: image-2022-06-29-12-41-52-164.png,
> image-2022-06-29-12-42-48-430.png, image-2022-06-29-12-43-25-441.png,
> image-2022-06-29-12-43-48-726.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I am trying to login and logout via {*}OIDC{*}.
> Login via OIDC is well. but *{color:#de350b}logout via OIDC is not
> working.{color}*
>
> {color:#172b4d}When I logout, NiFi Registry shows "Please contact your System
> Administrator." error message.{color}
> !image-2022-06-29-12-41-52-164.png|width=1134,height=213!
>
> nifi-registry-app.log (debug level)
> {code:java}
> 022-06-29 13:32:35,691 DEBUG [NiFi Registry Web Server-15]
> o.a.nifi.registry.db.DatabaseKeyService Deleting key with identity='myungwon'.
> 2022-06-29 13:32:35,697 INFO [NiFi Registry Web Server-15]
> o.a.n.r.w.s.a.jwt.JwtService Deleted token from database.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> X509IdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in
> request.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> JwtIdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.s.a.BearerAuthIdentityProvider HTTP Bearer Auth credentials not
> present. Not attempting to extract credentials for authentication.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.AnonymousIdentityFilter Set SecurityContextHolder to anonymous
> SecurityContext
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.ResourceAuthorizationFilter Request filter authorization check
> is not required for this HTTP Method on this resource. Allowing request to
> proceed. An additional authorization check might be performed downstream of
> this filter.
> 2022-06-29 13:32:35,799 INFO [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException:
> Kerberos service ticket login not supported by this NiFi Registry. Returning
> Conflict response.
> 2022-06-29 13:32:35,799 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper
> java.lang.IllegalStateException: Kerberos service ticket login not supported
> by this NiFi Registry
> at
> org.apache.nifi.registry.web.api.AccessResource.createAccessTokenUsingKerberosTicket(AccessResource.java:348)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81)
> at
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
> at
[jira] [Updated] (NIFI-10177) Nifi Registry logout via OIDC
[
https://issues.apache.org/jira/browse/NIFI-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10177:
Fix Version/s: 1.20.0
1.19.1
> Nifi Registry logout via OIDC
> -
>
> Key: NIFI-10177
> URL: https://issues.apache.org/jira/browse/NIFI-10177
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.16.3
>Reporter: kim myungwon
>Assignee: Emilio Setiadarma
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Attachments: image-2022-06-29-12-41-52-164.png,
> image-2022-06-29-12-42-48-430.png, image-2022-06-29-12-43-25-441.png,
> image-2022-06-29-12-43-48-726.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I am trying to login and logout via {*}OIDC{*}.
> Login via OIDC is well. but *{color:#de350b}logout via OIDC is not
> working.{color}*
>
> {color:#172b4d}When I logout, NiFi Registry shows "Please contact your System
> Administrator." error message.{color}
> !image-2022-06-29-12-41-52-164.png|width=1134,height=213!
>
> nifi-registry-app.log (debug level)
> {code:java}
> 022-06-29 13:32:35,691 DEBUG [NiFi Registry Web Server-15]
> o.a.nifi.registry.db.DatabaseKeyService Deleting key with identity='myungwon'.
> 2022-06-29 13:32:35,697 INFO [NiFi Registry Web Server-15]
> o.a.n.r.w.s.a.jwt.JwtService Deleted token from database.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> X509IdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in
> request.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> JwtIdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.s.a.BearerAuthIdentityProvider HTTP Bearer Auth credentials not
> present. Not attempting to extract credentials for authentication.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.AnonymousIdentityFilter Set SecurityContextHolder to anonymous
> SecurityContext
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.ResourceAuthorizationFilter Request filter authorization check
> is not required for this HTTP Method on this resource. Allowing request to
> proceed. An additional authorization check might be performed downstream of
> this filter.
> 2022-06-29 13:32:35,799 INFO [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException:
> Kerberos service ticket login not supported by this NiFi Registry. Returning
> Conflict response.
> 2022-06-29 13:32:35,799 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper
> java.lang.IllegalStateException: Kerberos service ticket login not supported
> by this NiFi Registry
> at
> org.apache.nifi.registry.web.api.AccessResource.createAccessTokenUsingKerberosTicket(AccessResource.java:348)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81)
> at
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
> at
[jira] [Updated] (NIFI-10845) JsonQueryElasticsearch processors are not outputting an empty flow file for a combined response with output_no_hits set to true
[ https://issues.apache.org/jira/browse/NIFI-10845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10845: Fix Version/s: 1.19.1 > JsonQueryElasticsearch processors are not outputting an empty flow file for a > combined response with output_no_hits set to true > > > Key: NIFI-10845 > URL: https://issues.apache.org/jira/browse/NIFI-10845 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.18.0 >Reporter: Ryan >Priority: Major > Fix For: 1.20.0, 1.19.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > If you set OUTPUT_NO_HITS to 'true' and SEARCH_RESULTS_SPLIT to 'Per Query' > it does not output an empty flow file if no hits are found. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10882) ElasticSearchClientService should not allow both BASIC and API_KEY properties to be set simultaneously
[
https://issues.apache.org/jira/browse/NIFI-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10882:
Fix Version/s: 1.19.1
> ElasticSearchClientService should not allow both BASIC and API_KEY properties
> to be set simultaneously
> --
>
> Key: NIFI-10882
> URL: https://issues.apache.org/jira/browse/NIFI-10882
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Chris Sampson
>Assignee: Chris Sampson
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While the {{ElasticSearchClientService}} will show/hide Controller Service
> properties based on the currently selected {{AuthorizationScheme}}, it is
> possible for a user to set {{BASIC}} credentials (e.g.
> {{Username}}/{{Password}}) then later switch to {{API_KEY}} auth without
> removing the {{BASIC}} properties - this leads to multiple {{Authorization}}
> headers being configured in requests to Elasticsearch, which is unexpected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10874) Multiple levels of versioned flows might not able to load from repository
[ https://issues.apache.org/jira/browse/NIFI-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10874: Fix Version/s: 1.19.1 > Multiple levels of versioned flows might not able to load from repository > - > > Key: NIFI-10874 > URL: https://issues.apache.org/jira/browse/NIFI-10874 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Fix For: 1.20.0, 1.19.1 > > Time Spent: 50m > Remaining Estimate: 0h > > With the refactoring of the registry (changing it to a component), several > necessary change was done, including the "generification" of the way included > versioned flows are handled (recognised). > Previous implementation was depending on an URI, which was not descriptive > enough for the new concept. Storage location has been introduced and now > registry client implementations are capable for determine if they are capable > to load a given flow based on this. > As a fallback mechanism, the URI was kept for the NiFiRegistry based > implementation. A bug has been introduced with this mechanism, namely: the > ProcessGroupResouce#createProcessGroup method works with version information > from the UI, which has no knowledge of this. In order to guarantee that the > given information is stored during flow creation (here: loading flow from > external source) we need to guarantee the transition of this information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-7190) CaptureChangeMySQL processor doesn't emit DDL events if SQL statement begins with a comment
[
https://issues.apache.org/jira/browse/NIFI-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-7190:
---
Fix Version/s: 1.19.1
> CaptureChangeMySQL processor doesn't emit DDL events if SQL statement begins
> with a comment
> ---
>
> Key: NIFI-7190
> URL: https://issues.apache.org/jira/browse/NIFI-7190
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.2
>Reporter: Przemyslaw Dubaniewicz
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Minor
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The existing check for DDL Events doesn't take into account SQL statements
> that begin with a comment, in file:
> _nifi/nifi-nar-bundles/nifi-cdc/nifi-cdc-mysql-bundle/nifi-cdc-mysql-processors/src/main/java/org/apache/nifi/cdc/mysql/processors/CaptureChangeMySQL.java:821_
> {code:java}
> // Check for DDL events (alter table, e.g.). Normalize the query to do string
> matching on the type of change
> String normalizedQuery = sql.toLowerCase().trim().replaceAll(" {2,}", " ");
> if (normalizedQuery.startsWith("alter table")
> || normalizedQuery.startsWith("alter ignore table")
> || normalizedQuery.startsWith("create table")
> || normalizedQuery.startsWith("truncate table")
> || normalizedQuery.startsWith("rename table")
> || normalizedQuery.startsWith("drop table")
> || normalizedQuery.startsWith("drop database")) {code}
> SQL commands such as:
> {code:sql}
> /* ApplicationName=DataGrip 2019.2.4 */ alter table test_table
> drop column test_column
> {code}
> won't evaluate to true.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-6428) CaptureChangeMySQL throws IOException with BIGIN event due to lingering 'inTransaction' instance variable
[ https://issues.apache.org/jira/browse/NIFI-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-6428: --- Fix Version/s: 1.19.1 > CaptureChangeMySQL throws IOException with BIGIN event due to lingering > 'inTransaction' instance variable > - > > Key: NIFI-6428 > URL: https://issues.apache.org/jira/browse/NIFI-6428 > Project: Apache NiFi > Issue Type: Bug >Reporter: Koji Kawamura >Priority: Major > Fix For: 1.20.0, 1.19.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Because of not clearing 'inTransaction' instance variable when the processor > stops, when a user clears processor state and restart it with a specific > initial binlog position, then if BEGIN event is received, the processor > throws an IOException. > The processor should reset 'inTransaction' to false, and also other instance > variables when it start with an empty processor state. > The issue was reported at NiFi user ML. > [https://mail-archives.apache.org/mod_mbox/nifi-users/201907.mbox/%3C2019070919385393266224%40geekplus.com.cn%3E] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10871) Intermittent CSRF HTTP 403 in Clustered Deployments
[
https://issues.apache.org/jira/browse/NIFI-10871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10871:
Fix Version/s: 1.19.1
> Intermittent CSRF HTTP 403 in Clustered Deployments
>
>
> Key: NIFI-10871
> URL: https://issues.apache.org/jira/browse/NIFI-10871
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI, Security
>Affects Versions: 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.18.0
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> NiFi 1.14.0 introduced Cross-Site Request Forgery mitigation as part of
> updates to support JSON Web Token resolution using HttpOnly Session cookies.
> The standard Spring Security
> [CsrfFilter|https://github.com/spring-projects/spring-security/blob/5.7.5/web/src/main/java/org/springframework/security/web/csrf/CsrfFilter.java]
> includes a Request Matcher property to control whether filtering operations
> should be applied, but the CsrfFilter checks the Request Matcher after
> generating and saving a new token.
> Standalone deployments of NiFi can reuse the CSRF Request Token when the HTTP
> request includes the value in a {{Cookie}} header, but the NiFi HTTP Request
> Replicator removes the CSRF Request Token cookie before sending the request
> to other cluster nodes.
> As a result of these implementation details, NiFi cluster nodes receiving
> replicated HTTP requests generate and return a new CSRF Request Token. The
> NiFi user interface receives the new CSRF Request Token and uses it to set
> the custom {{Request-Token}} HTTP Header on subsequent requests. This is not
> an issue for HTTP GET requests, but requests using methods such as POST, PUT,
> or DELETE can return an HTTP 403 Forbidden response from the Spring Security
> CsrfFilter due to receiving mismatched {{__Secure-Request-Token}} Cookie and
> {{Request-Token}} Header values.
> This issue is intermittent because it depends on the web browser
> simultaneously receiving an HTTP response with a new Secure-Request-Token
> Cookie while preparing to send a new HTTP request with a {{Request-Token}}
> Header that contains the value from the previously received cookie.
> Resolving the problem should include adjusting the behavior of the CsrfFilter
> to avoid setting a new cookie on requests that do not require filtering.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10834) TestPutSplunkHTTP Test Failures on NonDex
[
https://issues.apache.org/jira/browse/NIFI-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10834:
Fix Version/s: 1.19.1
> TestPutSplunkHTTP Test Failures on NonDex
> --
>
> Key: NIFI-10834
> URL: https://issues.apache.org/jira/browse/NIFI-10834
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
> Environment: openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
> Apache Maven 3.6.3;
>Reporter: Priyanka Awatramani
>Assignee: Priyanka Awatramani
>Priority: Trivial
> Fix For: 1.20.0, 1.19.1
>
> Attachments: image-2022-11-16-15-34-06-074.png,
> image-2022-11-16-15-36-02-621.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The test
> *org.apache.nifi.processors.splunk.TestPutSplunkHTTP.testHappyPathWithCustomQueryParameters*
> and
> *org.apache.nifi.processors.splunk.TestPutSplunkHTTP.testHappyPathWithCustomQueryParametersFromFlowFile*
> passed using normal maven-test, but showed Non-deterministic behavior under
> NonDex([https://github.com/TestingResearchIllinois/NonDex)] and thus failed.
> Some of the error messages are:
>
> !image-2022-11-16-15-34-06-074.png!
>
> !image-2022-11-16-15-36-02-621.png!
>
> and after some probing, I found the output from the test is not deterministic
> as the order of query parameters in the URL changes.
>
> Steps to reproduce the failure:
> Install Nondex([https://github.com/TestingResearchIllinois/NonDex)] in the
> environment.
> Then cd to nifi repository, and run the following:
> {code:java}
> mvn install -pl nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors
> -am -DskipTests
> mvn -pl nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.splunk.TestPutSplunkHTTP#testHappyPathWithCustomQueryParameters
>
> mvn -pl nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors
> edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.nifi.processors.splunk.TestPutSplunkHTTP#testHappyPathWithCustomQueryParametersFromFlowFile{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-5819) Support SQLServer sql_variant type
[
https://issues.apache.org/jira/browse/NIFI-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-5819:
---
Fix Version/s: 1.19.1
> Support SQLServer sql_variant type
> --
>
> Key: NIFI-5819
> URL: https://issues.apache.org/jira/browse/NIFI-5819
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
>Reporter: Charlie Meyer
>Assignee: Matt Burgess
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If i run a query using executesqlrecord against a mssql database such as
> {{SELECT SERVERPROPERTY ('ProductVersion') AS MajorVersion}} nifi logs the
> following stack trace:
> {code:java}
> { "cause": { "cause": null, "stackTrace": [ { "methodName": "createSchema",
> "fileName": "JdbcCommon.java", "lineNumber": 677, "className":
> "org.apache.nifi.processors.standard.util.JdbcCommon", "nativeMethod": false
> }, { "methodName": "writeResultSet", "fileName": "RecordSqlWriter.java",
> "lineNumber": 68, "className":
> "org.apache.nifi.processors.standard.sql.RecordSqlWriter", "nativeMethod":
> false }, { "methodName": "lambda$onTrigger$1", "fileName":
> "ExecuteSqlRecordWithoutSwallowingErrors.java", "lineNumber": 362,
> "className":
> "com.civitaslearning.collect.nifi.processor.ExecuteSqlRecordWithoutSwallowingErrors",
> "nativeMethod": false }, { "methodName": "write", "fileName":
> "StandardProcessSession.java", "lineNumber": 2648, "className":
> "org.apache.nifi.controller.repository.StandardProcessSession",
> "nativeMethod": false }, { "methodName": "onTrigger", "fileName":
> "ExecuteSqlRecordWithoutSwallowingErrors.java", "lineNumber": 360,
> "className":
> "com.civitaslearning.collect.nifi.processor.ExecuteSqlRecordWithoutSwallowingErrors",
> "nativeMethod": false }, { "methodName": "onTrigger", "fileName":
> "AbstractProcessor.java", "lineNumber": 27, "className":
> "org.apache.nifi.processor.AbstractProcessor", "nativeMethod": false }, {
> "methodName": "onTrigger", "fileName": "StandardProcessorNode.java",
> "lineNumber": 1165, "className":
> "org.apache.nifi.controller.StandardProcessorNode", "nativeMethod": false },
> { "methodName": "invoke", "fileName": "ConnectableTask.java", "lineNumber":
> 203, "className": "org.apache.nifi.controller.tasks.ConnectableTask",
> "nativeMethod": false }, { "methodName": "run", "fileName":
> "TimerDrivenSchedulingAgent.java", "lineNumber": 117, "className":
> "org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1",
> "nativeMethod": false }, { "methodName": "call", "fileName":
> "Executors.java", "lineNumber": 511, "className":
> "java.util.concurrent.Executors$RunnableAdapter", "nativeMethod": false }, {
> "methodName": "runAndReset", "fileName": "FutureTask.java", "lineNumber":
> 308, "className": "java.util.concurrent.FutureTask", "nativeMethod": false },
> { "methodName": "access$301", "fileName": "ScheduledThreadPoolExecutor.java",
> "lineNumber": 180, "className":
> "java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask",
> "nativeMethod": false }, { "methodName": "run", "fileName":
> "ScheduledThreadPoolExecutor.java", "lineNumber": 294, "className":
> "java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask",
> "nativeMethod": false }, { "methodName": "runWorker", "fileName":
> "ThreadPoolExecutor.java", "lineNumber": 1149, "className":
> "java.util.concurrent.ThreadPoolExecutor", "nativeMethod": false }, {
> "methodName": "run", "fileName": "ThreadPoolExecutor.java", "lineNumber":
> 624, "className": "java.util.concurrent.ThreadPoolExecutor$Worker",
> "nativeMethod": false }, { "methodName": "run", "fileName": "Thread.java",
> "lineNumber": 748, "className": "java.lang.Thread", "nativeMethod": false }
> ], "message": "createSchema: Unknown SQL type -156 / sql_variant (table:
> NiFi_ExecuteSQL_Record, column: MajorVersion) cannot be converted to Avro
> type", "localizedMessage": "createSchema: Unknown SQL type -156 / sql_variant
> (table: NiFi_ExecuteSQL_Record, column: MajorVersion) cannot be converted to
> Avro type", "suppressed": [] }, "stackTrace": [ { "methodName":
> "lambda$onTrigger$1", "fileName":
> "ExecuteSqlRecordWithoutSwallowingErrors.java", "lineNumber": 364,
> "className":
> "com.civitaslearning.collect.nifi.processor.ExecuteSqlRecordWithoutSwallowingErrors",
> "nativeMethod": false }, { "methodName": "write", "fileName":
> "StandardProcessSession.java", "lineNumber": 2648, "className":
> "org.apache.nifi.controller.repository.StandardProcessSession",
> "nativeMethod": false }, { "methodName": "onTrigger", "fileName":
> "ExecuteSqlRecordWithoutSwallowingErrors.java", "lineNumber": 360,
> "className":
>
[jira] [Updated] (NIFI-10873) GenerateFlowFile: flowfiles in a batch are not unique
[ https://issues.apache.org/jira/browse/NIFI-10873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10873: Fix Version/s: 1.19.1 > GenerateFlowFile: flowfiles in a batch are not unique > - > > Key: NIFI-10873 > URL: https://issues.apache.org/jira/browse/NIFI-10873 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.19.0 >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > Time Spent: 40m > Remaining Estimate: 0h > > When GenerateFlowFile is configured to generate unique flowfiles, the > flowfiles aren't unique in case the batch size is greater than one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10910) Update amqp-client to 5.16.0
[ https://issues.apache.org/jira/browse/NIFI-10910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10910: Fix Version/s: 1.19.1 > Update amqp-client to 5.16.0 > > > Key: NIFI-10910 > URL: https://issues.apache.org/jira/browse/NIFI-10910 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.0 >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Update ampq-client from 5.15.0 to 5.16.0. [Releases · > rabbitmq/rabbitmq-java-client > (github.com)|https://github.com/rabbitmq/rabbitmq-java-client/releases] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10886) Upgrade PostgreSQL JDBC Driver to 42.4.3
[ https://issues.apache.org/jira/browse/NIFI-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10886: Fix Version/s: 1.19.1 > Upgrade PostgreSQL JDBC Driver to 42.4.3 > > > Key: NIFI-10886 > URL: https://issues.apache.org/jira/browse/NIFI-10886 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry, Tools and Build >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The PostgreSQL JDBC Driver used for NiFi Registry integration tests should be > upgraded to 42.4.3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10872) Fix broken Java Mail links in ConsumeIMAP and ConsumePOP3 documentation
[ https://issues.apache.org/jira/browse/NIFI-10872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10872: Fix Version/s: 1.19.1 > Fix broken Java Mail links in ConsumeIMAP and ConsumePOP3 documentation > --- > > Key: NIFI-10872 > URL: https://issues.apache.org/jira/browse/NIFI-10872 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Nandor Soma Abonyi >Assignee: Nandor Soma Abonyi >Priority: Minor > Labels: docuentation > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Java mail project moved from [https://javaee.github.io/javamail/] to > [https://jakartaee.github.io/mail-api/] because it was moved to the Eclipse > Foundation as part of the [Eclipse Enterprise for > Java|https://projects.eclipse.org/projects/ee4j] project. > Links on the new project pages are broken, so we need to use the old site. > Unfortunately, the documentation is not versioned there, so we need to use > the "latest", which might list properties that are not supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10891) TestMergeContent.testDefragmentMultipleMingledSegments uses non-deterministic HashMap
[
https://issues.apache.org/jira/browse/NIFI-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10891:
Fix Version/s: 1.19.1
> TestMergeContent.testDefragmentMultipleMingledSegments uses non-deterministic
> HashMap
> --
>
> Key: NIFI-10891
> URL: https://issues.apache.org/jira/browse/NIFI-10891
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Sopan Phaltankar
>Assignee: Sopan Phaltankar
>Priority: Trivial
> Fix For: 1.20.0, 1.19.1
>
> Attachments: org.apache.nifi.processors.standard.TestMergeContent.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.processors.standard.TestMergeContent{code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.
> The test shows below:
> {code:java}
> [ERROR] Failures:
> [ERROR] TestMergeContent.testDefragmentMultipleMingledSegments:1028
> FlowFile content differs from input at byte 0 with input having value 65 and
> FlowFile having value 78
> {code}
> *Steps to reproduce the failure:*
> # Run the following command in nifi:
> # First, build the module:
> {noformat}
> mvn clean install -pl
> nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors -DskipTests
> -Drat.skip -am {noformat}
> # Then run the test using
> [NonDex|https://github.com/TestingResearchIllinois/NonDex]
> {noformat}
> mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex -pl
> nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors
> -Dtest=org.apache.nifi.processors.standard.TestMergeContent#testDefragmentMultipleMingledSegments{noformat}
> The result will be saved under the module folder in .nondex
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10765) Add better error reporting for JASN1Reader
[ https://issues.apache.org/jira/browse/NIFI-10765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10765: Fix Version/s: 1.19.1 > Add better error reporting for JASN1Reader > -- > > Key: NIFI-10765 > URL: https://issues.apache.org/jira/browse/NIFI-10765 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 1.20.0, 1.19.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The JASN1Reader relies on https://github.com/beanit/asn1bean to compile ASN > schema files and to deserialize ASN data files. > The schema compilation step can fail for many different reasons and the error > is not reported to the user properly (or in any way really) so understanding > and fixing errors in the schema file is very hard currently. > We should report meaningful error messages to the bulletin and/or the > controller service validation error indicator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10890) TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved uses non-deterministic HashMap
[
https://issues.apache.org/jira/browse/NIFI-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10890:
Fix Version/s: 1.19.1
> TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved uses
> non-deterministic HashMap
>
>
> Key: NIFI-10890
> URL: https://issues.apache.org/jira/browse/NIFI-10890
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Sopan Phaltankar
>Assignee: Sopan Phaltankar
>Priority: Trivial
> Fix For: 1.20.0, 1.19.1
>
> Attachments: org.apache.nifi.json.TestJsonTreeRowRecordReader.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.json.TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved{code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.
> The test shows below:
> {code:java}
> [ERROR]
> TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved:433
> expected: City, state=MS, zipCode=1, country=USA,
> account=MapRecord[{balance=4750.89, id=42}]}]> but was: name=John Doe, address=123 My Street, city=My City, state=MS, zipCode=1,
> country=USA, account=MapRecord[{id=42, balance=4750.89}]}]>{code}
> *Steps to reproduce the failure:*
> # Run the following command in nifi:
> # First, build the module:
> {noformat}
> mvn install -pl
> nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services
> -DskipTests -Drat.skip -am{noformat}
> # Then run the test using
> [NonDex|https://github.com/TestingResearchIllinois/NonDex]
> {noformat}
> mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex -pl
> nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services
>
> -Dtest=org.apache.nifi.json.TestJsonTreeRowRecordReader#testReadRawRecordFieldOrderPreserved
> {noformat}
> The result will be saved under the module folder in .nondex
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10875) Test org.apache.nifi.processors.solr.TestQuerySolr.testAttributes Fails on NonDex
[
https://issues.apache.org/jira/browse/NIFI-10875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10875:
Fix Version/s: 1.19.1
> Test org.apache.nifi.processors.solr.TestQuerySolr.testAttributes Fails on
> NonDex
> -
>
> Key: NIFI-10875
> URL: https://issues.apache.org/jira/browse/NIFI-10875
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Yichen
>Assignee: Yichen
>Priority: Trivial
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.processors.solr.TestQuerySolr.testAttributes {code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.The
> test shows below:
>
> {code:java}
> ---
> Test set: org.apache.nifi.processors.solr.TestQuerySolr
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.426 s <<<
> FAILURE! - in org.apache.nifi.processors.solr.TestQuerySolr
> org.apache.nifi.processors.solr.TestQuerySolr.testAttributes Time elapsed:
> 0.205 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected:
> but was:
>
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1142)
> at
> org.apache.nifi.processors.solr.TestQuerySolr.testAttributes(TestQuerySolr.java:606)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
>
[jira] [Updated] (NIFI-10859) Update metrics-jvm to 4.1.33
[ https://issues.apache.org/jira/browse/NIFI-10859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10859: Fix Version/s: 1.19.1 > Update metrics-jvm to 4.1.33 > > > Key: NIFI-10859 > URL: https://issues.apache.org/jira/browse/NIFI-10859 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.18.0 >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Fix For: 1.20.0, 1.19.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update metrics-jvm to 4.2.13 from 4.1.2. It can be found at > /nifi-commons/nifi-metrics/pom.xml > release notes https://github.com/dropwizard/metrics/releases -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10895) MiNiFi C2 - Implement UPDATE/PROPERTIES command
[ https://issues.apache.org/jira/browse/NIFI-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10895: Fix Version/s: (was: 1.20.0) > MiNiFi C2 - Implement UPDATE/PROPERTIES command > --- > > Key: NIFI-10895 > URL: https://issues.apache.org/jira/browse/NIFI-10895 > Project: Apache NiFi > Issue Type: New Feature > Components: C2, MiNiFi >Reporter: Ferenc Erdei >Assignee: Ferenc Erdei >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Implement a UPDATE/PROPERTIES command which will allow the agent to update > bootstrap properties using the C2 protocol. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10850) Query Parameters property in InvokeAWSGatewayApi should support FlowFile attributes in EL
[ https://issues.apache.org/jira/browse/NIFI-10850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10850: Fix Version/s: 1.19.1 > Query Parameters property in InvokeAWSGatewayApi should support FlowFile > attributes in EL > - > > Key: NIFI-10850 > URL: https://issues.apache.org/jira/browse/NIFI-10850 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Minor > Labels: aws > Fix For: 1.20.0, 1.19.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Query Parameters property declares FlowFile Attributes support but it is not > handled in the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10866) Refactor Kafka 1.0 and 2.0 Components using nifi-kafka-shared
[
https://issues.apache.org/jira/browse/NIFI-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10866:
Fix Version/s: 1.19.1
> Refactor Kafka 1.0 and 2.0 Components using nifi-kafka-shared
> -
>
> Key: NIFI-10866
> URL: https://issues.apache.org/jira/browse/NIFI-10866
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Kafka 1.0 and 2.0 components should be refactored to use property and
> validation components in {{nifi-kafka-shared}}.
> This refactoring will reduce duplicate code and also bring additional
> security measures to the validation of custom sasl.jaas.config properties
> across all Kafka components
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10785) Allow publishing AMQP message with null header value
[ https://issues.apache.org/jira/browse/NIFI-10785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10785: Fix Version/s: 1.19.1 > Allow publishing AMQP message with null header value > > > Key: NIFI-10785 > URL: https://issues.apache.org/jira/browse/NIFI-10785 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Nandor Soma Abonyi >Assignee: Nandor Soma Abonyi >Priority: Minor > Labels: amqp > Fix For: 1.20.0, 1.19.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Since after NIFI-10317 ConsumeAMQP is able to handle null header value it > makes sense to support it in PublishAMQP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10887) Improve Performance of ReplaceText processor
[
https://issues.apache.org/jira/browse/NIFI-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10887:
Fix Version/s: (was: 1.20.0)
> Improve Performance of ReplaceText processor
>
>
> Key: NIFI-10887
> URL: https://issues.apache.org/jira/browse/NIFI-10887
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Labels: performance
> Attachments: ReplaceText-LiteralReplace-0msRunDuration.png,
> ReplaceText-LiteralReplace-25msRunDuration.png,
> ReplaceText-LiteralReplace-AfterChanges.png,
> ReplaceText-LiteralReplace-BeforeChanges.png,
> ReplaceText-RegexReplace-AfterChanges.png,
> ReplaceText-RegexReplace-BeforeChanges.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When performing some tests with the ReplaceText processor, I found that it
> seemed to be quite a bit slower than I expected, especially when using a
> Replacement Strategy of "Literal Replace" and when using a lot of small
> FlowFiles.
> As a result, I performed some profiling and identified a few areas that could
> use some improvement:
> * When using the Literal Replace strategy, we find matches using
> {{Pattern.compile(Pattern.quote(...));}} and then using
> {{{}Pattern.matcher(...).find(){}}}. This is quite inefficient compared to
> just using {{String.indexOf(...)}} and accounted for approximately 30% of the
> time spent in the processor.
> * A significant amount of time was spent flushing the write buffer, as it
> flushes to disk when finished writing to each individual FlowFile. Even when
> we set a Run Duration > 0 ms, we flush for each FlowFile. This flush() gets
> delegated all the way down to the FileOutputStream. However, when using
> ProcessSession.append(), we intercept this with a NonFlushableOutputStream.
> We should do this when calling ProcessSession.write() as well. While it makes
> sense to flush data from the Processor layer's buffer, there's no need to
> flush past the session layer until the session is committed.
> * A decent bit of time was spent in the session's get() method calling
> {{{}final Set set =
> unacknowledgedFlowFiles.computeIfAbsent(connection.getFlowFileQueue(), k ->
> new HashSet<>());{}}}. The time here was spent in StandardFlowFileQueue's
> hashCode() method, which is the JVM default. We can easily implement
> hashCode() to just return the hashCode of the identifier, which is a String.
> This is a pre-computed hashcode so provides constant time of 0 ms (with the
> exception of the method call itself) so eliminates the expense here.
> * When using a Run Duration > 0 ms, we can hold InputStreams open by
> processing multiple FlowFiles in a given Session. This can also significantly
> improve performance. As such, we should make the default run duration 25 ms
> instead of 0 ms.
> * A common pattern with ReplaceText is to prepend text to the beginning of a
> FlowFile, or line. And then use another ReplaceText to append text to the end
> of a FlowFile, or line. We should have a strategy for "Surround" that allow
> us to both Prepend text and Append text. This will result in double the
> performance for this use case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10888) Improve performance of Record Readers when inferring schema of small FlowFiles
[
https://issues.apache.org/jira/browse/NIFI-10888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10888:
Fix Version/s: (was: 1.20.0)
> Improve performance of Record Readers when inferring schema of small FlowFiles
> --
>
> Key: NIFI-10888
> URL: https://issues.apache.org/jira/browse/NIFI-10888
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Labels: performance
> Attachments: InferSchema-AfterChanges.png,
> InferSchema-BeforeChanges.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we infer the schema of a FlowFile, the Record Reader has to read all of
> the data in the FlowFile in order to infer the schema accurately. As a
> result, when we use a Record Reader, by default, we must parse the entire
> FlowFile, then seek back to the beginning of it, and parse the entire
> FlowFile again in order to return the records.
> It turns out that for smaller FlowFiles, the most expensive part of this
> cycle is actually seeking back to the beginning of the FlowFile (via
> {{{}InputStream.reset(){}}}). When {{InputStream.reset()}} is called, it
> closes the current InputStream and opens a new one, reading from the Content
> Repository again, causing a disk seek.
> Instead, if {{InputStream.mark()}} is called, we should use a
> BufferedInputStream under the hood, and if {{reset()}} is then called, we
> should call {{BufferedInputStream.reset()}} if the number of bytes consumed
> since mark is less than or equal to the read limit. We should then use
> {{{}InputStream.mark(1024 * 1024){}}}.
> Effectively, we should buffer up to 1 MB worth of content when inferring a
> schema. As a result, we can avoid that extra disk seek. For FlowFiles larger
> than 1 MB, this will not make a difference in performance. However, for
> larger FlowFiles it is less of a concern, simply because we are performing
> the seek less frequently (i.e., if we have 10 FlowFiles, each 50 MB vs. 1000
> FlowFiles each 5 KB, we end up seeking 100x less frequently in the case of
> larger FlowFiles).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10901) PublishKafka headers not sent in ProducerRecord
[ https://issues.apache.org/jira/browse/NIFI-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10901: Fix Version/s: 1.20.0 (was: 2.0.0) > PublishKafka headers not sent in ProducerRecord > --- > > Key: NIFI-10901 > URL: https://issues.apache.org/jira/browse/NIFI-10901 > Project: Apache NiFi > Issue Type: Bug >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Major > Fix For: 1.20.0, 1.19.1 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10901) PublishKafka headers not sent in ProducerRecord
[ https://issues.apache.org/jira/browse/NIFI-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10901: Fix Version/s: 2.0.0 1.19.1 > PublishKafka headers not sent in ProducerRecord > --- > > Key: NIFI-10901 > URL: https://issues.apache.org/jira/browse/NIFI-10901 > Project: Apache NiFi > Issue Type: Bug >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 2.0.0, 1.19.1 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10901) PublishKafka headers not sent in ProducerRecord
[ https://issues.apache.org/jira/browse/NIFI-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10901: Priority: Major (was: Minor) > PublishKafka headers not sent in ProducerRecord > --- > > Key: NIFI-10901 > URL: https://issues.apache.org/jira/browse/NIFI-10901 > Project: Apache NiFi > Issue Type: Bug >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Major > Fix For: 2.0.0, 1.19.1 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10914) Version information is not handled properly in case of clustered setup
[ https://issues.apache.org/jira/browse/NIFI-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10914: Fix Version/s: 1.20.0 1.19.1 > Version information is not handled properly in case of clustered setup > -- > > Key: NIFI-10914 > URL: https://issues.apache.org/jira/browse/NIFI-10914 > Project: Apache NiFi > Issue Type: Bug >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Blocker > Fix For: 1.20.0, 1.19.1 > > > When the NiFi runs in clustered mode, the already filled "statusLocation" is > being removed from the version information after creation. > - During adding a flow from registry (creating a process group from the > standpoint of NiFi) we do enrich the version control information with > storageLocation in order to be able to be reload it from registry in case it > will be part of a nested structure > - This information is being added, but in case of multiple nodes, the > information loses afterward > It looks like, the storageLocation is empty at in thee flow.xml and flow.json > and also it is not stored in the internal representation. Single node > environments do not suffer from this. > It is suspicious that the information loses during mergin in > VersionControlInformationEntityMerger -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10913) Release NiFi 1.19.1
Joe Witt created NIFI-10913: --- Summary: Release NiFi 1.19.1 Key: NIFI-10913 URL: https://issues.apache.org/jira/browse/NIFI-10913 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt Fix For: 1.19.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10890) TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved uses non-deterministic HashMap
[
https://issues.apache.org/jira/browse/NIFI-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10890:
Fix Version/s: (was: 1.19.0)
> TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved uses
> non-deterministic HashMap
>
>
> Key: NIFI-10890
> URL: https://issues.apache.org/jira/browse/NIFI-10890
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Sopan Phaltankar
>Assignee: Sopan Phaltankar
>Priority: Trivial
> Attachments: org.apache.nifi.json.TestJsonTreeRowRecordReader.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.json.TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved{code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.
> The test shows below:
> {code:java}
> [ERROR]
> TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved:433
> expected: City, state=MS, zipCode=1, country=USA,
> account=MapRecord[{balance=4750.89, id=42}]}]> but was: name=John Doe, address=123 My Street, city=My City, state=MS, zipCode=1,
> country=USA, account=MapRecord[{id=42, balance=4750.89}]}]>{code}
> *Steps to reproduce the failure:*
> # Run the following command in nifi:
> # First, build the module:
> {noformat}
> mvn install -pl
> nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services
> -DskipTests -Drat.skip -am{noformat}
> # Then run the test using
> [NonDex|https://github.com/TestingResearchIllinois/NonDex]
> {noformat}
> mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex -pl
> nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services
>
> -Dtest=org.apache.nifi.json.TestJsonTreeRowRecordReader#testReadRawRecordFieldOrderPreserved
> {noformat}
> The result will be saved under the module folder in .nondex
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10891) TestMergeContent.testDefragmentMultipleMingledSegments uses non-deterministic HashMap
[
https://issues.apache.org/jira/browse/NIFI-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640799#comment-17640799
]
Joe Witt commented on NIFI-10891:
-
[~sopan98]Please do not tag fix versions until a reviewer is landing the commit
on a given release line. They'll do that. But here you're tagging a release
which has already shipped. Thanks for contributing but please do be careful on
these values.
> TestMergeContent.testDefragmentMultipleMingledSegments uses non-deterministic
> HashMap
> --
>
> Key: NIFI-10891
> URL: https://issues.apache.org/jira/browse/NIFI-10891
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Sopan Phaltankar
>Assignee: Sopan Phaltankar
>Priority: Trivial
> Fix For: 1.19.0
>
> Attachments: org.apache.nifi.processors.standard.TestMergeContent.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.processors.standard.TestMergeContent{code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.
> The test shows below:
> {code:java}
> [ERROR] Failures:
> [ERROR] TestMergeContent.testDefragmentMultipleMingledSegments:1028
> FlowFile content differs from input at byte 0 with input having value 65 and
> FlowFile having value 78
> {code}
> *Steps to reproduce the failure:*
> # Run the following command in nifi:
> # First, build the module:
> {noformat}
> mvn clean install -pl
> nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors -DskipTests
> -Drat.skip -am {noformat}
> # Then run the test using
> [NonDex|https://github.com/TestingResearchIllinois/NonDex]
> {noformat}
> mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex -pl
> nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors
> -Dtest=org.apache.nifi.processors.standard.TestMergeContent#testDefragmentMultipleMingledSegments{noformat}
> The result will be saved under the module folder in .nondex
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10891) TestMergeContent.testDefragmentMultipleMingledSegments uses non-deterministic HashMap
[
https://issues.apache.org/jira/browse/NIFI-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10891:
Fix Version/s: (was: 1.19.0)
> TestMergeContent.testDefragmentMultipleMingledSegments uses non-deterministic
> HashMap
> --
>
> Key: NIFI-10891
> URL: https://issues.apache.org/jira/browse/NIFI-10891
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Sopan Phaltankar
>Assignee: Sopan Phaltankar
>Priority: Trivial
> Attachments: org.apache.nifi.processors.standard.TestMergeContent.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.processors.standard.TestMergeContent{code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.
> The test shows below:
> {code:java}
> [ERROR] Failures:
> [ERROR] TestMergeContent.testDefragmentMultipleMingledSegments:1028
> FlowFile content differs from input at byte 0 with input having value 65 and
> FlowFile having value 78
> {code}
> *Steps to reproduce the failure:*
> # Run the following command in nifi:
> # First, build the module:
> {noformat}
> mvn clean install -pl
> nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors -DskipTests
> -Drat.skip -am {noformat}
> # Then run the test using
> [NonDex|https://github.com/TestingResearchIllinois/NonDex]
> {noformat}
> mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex -pl
> nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors
> -Dtest=org.apache.nifi.processors.standard.TestMergeContent#testDefragmentMultipleMingledSegments{noformat}
> The result will be saved under the module folder in .nondex
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10890) TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved uses non-deterministic HashMap
[
https://issues.apache.org/jira/browse/NIFI-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640798#comment-17640798
]
Joe Witt commented on NIFI-10890:
-
[~sopan98]Please do not tag fix versions until a reviewer is landing the commit
on a given release line. They'll do that. But here you're tagging a release
which has already shipped. Thanks for contributing but please do be careful on
these values.
> TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved uses
> non-deterministic HashMap
>
>
> Key: NIFI-10890
> URL: https://issues.apache.org/jira/browse/NIFI-10890
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Environment: Apache Maven 3.6.0;
> openjdk version "1.8.0_342";
> OpenJDK Runtime Environment (build 1.8.0_342-8u342-b07-0ubuntu1~20.04-b07);
> OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode);
>Reporter: Sopan Phaltankar
>Assignee: Sopan Phaltankar
>Priority: Trivial
> Fix For: 1.19.0
>
> Attachments: org.apache.nifi.json.TestJsonTreeRowRecordReader.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> org.apache.nifi.json.TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved{code}
> This is a flaky test, it can pass mvn test while but when run using the tool
> [NonDex|https://github.com/TestingResearchIllinois/NonDex], it fails. NonDex
> is a tool that will introduce non-determinism in certain java collections.
> The test shows below:
> {code:java}
> [ERROR]
> TestJsonTreeRowRecordReader.testReadRawRecordFieldOrderPreserved:433
> expected: City, state=MS, zipCode=1, country=USA,
> account=MapRecord[{balance=4750.89, id=42}]}]> but was: name=John Doe, address=123 My Street, city=My City, state=MS, zipCode=1,
> country=USA, account=MapRecord[{id=42, balance=4750.89}]}]>{code}
> *Steps to reproduce the failure:*
> # Run the following command in nifi:
> # First, build the module:
> {noformat}
> mvn install -pl
> nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services
> -DskipTests -Drat.skip -am{noformat}
> # Then run the test using
> [NonDex|https://github.com/TestingResearchIllinois/NonDex]
> {noformat}
> mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex -pl
> nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services
>
> -Dtest=org.apache.nifi.json.TestJsonTreeRowRecordReader#testReadRawRecordFieldOrderPreserved
> {noformat}
> The result will be saved under the module folder in .nondex
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10854) Conduct Apache NiFi 1.19.0 Release
[ https://issues.apache.org/jira/browse/NIFI-10854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10854. - Resolution: Fixed > Conduct Apache NiFi 1.19.0 Release > -- > > Key: NIFI-10854 > URL: https://issues.apache.org/jira/browse/NIFI-10854 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
