[jira] [Updated] (NIFI-9878) DistributedCacheMap Handshake failure, processor hang indefinitely.
[ https://issues.apache.org/jira/browse/NIFI-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-9878: --- Fix Version/s: 1.18.0 > DistributedCacheMap Handshake failure, processor hang indefinitely. > --- > > Key: NIFI-9878 > URL: https://issues.apache.org/jira/browse/NIFI-9878 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.15.3, 1.17.0, 1.16.3 >Reporter: Aaron Rich >Assignee: Jon Shoemaker >Priority: Major > Labels: Handshake, distributed_cache > Fix For: 1.18.0 > > Attachments: > 0001-NIFI-9878-fix-for-hanging-client-thread-with-handsha.patch, > image-2022-04-05-21-54-31-002.png, image-2022-04-05-21-55-16-221.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When a DistributedCacheMapClient attempts to connect to a > DistributedCacheMapServer, but the handshake response is never received by > the client, the PutDistributedCacheMap processor with hang indefinitely. The > handshake never times out. > A situation like this can be caused if a proxy allows for the TCP connection > to be established between client and server but fails to deliver handshake > data to/from DistributedCacheMapServer (for example an unstable Istio service > mesh between the two). Could also happen if a client was accidentally > misconfigured to point to wrong TCP server point (one that wasn't hosting a > DistributedCacheMapServer. > Steps to recreate: > 1) Set up a PutDistributedCacheMap processor with a > DistributedMapCacheClientService > 2) Configure DistributedMapCacheClientService to point to a non > DistributedCacheMapServer tcp server (nc -lk 127.0.0.1 4457). This simulates > a situation where the socket connection can be made but there is no handshake > response from the server (for example, server is in bad state and unable to > respond, a proxy is misbehaving, etc). > 3) use generateFlowFile to trigger PutDistributedCacheMap processor. > 4) processor will hang with no failure or success. Processor will have to be > force terminated. > !image-2022-04-05-21-54-31-002.png! > !image-2022-04-05-21-55-16-221.png! > Hang occurs at : > CacheClientRequestHandler.java:92: handshakeHandler.waitHandshakeComplete(); > > Currently, the "connection timeout" parameter is only used to timeout the > establishment of the TCP socket connection, not the full application layer > connection. > Suggestion: > Handshake should have a timeout too to be robust to handle a network outage > where the TCP connection is able to be created, but the handshake data can't > be exchanged. The processor hanging prevents any way to handle this error in > a dataflow. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10559) PutSFTP remote path docs says it doesnt honor flowfile attributes but it does
Joe Witt created NIFI-10559: --- Summary: PutSFTP remote path docs says it doesnt honor flowfile attributes but it does Key: NIFI-10559 URL: https://issues.apache.org/jira/browse/NIFI-10559 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt Fix For: 1.18.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10558) NiFi Ranger support as well as NiFi Registry Ranger support needs to still build on ARM
[ https://issues.apache.org/jira/browse/NIFI-10558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610686#comment-17610686 ] Joe Witt commented on NIFI-10558: - Ok so what we want: - build the ranger components on any platform. - test the ranger components only on amd64 and intel64 which is what they support. - never include the ranger components in convenience builds unless manually activated to do so. We will not include them by default any longer. The artifacts are too huge. > NiFi Ranger support as well as NiFi Registry Ranger support needs to still > build on ARM > --- > > Key: NIFI-10558 > URL: https://issues.apache.org/jira/browse/NIFI-10558 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: David Handermann >Priority: Blocker > Fix For: 1.18.0 > > > Increasingly ARM based laptops are the norm on the Apple world. I am > attempting to do a release candidate this way in fact. > The ranger portions get skipped because Ranger testing requires particular > native libs. So it is understandable tests wont run. Further ranger > artifacts are *huge* so we dont want them in convenience binaries anymore. > But we should still be able to build properly and just skip ranger tests and > we should be able to have the poms properly automatically changed for > snapshot references during the release process. > The actual artifacts would still be workable as the correct native libs would > be loaded for a given supported environment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10381) Upgrade Azure Event Hubs Libraries to Version 5
[
https://issues.apache.org/jira/browse/NIFI-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10381:
Fix Version/s: 1.18.0
(was: 1.19.0)
> Upgrade Azure Event Hubs Libraries to Version 5
> ---
>
> Key: NIFI-10381
> URL: https://issues.apache.org/jira/browse/NIFI-10381
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.18.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Current Microsoft Azure documentation describes the Azure Event Hubs
> libraries in the {{com.microsoft.azure}} group as the legacy version of the
> SDK. Version 5 in the {{com.azure}} group is the current version and provides
> better integration with other current Azure libraries.
> The newer {{AzureEventHubRecordSink}} Controller Service is built on version
> 5, and existing Azure Event Hubs components should be migrated to version 5
> to streamline dependency management and integration.
> Upgrading to current version of the SDK provides an opportunity to merge the
> {{nifi-azure-record-sink-nar}} with the {{nifi-azure-nar}} and also leverage
> the [Azure SDK Bill of
> Materials|https://search.maven.org/artifact/com.azure/azure-sdk-bom/1.2.4/pom]
> dependency to ensure consistency across components and core libraries.
> The [Azure SDK Event Hubs Migration
> Guide|https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/eventhubs/azure-messaging-eventhubs/migration-guide.md]
> highlights the benefits of upgrading to version 5 and provides a comparison
> of implementation differences.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10558) NiFi Ranger support as well as NiFi Registry Ranger support needs to still build on ARM
[ https://issues.apache.org/jira/browse/NIFI-10558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10558: Priority: Blocker (was: Major) > NiFi Ranger support as well as NiFi Registry Ranger support needs to still > build on ARM > --- > > Key: NIFI-10558 > URL: https://issues.apache.org/jira/browse/NIFI-10558 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Priority: Blocker > > Increasingly ARM based laptops are the norm on the Apple world. I am > attempting to do a release candidate this way in fact. > The ranger portions get skipped because Ranger testing requires particular > native libs. So it is understandable tests wont run. Further ranger > artifacts are *huge* so we dont want them in convenience binaries anymore. > But we should still be able to build properly and just skip ranger tests and > we should be able to have the poms properly automatically changed for > snapshot references during the release process. > The actual artifacts would still be workable as the correct native libs would > be loaded for a given supported environment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10558) NiFi Ranger support as well as NiFi Registry Ranger support needs to still build on ARM
[ https://issues.apache.org/jira/browse/NIFI-10558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10558: Fix Version/s: 1.18.0 > NiFi Ranger support as well as NiFi Registry Ranger support needs to still > build on ARM > --- > > Key: NIFI-10558 > URL: https://issues.apache.org/jira/browse/NIFI-10558 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Priority: Blocker > Fix For: 1.18.0 > > > Increasingly ARM based laptops are the norm on the Apple world. I am > attempting to do a release candidate this way in fact. > The ranger portions get skipped because Ranger testing requires particular > native libs. So it is understandable tests wont run. Further ranger > artifacts are *huge* so we dont want them in convenience binaries anymore. > But we should still be able to build properly and just skip ranger tests and > we should be able to have the poms properly automatically changed for > snapshot references during the release process. > The actual artifacts would still be workable as the correct native libs would > be loaded for a given supported environment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10558) NiFi Ranger support as well as NiFi Registry Ranger support needs to still build on ARM
Joe Witt created NIFI-10558: --- Summary: NiFi Ranger support as well as NiFi Registry Ranger support needs to still build on ARM Key: NIFI-10558 URL: https://issues.apache.org/jira/browse/NIFI-10558 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Increasingly ARM based laptops are the norm on the Apple world. I am attempting to do a release candidate this way in fact. The ranger portions get skipped because Ranger testing requires particular native libs. So it is understandable tests wont run. Further ranger artifacts are *huge* so we dont want them in convenience binaries anymore. But we should still be able to build properly and just skip ranger tests and we should be able to have the poms properly automatically changed for snapshot references during the release process. The actual artifacts would still be workable as the correct native libs would be loaded for a given supported environment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10427) Add List-/Fetch Box processors
[ https://issues.apache.org/jira/browse/NIFI-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10427: Issue Type: New Feature (was: Task) > Add List-/Fetch Box processors > -- > > Key: NIFI-10427 > URL: https://issues.apache.org/jira/browse/NIFI-10427 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 1.18.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Add processor that are able list and fetch files from a given Box folder. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10553) MergeContent Prematurely Evicts Bins
[ https://issues.apache.org/jira/browse/NIFI-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10553: Fix Version/s: (was: 1.18.0) > MergeContent Prematurely Evicts Bins > > > Key: NIFI-10553 > URL: https://issues.apache.org/jira/browse/NIFI-10553 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.14.0, 1.16.3 >Reporter: Eric Secules >Priority: Major > > When NiFi's merge processors are configured to defragment, the user wants > flowfiles merged in a specific way according to the `fragment.` attributes. > Hoever, when MergeDocuments is handling many unique values for > `fragment.identifier` it opens up one bin per value until it reaches the > `MAX_BIN_COUNT` parameter configured on this processor. This parameter is > there to limit memory used by merging too many things all at once. It is not > certain that the user will be able to set this to an appropriate value for > every flow, and the consequence is that evicting a partially filled bin will > result in possible downstream issues and flowfiles stuck in the input > connection of MergeDocuments. > > Instead of this behaviour, the merge processor should penalize and requeue > flowfiles that don't fit in any of the existing bins if we have reached the > max number of bins already. Penalizing non-matching flowfiles will give time > for the ones needed to complete the existing bins to arrive. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10521) Conduct Apache NiFi 1.18.0 Release
[ https://issues.apache.org/jira/browse/NIFI-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10521: Summary: Conduct Apache NiFi 1.18.0 Release (was: Apache NiFi 1.18.0 RC1 RM) > Conduct Apache NiFi 1.18.0 Release > -- > > Key: NIFI-10521 > URL: https://issues.apache.org/jira/browse/NIFI-10521 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.18.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10552) Ranger CredentialBuilder throws NoClassDefFoundException
[
https://issues.apache.org/jira/browse/NIFI-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt resolved NIFI-10552.
-
Resolution: Fixed
> Ranger CredentialBuilder throws NoClassDefFoundException
>
>
> Key: NIFI-10552
> URL: https://issues.apache.org/jira/browse/NIFI-10552
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Zoltán Kornél Török
>Assignee: Zoltán Kornél Török
>Priority: Major
> Fix For: 1.18.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When try to create a ranger keystore/truststore I got the following exception:
> {code}
> java.lang.NoClassDefFoundError: org/apache/commons/lang3/StringUtils
> at
> org.apache.hadoop.metrics2.lib.MutableMetricsFactory.getName(MutableMetricsFactory.java:134)
> at
> org.apache.hadoop.metrics2.lib.MutableMetricsFactory.getInfo(MutableMetricsFactory.java:130)
> at
> org.apache.hadoop.metrics2.lib.MutableMetricsFactory.newForField(MutableMetricsFactory.java:45)
> at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder.add(MetricsSourceBuilder.java:147)
> at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder.(MetricsSourceBuilder.java:69)
> at
> org.apache.hadoop.metrics2.lib.MetricsAnnotations.newSourceBuilder(MetricsAnnotations.java:43)
> at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:223)
> at
> org.apache.hadoop.metrics2.MetricsSystem.register(MetricsSystem.java:71)
> at
> org.apache.hadoop.security.UserGroupInformation$UgiMetrics.create(UserGroupInformation.java:149)
> at
> org.apache.hadoop.security.UserGroupInformation.(UserGroupInformation.java:265)
> at
> org.apache.hadoop.fs.FileSystem$Cache$Key.(FileSystem.java:3614)
> at
> org.apache.hadoop.fs.FileSystem$Cache$Key.(FileSystem.java:3604)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:3441)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:524)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:365)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider.initFileSystem(JavaKeyStoreProvider.java:89)
> at
> org.apache.hadoop.security.alias.AbstractJavaKeyStoreProvider.(AbstractJavaKeyStoreProvider.java:85)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider.(JavaKeyStoreProvider.java:49)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider.(JavaKeyStoreProvider.java:41)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider$Factory.createProvider(JavaKeyStoreProvider.java:100)
> at
> org.apache.hadoop.security.alias.CredentialProviderFactory.getProviders(CredentialProviderFactory.java:73)
> at
> org.apache.ranger.credentialapi.CredentialReader.getDecryptedString(CredentialReader.java:74)
> at
> org.apache.ranger.credentialapi.buildks.createCredential(buildks.java:87)
> at org.apache.ranger.credentialapi.buildks.main(buildks.java:41)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
> ... 24 more
> {code}
> Command to reproduce:
> {code}
> java -cp "ext/ranger/install/lib/*" org.apache.ranger.credentialapi.buildks
> create sslTrustStore -value "test" -provider
> "jceks://file/<>/test2.jceks"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10552) Ranger CredentialBuilder throws NoClassDefFoundException
[
https://issues.apache.org/jira/browse/NIFI-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10552:
Fix Version/s: 1.18.0
> Ranger CredentialBuilder throws NoClassDefFoundException
>
>
> Key: NIFI-10552
> URL: https://issues.apache.org/jira/browse/NIFI-10552
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Zoltán Kornél Török
>Assignee: Zoltán Kornél Török
>Priority: Major
> Fix For: 1.18.0
>
>
> When try to create a ranger keystore/truststore I got the following exception:
> {code}
> java.lang.NoClassDefFoundError: org/apache/commons/lang3/StringUtils
> at
> org.apache.hadoop.metrics2.lib.MutableMetricsFactory.getName(MutableMetricsFactory.java:134)
> at
> org.apache.hadoop.metrics2.lib.MutableMetricsFactory.getInfo(MutableMetricsFactory.java:130)
> at
> org.apache.hadoop.metrics2.lib.MutableMetricsFactory.newForField(MutableMetricsFactory.java:45)
> at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder.add(MetricsSourceBuilder.java:147)
> at
> org.apache.hadoop.metrics2.lib.MetricsSourceBuilder.(MetricsSourceBuilder.java:69)
> at
> org.apache.hadoop.metrics2.lib.MetricsAnnotations.newSourceBuilder(MetricsAnnotations.java:43)
> at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:223)
> at
> org.apache.hadoop.metrics2.MetricsSystem.register(MetricsSystem.java:71)
> at
> org.apache.hadoop.security.UserGroupInformation$UgiMetrics.create(UserGroupInformation.java:149)
> at
> org.apache.hadoop.security.UserGroupInformation.(UserGroupInformation.java:265)
> at
> org.apache.hadoop.fs.FileSystem$Cache$Key.(FileSystem.java:3614)
> at
> org.apache.hadoop.fs.FileSystem$Cache$Key.(FileSystem.java:3604)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:3441)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:524)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:365)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider.initFileSystem(JavaKeyStoreProvider.java:89)
> at
> org.apache.hadoop.security.alias.AbstractJavaKeyStoreProvider.(AbstractJavaKeyStoreProvider.java:85)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider.(JavaKeyStoreProvider.java:49)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider.(JavaKeyStoreProvider.java:41)
> at
> org.apache.hadoop.security.alias.JavaKeyStoreProvider$Factory.createProvider(JavaKeyStoreProvider.java:100)
> at
> org.apache.hadoop.security.alias.CredentialProviderFactory.getProviders(CredentialProviderFactory.java:73)
> at
> org.apache.ranger.credentialapi.CredentialReader.getDecryptedString(CredentialReader.java:74)
> at
> org.apache.ranger.credentialapi.buildks.createCredential(buildks.java:87)
> at org.apache.ranger.credentialapi.buildks.main(buildks.java:41)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
> ... 24 more
> {code}
> Command to reproduce:
> {code}
> java -cp "ext/ranger/install/lib/*" org.apache.ranger.credentialapi.buildks
> create sslTrustStore -value "test" -provider
> "jceks://file/<>/test2.jceks"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10442) Create PutIceberg processor
[ https://issues.apache.org/jira/browse/NIFI-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610140#comment-17610140 ] Joe Witt commented on NIFI-10442: - Good work ongoing but going to punt from 1.18 and get the RC1 going. Certainly if this shows up I'll grab it > Create PutIceberg processor > --- > > Key: NIFI-10442 > URL: https://issues.apache.org/jira/browse/NIFI-10442 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Add a processor that is able to ingest data into Iceberg tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10442) Create PutIceberg processor
[ https://issues.apache.org/jira/browse/NIFI-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10442: Fix Version/s: (was: 1.18.0) > Create PutIceberg processor > --- > > Key: NIFI-10442 > URL: https://issues.apache.org/jira/browse/NIFI-10442 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Add a processor that is able to ingest data into Iceberg tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10289) PutDatabaseRecord generating incomplete Merge SQL when using Oracle12DatabaseAdapter
[
https://issues.apache.org/jira/browse/NIFI-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10289:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> PutDatabaseRecord generating incomplete Merge SQL when using
> Oracle12DatabaseAdapter
>
>
> Key: NIFI-10289
> URL: https://issues.apache.org/jira/browse/NIFI-10289
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.16.3
>Reporter: Eduardo Mota Fontes
>Assignee: Eduardo Mota Fontes
>Priority: Major
> Fix For: 1.18.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Processor PutDatabaseRecord is generating incomplete SQL statement when MERGE
> statement type for ORACLE12+.
> It isn't considering all Update Keys.
> I'm getting this SQL:
> {code:sql}
> MERGE INTO table USING (SELECT ? CASO, ? REFERENCIA_NOME, ?
> CASO_REFERENCIA_INDICA, 1 REFERENCIA_CODIGO FROM DUAL) n ON (table.CASO =
> n.CASO) WHEN NOT MATCHED THEN INSERT (CASO, REFERENCIA_NOME,
> CASO_REFERENCIA_INDICA, REFERENCIA_CODIGO) VALUES (n.CASO, n.REFERENCIA_NOME,
> n.CASO_REFERENCIA_INDICA, n.REFERENCIA_CODIGO) WHEN MATCHED THEN UPDATE SET
> table.REFERENCIA_NOME = n.REFERENCIA_NOME, table.CASO_REFERENCIA_INDICA =
> n.CASO_REFERENCIA_INDICA, table.REFERENCIA_CODIGO = n.REFERENCIA_CODIGO{code}
> Should be:
> {code:sql}
> MERGE INTO table USING (SELECT ? CASO, ? REFERENCIA_NOME, ?
> CASO_REFERENCIA_INDICA, 1 REFERENCIA_CODIGO FROM DUAL) n ON (table.CASO =
> n.CASO AND table.REFERENCIA_CODIGO = n.REFERENCIA_CODIGO) WHEN NOT MATCHED
> THEN INSERT (CASO, REFERENCIA_NOME, CASO_REFERENCIA_INDICA,
> REFERENCIA_CODIGO) VALUES (n.CASO, n.REFERENCIA_NOME,
> n.CASO_REFERENCIA_INDICA, n.REFERENCIA_CODIGO) WHEN MATCHED THEN UPDATE SET
> table.REFERENCIA_NOME = n.REFERENCIA_NOME, table.CASO_REFERENCIA_INDICA =
> n.CASO_REFERENCIA_INDICA{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10442) Create PutIceberg processor
[ https://issues.apache.org/jira/browse/NIFI-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609707#comment-17609707 ] Joe Witt commented on NIFI-10442: - Went to remove fix version but there is a ton of review/iteration going on so will give it another day or so to see if it makes it in. If necessary will remove fix version and get the RC going. > Create PutIceberg processor > --- > > Key: NIFI-10442 > URL: https://issues.apache.org/jira/browse/NIFI-10442 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Fix For: 1.18.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Add a processor that is able to ingest data into Iceberg tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10442) Create PutIceberg processor
[ https://issues.apache.org/jira/browse/NIFI-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10442: Fix Version/s: 1.18.0 > Create PutIceberg processor > --- > > Key: NIFI-10442 > URL: https://issues.apache.org/jira/browse/NIFI-10442 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Fix For: 1.18.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Add a processor that is able to ingest data into Iceberg tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10442) Create PutIceberg processor
[ https://issues.apache.org/jira/browse/NIFI-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10442: Fix Version/s: (was: 1.18.0) > Create PutIceberg processor > --- > > Key: NIFI-10442 > URL: https://issues.apache.org/jira/browse/NIFI-10442 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Add a processor that is able to ingest data into Iceberg tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10473) Parameter Provider Fetch REST call authorization check is too restrictive
[ https://issues.apache.org/jira/browse/NIFI-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10473. - Resolution: Fixed appears this was merged with the work for parameter providers > Parameter Provider Fetch REST call authorization check is too restrictive > - > > Key: NIFI-10473 > URL: https://issues.apache.org/jira/browse/NIFI-10473 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Joe Gresock >Assignee: Joe Gresock >Priority: Minor > Fix For: 1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When bringing up the Fetch Parameters dialog, if the user is not authorized > on any referencing component, the dialog fails to load. This is overly > restrictive, as NiFi already prevents applying the parameters in this > scenario. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609663#comment-17609663 ] Joe Witt commented on NIFI-10532: - yep this pr fixes this. But doesnt change how much I greatly dislike this feature :) It could never be efficient generally speaking. > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Assignee: Joe Witt >Priority: Critical > Fix For: 1.18.0 > > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10547) NiFi cluster is unstable with error "Administrative Yield Duration"
[ https://issues.apache.org/jira/browse/NIFI-10547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609528#comment-17609528 ] Joe Witt commented on NIFI-10547: - Hello. We will need more details about the configuration but specifically we will need the stack traces. This looks like a grep for ERROR in the logs but that will only take the first thing. We need the stacks that follow. There is clearly an issue with the Cassandra QL processor. This being NiFi 1.8.0 it is likely the solution will be to upgrade. Thanks > NiFi cluster is unstable with error "Administrative Yield Duration" > --- > > Key: NIFI-10547 > URL: https://issues.apache.org/jira/browse/NIFI-10547 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 1.8.0 > Environment: Prod >Reporter: Anoop Ajit >Priority: Major > > Nifi cluster is refusing to be stable and is throwing various errors like > "Too many Open files" and "Administrative Yield Duration". > > Below is the error logs: > > 2022-09-26 21:25:25,745 ERROR [Timer-Driven Process Thread-83] > o.a.n.p.cassandra.QueryCassandra > QueryCassandra[id=daa02218-016b-1000--f4865b2f] Failed to properly > initialize Processor. If still scheduled to run, NiFi will attempt to > initialize and run the Processor again after the 'Administrative Yield > Duration' has elapsed. Failure is due to > java.lang.reflect.InvocationTargetException: > java.lang.reflect.InvocationTargetException > 2022-09-26 21:25:25,775 ERROR [Timer-Driven Process Thread-139] > o.a.n.p.cassandra.PutCassandraQL > PutCassandraQL[id=d6ad5e1c-eec8-3e77-9636-247017134eee] Failed to properly > initialize Processor. If still scheduled to run, NiFi will attempt to > initialize and run the Processor again after the 'Administrative Yield > Duration' has elapsed. Failure is due to > java.lang.reflect.InvocationTargetException: > java.lang.reflect.InvocationTargetException > 2022-09-26 21:25:57,865 ERROR [Timer-Driven Process Thread-31] > o.a.n.p.cassandra.QueryCassandra > QueryCassandra[id=daa02218-016b-1000--f4865b2f] Failed to properly > initialize Processor. If still scheduled to run, NiFi will attempt to > initialize and run the Processor again after the 'Administrative Yield > Duration' has elapsed. Failure is due to > java.lang.reflect.InvocationTargetException: > java.lang.reflect.InvocationTargetException > 2022-09-26 21:25:57,974 ERROR [Timer-Driven Process Thread-44] > o.a.n.p.cassandra.PutCassandraQL > PutCassandraQL[id=f02c3fb7-3a9c-147c-9bc1-d30b6ba15183] Failed to properly > initialize Processor. If still scheduled to run, NiFi will attempt to > initialize and run the Processor again after the 'Administrative Yield > Duration' has elapsed. Failure is due to > java.lang.reflect.InvocationTargetException: > java.lang.reflect.InvocationTargetException > 2022-09-26 21:25:58,006 ERROR [Timer-Driven Process Thread-164] > o.a.n.p.cassandra.PutCassandraQL > PutCassandraQL[id=d6ad5e1c-eec8-3e77-9636-247017134eee] Failed to properly > initialize Processor. If still scheduled to run, NiFi will attempt to > initialize and run the Processor again after the 'Administrative Yield > Duration' has elapsed. Failure is due to > java.lang.reflect.InvocationTargetException: > java.lang.reflect.InvocationTargetException > 2022-09-26 21:26:20,039 ERROR [Timer-Driven Process Thread-72] > o.a.nifi.groups.StandardProcessGroup Failed to synchronize > StandardProcessGroup[identifier=318ec9e8-016b-1000--c852c4db] with > Flow Registry because could not retrieve version 1 of flow with identifier > dd7b8feb-4f95-495e-980f-05d89641daff in bucket > 49b79584-8e25-4e3b-80cc-bf2b6ff4a452 > 2022-09-26 21:26:20,040 ERROR [Timer-Driven Process Thread-72] > o.a.nifi.groups.StandardProcessGroup Failed to synchronize > StandardProcessGroup[identifier=3190cbfe-016b-1000--ab2b0f70] with > Flow Registry because could not retrieve version 1 of flow with identifier > 70323c57-4dc0-4157-ba01-7efbef1a1e1b in bucket > 0a33dfc5-dd66-49d7-977b-e82a56bcc4df > 2022-09-26 21:26:20,041 ERROR [Timer-Driven Process Thread-72] > o.a.nifi.groups.StandardProcessGroup Failed to synchronize > StandardProcessGroup[identifier=f59f32d1-d71f-1cbc-86ad-9242e95745ad] with > Flow Registry because could not retrieve version 1 of flow with identifier > 4dc233a0-d21e-4a41-b271-80d3f4d9310f in bucket > 0a33dfc5-dd66-49d7-977b-e82a56bcc4df > 2022-09-26 21:26:20,042 ERROR [Timer-Driven Process Thread-72] > o.a.nifi.groups.StandardProcessGroup Failed to synchronize > StandardProcessGroup[identifier=b4ea3324-079f-1226-b6b6-7e93c8b1318d] with > Flow Registry because could not retrieve version 1 of flow with identifier > 67db4103-271f-43c8-8bc6-68c7729f3504 in bucket >
[jira] [Created] (NIFI-10541) PutSFTP listing logic fails when credentials/location come from flow file attributes
Joe Witt created NIFI-10541: --- Summary: PutSFTP listing logic fails when credentials/location come from flow file attributes Key: NIFI-10541 URL: https://issues.apache.org/jira/browse/NIFI-10541 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.17.0, 1.18.0 Reporter: Joe Witt In fixing NIFI-10532 it was discovered that PutSFTP logic for listing directories to check if the required directories exist will not work when key values come from flowfile attributes such as login credentials or destination directory or host/port data. This might have worked before NIFI-10532 but only by accident. The solution will be to inject the flowfile and resolve its values properly when constructing the sftp client. The performance will be poor generally in such cases but this is a known limitation of this level of flexibility. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608864#comment-17608864 ] Joe Witt commented on NIFI-10532: - If hostname, port, username, or password as evaluated against each flowfile results in a difference from the previous transfer created then we need to close the connection and make a new one. We need to make it clear to users that this usage pattern is convenient but inefficient so should not be used when performance is desired. Also, in general, it is never a great idea to put sensitive values in flowfile attributes. > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Assignee: Joe Witt >Priority: Critical > Fix For: 1.18.0 > > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-5717) FTPTransfer can't connect to different users in a same host
[ https://issues.apache.org/jira/browse/NIFI-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-5717. Resolution: Duplicate > FTPTransfer can't connect to different users in a same host > --- > > Key: NIFI-5717 > URL: https://issues.apache.org/jira/browse/NIFI-5717 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.7.1 >Reporter: Daniel do Vale >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > 1) I have one FTP server host which different users can access. > 2) I'm trying to connect with 2 different users in the same host. These users > have different root folders configurated inside my host. > 3) The first user can connect to FTP without any problems. > 4) The second user can't connect to FTP properly, because nifi FTPTransfer > class have one verification that sees if the host is the same that previous > access, it don't reconnect (just reuse the current connection). For this > reason, the folders path dont match when i try to get some files. > > The problem occurs inside "getClient" method in FTPTransfer util class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10532: Priority: Critical (was: Major) > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Assignee: Joe Witt >Priority: Critical > Fix For: 1.18.0 > > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10532: Fix Version/s: 1.18.0 > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Assignee: Joe Witt >Priority: Major > Fix For: 1.18.0 > > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt reassigned NIFI-10532: --- Assignee: Joe Witt > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Assignee: Joe Witt >Priority: Major > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608850#comment-17608850 ] Joe Witt commented on NIFI-10532: - likely impacts PutFTP, PutSFTP, FetchFTP, FetchSFTP. > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Priority: Major > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10532) PutFTP does not group the batch by user name
[ https://issues.apache.org/jira/browse/NIFI-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17608844#comment-17608844 ] Joe Witt commented on NIFI-10532: - Hello it would never group them by their values. As a flowfile comes in it will decide what to do such as using an existing connection because the values match vs making a new one since they changed such as host/username/etc.. This approach is not efficient. I recommend running two different PutFTP processors and not using flowfile attributes for these values if efficiency/batching is desired. In any case at times this model is convenient and so we do want it to work. The bug is likely in https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/util/FTPTransfer.java#L547-L559 where we're only validating that the hostname hasn't changed. We need to validate the user hasn't changed, etc.. Will look more but that jumps out. > PutFTP does not group the batch by user name > > > Key: NIFI-10532 > URL: https://issues.apache.org/jira/browse/NIFI-10532 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.17.0, 1.16.1 >Reporter: Christoph Langheld >Priority: Major > Attachments: 01-PutFTP-ProcessGroup.png, 02-PutFTP-Setting.png, > 03-PutFTP-Result.png, PutFTP-Bug.xml > > > Hello, > for the PutFTP processor we set the host, name, password, port, and target > directory dynamically via UpdateAttribute. > We now have the problem, that the PutFTP processor transmits every file with > the same user even the ftp user name changed. The target host does not > change, only the user. > To reproduce I attached a process group as template ([^PutFTP-Bug.xml]). You > have to adapt the ftp server settings within the UpdateAttribute processor to > your environment. > The process group generates 50 flow files. > UpdateAttribute sets the ftp user credentials and sets a filename prefix > (NIFI-A_ respectively NIFI-B_). > If everything would work correctly all files with prefix NIFI-A_ should be > transfered to the ftp server as user nifi-a and the rest as user nifi-b. > But every file will be transferred as the same user (nifi-a). > PutFTP should group the batch by host, login credentials (user, password, > port) and target directory. > !01-PutFTP-ProcessGroup.png|width=639,height=607! > PutFTP settings: > !02-PutFTP-Setting.png|width=750,height=523! > Result on the ftp server (logged in as user nifi-a): > !03-PutFTP-Result.png|width=268,height=482! > > Thank you and regards > Christoph > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10369) Apache NiFi 1.16.x windows server closes immediately
[ https://issues.apache.org/jira/browse/NIFI-10369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10369. - Resolution: Fixed https://issues.apache.org/jira/browse/NIFI-10371 > Apache NiFi 1.16.x windows server closes immediately > > > Key: NIFI-10369 > URL: https://issues.apache.org/jira/browse/NIFI-10369 > Project: Apache NiFi > Issue Type: Bug > Components: Examples >Affects Versions: 1.16.3 > Environment: Windows, Linux >Reporter: Nikolay Akimov >Priority: Critical > Labels: test-stability > Attachments: Output_Port.xml, testRemote.xml > > > When I try to restart the server it's throwing with the following error > message. > *org.apache.nifi.controller.serialization.FlowSynchronizationException: > java.lang.IllegalStateException: Cannot add Connection to Process Group > because source is an Output Port that does not belong to a child Process > Group* > > I have simplified the scenario to such an extent that it is reproducible. I > attach the file. After importing this file and if you place the template on > the canvas, WiFi does not start after the restart. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10369) Apache NiFi 1.16.x windows server closes immediately
[ https://issues.apache.org/jira/browse/NIFI-10369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607964#comment-17607964 ] Joe Witt commented on NIFI-10369: - I believe this issue has been resolved in https://issues.apache.org/jira/browse/NIFI-10371 > Apache NiFi 1.16.x windows server closes immediately > > > Key: NIFI-10369 > URL: https://issues.apache.org/jira/browse/NIFI-10369 > Project: Apache NiFi > Issue Type: Bug > Components: Examples >Affects Versions: 1.16.3 > Environment: Windows, Linux >Reporter: Nikolay Akimov >Priority: Critical > Labels: test-stability > Attachments: Output_Port.xml, testRemote.xml > > > When I try to restart the server it's throwing with the following error > message. > *org.apache.nifi.controller.serialization.FlowSynchronizationException: > java.lang.IllegalStateException: Cannot add Connection to Process Group > because source is an Output Port that does not belong to a child Process > Group* > > I have simplified the scenario to such an extent that it is reproducible. I > attach the file. After importing this file and if you place the template on > the canvas, WiFi does not start after the restart. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10533) Update org.apache.commons.commons-configuration2 to 2.8.0 For NiFi Ranger
[
https://issues.apache.org/jira/browse/NIFI-10533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607903#comment-17607903
]
Joe Witt commented on NIFI-10533:
-
PLease work this through the Ranger project so we're not stuck messing with the
dependencies of other services. Thanks
> Update org.apache.commons.commons-configuration2 to 2.8.0 For NiFi Ranger
> -
>
> Key: NIFI-10533
> URL: https://issues.apache.org/jira/browse/NIFI-10533
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Mike R
>Priority: Major
>
> Update org.apache.commons.commons-configuration2 to 2.8.0 For NiFi Ranger
> from version 2.1.1. The move to version 2.8.0 remediates the following CVEs:
> [{*}CVE-2022-23437{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23437]
> [{*}CVE-2022-23302{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302]
> [{*}CVE-2022-22971{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971]
> [{*}CVE-2022-22968{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968]
> [{*}CVE-2022-22950{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22950]
> [{*}CVE-2020-15250{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15250]
> [{*}CVE-2019-17571{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571]
> [{*}CVE-2018-8088{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088]
> [{*}CVE-2018-1275{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1275]
> [{*}CVE-2018-1271{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1271]
> [{*}CVE-2018-1257{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1257]
> [{*}CVE-2016-5007{*}{*}{*}|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5007]
> [*CVE-2012-0881*|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0881]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-10522) Scripted Components cause doc generation errors on startup
Joe Witt created NIFI-10522: --- Summary: Scripted Components cause doc generation errors on startup Key: NIFI-10522 URL: https://issues.apache.org/jira/browse/NIFI-10522 Project: Apache NiFi Issue Type: Bug Components: Extensions Affects Versions: 1.18.0 Environment: Java version: 17.0.4.1, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "12.6", arch: "aarch64", family: "mac" Reporter: Joe Witt Assignee: Matt Burgess 2022-09-17 22:42:03,953 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to document: class org.apache.nifi.processors.script.InvokeScriptedProcessor java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:185) at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:139) at org.apache.nifi.processors.script.InvokeScriptedProcessor.getSupportedPropertyDescriptors(InvokeScriptedProcessor.java:157) at org.apache.nifi.components.AbstractConfigurableComponent.getPropertyDescriptors(AbstractConfigurableComponent.java:231) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeProperties(HtmlDocumentationWriter.java:465) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeBody(HtmlDocumentationWriter.java:161) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.write(HtmlDocumentationWriter.java:93) at org.apache.nifi.documentation.DocGenerator.document(DocGenerator.java:144) at org.apache.nifi.documentation.DocGenerator.documentConfigurableComponent(DocGenerator.java:106) at org.apache.nifi.documentation.DocGenerator.generate(DocGenerator.java:66) at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:787) at org.apache.nifi.NiFi.(NiFi.java:172) at org.apache.nifi.NiFi.(NiFi.java:83) at org.apache.nifi.NiFi.main(NiFi.java:332) 2022-09-17 22:42:04,588 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to document: class org.apache.nifi.processors.script.ExecuteScript java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:185) at org.apache.nifi.processors.script.ExecuteScript.getSupportedPropertyDescriptors(ExecuteScript.java:124) at org.apache.nifi.components.AbstractConfigurableComponent.getPropertyDescriptors(AbstractConfigurableComponent.java:231) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeProperties(HtmlDocumentationWriter.java:465) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeBody(HtmlDocumentationWriter.java:161) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.write(HtmlDocumentationWriter.java:93) at org.apache.nifi.documentation.DocGenerator.document(DocGenerator.java:144) at org.apache.nifi.documentation.DocGenerator.documentConfigurableComponent(DocGenerator.java:106) at org.apache.nifi.documentation.DocGenerator.generate(DocGenerator.java:66) at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:787) at org.apache.nifi.NiFi.(NiFi.java:172) at org.apache.nifi.NiFi.(NiFi.java:83) at org.apache.nifi.NiFi.main(NiFi.java:332) 2022-09-17 22:42:04,842 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to document: class org.apache.nifi.rules.handlers.script.ScriptedActionHandler java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:185) at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:139) at org.apache.nifi.rules.handlers.script.ScriptedActionHandler.getSupportedPropertyDescriptors(ScriptedActionHandler.java:73) at org.apache.nifi.components.AbstractConfigurableComponent.getPropertyDescriptors(AbstractConfigurableComponent.java:231) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeProperties(HtmlDocumentationWriter.java:465) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeBody(HtmlDocumentationWriter.java:161) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.write(HtmlDocumentationWriter.java:93) at org.apache.nifi.documentation.DocGenerator.document(DocGenerator.java:144) at org.apache.nifi.documentation.DocGenerator.documentConfigurableComponent(DocGenerator.java:106)
[jira] [Created] (NIFI-10521) Apache NiFi 1.18.0 RC1 RM
Joe Witt created NIFI-10521: --- Summary: Apache NiFi 1.18.0 RC1 RM Key: NIFI-10521 URL: https://issues.apache.org/jira/browse/NIFI-10521 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10521) Apache NiFi 1.18.0 RC1 RM
[ https://issues.apache.org/jira/browse/NIFI-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10521: Fix Version/s: 1.18.0 > Apache NiFi 1.18.0 RC1 RM > - > > Key: NIFI-10521 > URL: https://issues.apache.org/jira/browse/NIFI-10521 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.18.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10406) Update nifi parent to assembly plugin 3.4.2
[ https://issues.apache.org/jira/browse/NIFI-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17603766#comment-17603766 ] Joe Witt commented on NIFI-10406: - uh yeah no we need this. thank you. i'll review. all good > Update nifi parent to assembly plugin 3.4.2 > --- > > Key: NIFI-10406 > URL: https://issues.apache.org/jira/browse/NIFI-10406 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Mark Payne >Priority: Major > Fix For: 1.18.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In working on NIFI-10405 it was discovered the build for stateless nifi > breaks when updating to maven assembly plugin 3.4.2 from 3.3.0. This appears > to be due to changes related to > https://issues.apache.org/jira/browse/MASSEMBLY-969 potentially. In any case > whatever happens with assembly formation for stateless appears to break. > [ERROR] Failures: > [ERROR] > TestExecuteStateless.testErrorBulletinSurfaced:180->testBulletinSurfaced:194 > expected: <1> but was: <0> > [ERROR] > TestExecuteStateless.testInfoBulletinNotSurfaced:170->testBulletinSurfaced:194 > expected: <1> but was: <0> > [ERROR] TestExecuteStateless.testMultipleFailurePortNames:126 expected: <1> > but was: <0> > [ERROR] TestExecuteStateless.testProcessorExceptionRoutesToFailure:165 > expected: <1> but was: <0> > [ERROR] TestExecuteStateless.testRouteToFailureInnerGroup:139 expected: <1> > but was: <0> > [ERROR] TestExecuteStateless.testRouteToFailureWithInput:103 expected: <3> > but was: <0> > [ERROR] TestExecuteStateless.testSimplePassThrough:58 expected: <1> but > was: <0> > [ERROR] TestExecuteStateless.testSplitWithParameters:73 expected: <3> but > was: <0> > [ERROR] TestExecuteStateless.testTimeout:154 expected: <1> but was: <0> > [ERROR] > TestExecuteStateless.testWarnBulletinSurfaced:175->testBulletinSurfaced:194 > expected: <1> but was: <0> > [INFO] > [ERROR] Tests run: 11, Failures: 10, Errors: 0, Skipped: 0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10406) Update nifi parent to assembly plugin 3.4.2
[ https://issues.apache.org/jira/browse/NIFI-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10406: Fix Version/s: (was: 1.18.0) > Update nifi parent to assembly plugin 3.4.2 > --- > > Key: NIFI-10406 > URL: https://issues.apache.org/jira/browse/NIFI-10406 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Mark Payne >Priority: Major > > In working on NIFI-10405 it was discovered the build for stateless nifi > breaks when updating to maven assembly plugin 3.4.2 from 3.3.0. This appears > to be due to changes related to > https://issues.apache.org/jira/browse/MASSEMBLY-969 potentially. In any case > whatever happens with assembly formation for stateless appears to break. > [ERROR] Failures: > [ERROR] > TestExecuteStateless.testErrorBulletinSurfaced:180->testBulletinSurfaced:194 > expected: <1> but was: <0> > [ERROR] > TestExecuteStateless.testInfoBulletinNotSurfaced:170->testBulletinSurfaced:194 > expected: <1> but was: <0> > [ERROR] TestExecuteStateless.testMultipleFailurePortNames:126 expected: <1> > but was: <0> > [ERROR] TestExecuteStateless.testProcessorExceptionRoutesToFailure:165 > expected: <1> but was: <0> > [ERROR] TestExecuteStateless.testRouteToFailureInnerGroup:139 expected: <1> > but was: <0> > [ERROR] TestExecuteStateless.testRouteToFailureWithInput:103 expected: <3> > but was: <0> > [ERROR] TestExecuteStateless.testSimplePassThrough:58 expected: <1> but > was: <0> > [ERROR] TestExecuteStateless.testSplitWithParameters:73 expected: <3> but > was: <0> > [ERROR] TestExecuteStateless.testTimeout:154 expected: <1> but was: <0> > [ERROR] > TestExecuteStateless.testWarnBulletinSurfaced:175->testBulletinSurfaced:194 > expected: <1> but was: <0> > [INFO] > [ERROR] Tests run: 11, Failures: 10, Errors: 0, Skipped: 0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10433) Update Javassist to 3.29.1-GA
[ https://issues.apache.org/jira/browse/NIFI-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10433: Issue Type: Task (was: New Feature) > Update Javassist to 3.29.1-GA > - > > Key: NIFI-10433 > URL: https://issues.apache.org/jira/browse/NIFI-10433 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 1.17.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Fix For: 1.18.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Javassist from 3.23.1-GA to 3.29.1-GA -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10495) Finish relationship for FetchFile
[ https://issues.apache.org/jira/browse/NIFI-10495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17603649#comment-17603649 ] Joe Witt commented on NIFI-10495: - Hello. The resulting fetched data that goes to success - does this not achieve that outcome? Send that 'success' relationship to whatever downstream component you need... > Finish relationship for FetchFile > - > > Key: NIFI-10495 > URL: https://issues.apache.org/jira/browse/NIFI-10495 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Shayan Tabrizi >Priority: Major > > When using FetchFile to read a file, one might need to know if fetching is > finished, so, e.g., notifies a downstream component to do some processing on > the whole data of the file. Is it possible to put a finish relationship for > FetchFile so this can be done? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10462) nexus-staging-plugin throwing errors/stacktrace on startup
Joe Witt created NIFI-10462: --- Summary: nexus-staging-plugin throwing errors/stacktrace on startup Key: NIFI-10462 URL: https://issues.apache.org/jira/browse/NIFI-10462 Project: Apache NiFi Issue Type: Bug Reporter: Joe Witt Assignee: Joe Witt Fix For: 1.18.0 Not sure when this started happening but it is and it is annoying. mvn -T C1 clean install -Pcontrib-check,include-grpc [INFO] Scanning for projects... [WARNING] ClassRealm[extension>org.sonatype.plugins:nexus-staging-maven-plugin:1.6.9, parent: sun.misc.Launcher$AppClassLoader@7852e922] com.google.inject.CreationException: Unable to create injector, see the following errors: 1) No implementation for com.fasterxml.jackson.databind.ObjectMapper annotated with interface org.eclipse.sisu.inject.TypeArguments$Implicit was bound. Did you mean? com.fasterxml.jackson.databind.ObjectMapper annotated with @com.google.inject.name.Named(value=org.sonatype.sisu.siesta.jackson.ObjectMapperProvider) bound at ClassRealm[extension>org.sonatype.plugins:nexus-staging-maven-plugin:1.6.9, parent: sun.misc.Launcher$AppClassLoader@7852e922] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule) com.fasterxml.jackson.databind.ObjectMapper bound at org.eclipse.sisu.wire.LocatorWiring at org.eclipse.sisu.wire.LocatorWiring 1 error at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist (Errors.java:543) at com.google.inject.internal.InternalInjectorCreator.initializeStatically (InternalInjectorCreator.java:159) at com.google.inject.internal.InternalInjectorCreator.build (InternalInjectorCreator.java:106) at com.google.inject.Guice.createInjector (Guice.java:87) at com.google.inject.Guice.createInjector (Guice.java:69) at com.google.inject.Guice.createInjector (Guice.java:59) at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector (DefaultPlexusContainer.java:481) at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents (DefaultPlexusContainer.java:460) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.discoverPluginComponents (DefaultMavenPluginManager.java:436) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm (DefaultMavenPluginManager.java:879) at org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm (DefaultProjectBuildingHelper.java:197) at org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled (DefaultModelBuildingListener.java:101) at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire (ModelBuildingEventCatapult.java:44) at org.apache.maven.model.building.DefaultModelBuilder.fireEvent (DefaultModelBuilder.java:1450) at org.apache.maven.model.building.DefaultModelBuilder.build (DefaultModelBuilder.java:530) at org.apache.maven.model.building.DefaultModelBuilder.build (DefaultModelBuilder.java:510) at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:618) at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:387) at org.apache.maven.graph.DefaultGraphBuilder.collectProjects (DefaultGraphBuilder.java:414) at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor (DefaultGraphBuilder.java:405) at org.apache.maven.graph.DefaultGraphBuilder.build (DefaultGraphBuilder.java:82) at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:532) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293) at org.apache.maven.cli.MavenCli.main (MavenCli.java:196) 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10462) nexus-staging-plugin throwing errors/stacktrace on startup
[ https://issues.apache.org/jira/browse/NIFI-10462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10462: Priority: Minor (was: Major) > nexus-staging-plugin throwing errors/stacktrace on startup > -- > > Key: NIFI-10462 > URL: https://issues.apache.org/jira/browse/NIFI-10462 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Minor > Fix For: 1.18.0 > > > Not sure when this started happening but it is and it is annoying. > mvn -T C1 clean install -Pcontrib-check,include-grpc > [INFO] Scanning for projects... > [WARNING] > ClassRealm[extension>org.sonatype.plugins:nexus-staging-maven-plugin:1.6.9, > parent: sun.misc.Launcher$AppClassLoader@7852e922] > com.google.inject.CreationException: Unable to create injector, see the > following errors: > 1) No implementation for com.fasterxml.jackson.databind.ObjectMapper > annotated with interface org.eclipse.sisu.inject.TypeArguments$Implicit was > bound. > Did you mean? > com.fasterxml.jackson.databind.ObjectMapper annotated with > @com.google.inject.name.Named(value=org.sonatype.sisu.siesta.jackson.ObjectMapperProvider) > bound at > ClassRealm[extension>org.sonatype.plugins:nexus-staging-maven-plugin:1.6.9, > parent: sun.misc.Launcher$AppClassLoader@7852e922] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > com.fasterxml.jackson.databind.ObjectMapper bound at > org.eclipse.sisu.wire.LocatorWiring > at org.eclipse.sisu.wire.LocatorWiring > 1 error > at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist > (Errors.java:543) > at > com.google.inject.internal.InternalInjectorCreator.initializeStatically > (InternalInjectorCreator.java:159) > at com.google.inject.internal.InternalInjectorCreator.build > (InternalInjectorCreator.java:106) > at com.google.inject.Guice.createInjector (Guice.java:87) > at com.google.inject.Guice.createInjector (Guice.java:69) > at com.google.inject.Guice.createInjector (Guice.java:59) > at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector > (DefaultPlexusContainer.java:481) > at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents > (DefaultPlexusContainer.java:460) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.discoverPluginComponents > (DefaultMavenPluginManager.java:436) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:879) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:532) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:196) > 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at
[jira] [Created] (NIFI-10414) Zookeeper/Curator NPE during pod restarts in K8S environment/Openshift
Joe Witt created NIFI-10414: --- Summary: Zookeeper/Curator NPE during pod restarts in K8S environment/Openshift Key: NIFI-10414 URL: https://issues.apache.org/jira/browse/NIFI-10414 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.16.1 Environment: NiFi 1.16.1 on RedHat OpenShift 4.9 Reporter: Joe Witt Walter Moar 10:51 AM Hello, I'm running NiFi 1.16.1 on RedHat OpenShift 4.9. I'm seeing the behaviour that when OpenShift operations cause Zookeeper pod restarts, the NiFi cluster loses its controller. When this happens I have to scale down the NiFi pods and then back up again. The error in the logs is: 2022-08-30 17:02:19,452 ERROR [main-EventThread] o.a.c.f.imps.CuratorFrameworkImpl Background exception was not retry-able or retry gave up java.lang.NullPointerException: null at org.apache.curator.utils.Compatibility.getHostAddress(Compatibility.java:116) at org.apache.curator.framework.imps.EnsembleTracker.configToConnectionString(EnsembleTracker.java:185) at org.apache.curator.framework.imps.EnsembleTracker.processConfigData(EnsembleTracker.java:206) at org.apache.curator.framework.imps.EnsembleTracker.access$300(EnsembleTracker.java:50) at org.apache.curator.framework.imps.EnsembleTracker$2.processResult(EnsembleTracker.java:150) at org.apache.curator.framework.imps.CuratorFrameworkImpl.sendToBackgroundCallback(CuratorFrameworkImpl.java:926) at org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(CuratorFrameworkImpl.java:683) at org.apache.curator.framework.imps.WatcherRemovalFacade.processBackgroundOperation(WatcherRemovalFacade.java:152) at org.apache.curator.framework.imps.GetConfigBuilderImpl$2.processResult(GetConfigBuilderImpl.java:222) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:598) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:510) The NPE should be fixed by https://issues.apache.org/jira/browse/CURATOR-538 Once CURATOR-538 lands we need to pull in the new curator version. This should address the issue seen above but may expose something else. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10405) Update to latest Apache Maven Parent 27 and address other plugin versions
[ https://issues.apache.org/jira/browse/NIFI-10405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10405. - Resolution: Fixed > Update to latest Apache Maven Parent 27 and address other plugin versions > - > > Key: NIFI-10405 > URL: https://issues.apache.org/jira/browse/NIFI-10405 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10048) NullPointerException in StandardFlowDifference.hashCode Causes Startup Failures
[
https://issues.apache.org/jira/browse/NIFI-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597323#comment-17597323
]
Joe Witt commented on NIFI-10048:
-
confirmed commit is on main and post 1.17 so is a 1.18 fix and resolved.
> NullPointerException in StandardFlowDifference.hashCode Causes Startup
> Failures
> ---
>
> Key: NIFI-10048
> URL: https://issues.apache.org/jira/browse/NIFI-10048
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.16.1
>Reporter: Andreas Adamides
>Assignee: Emilio Setiadarma
>Priority: Critical
> Fix For: 1.18.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The following exception keeps occurring on the Apache NiFi Cluster, this is
> from the app logs:
> {code:java}
> 2022-05-24 15:13:03,669 INFO [main] o.a.n.c.s.VersionedFlowSynchronizer
> Synching FlowController with proposed flow: Controller Already Synchronized =
> false
> 2022-05-24 15:13:04,260 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.registry.flow.diff.StandardFlowDifference.hashCode(StandardFlowDifference.java:92)
> at java.util.HashMap.hash(HashMap.java:340)
> at java.util.HashMap.put(HashMap.java:613)
> at java.util.HashSet.add(HashSet.java:220)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.addIfDifferent(StandardFlowComparator.java:562)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:447)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:92)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:77)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.compareFlows(VersionedFlowSynchronizer.java:383)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:165)
> at
> org.apache.nifi.controller.serialization.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:43)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1524)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:104)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:815)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:457)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1086)
> at org.apache.nifi.NiFi.(NiFi.java:170)
> at org.apache.nifi.NiFi.(NiFi.java:82)
> at org.apache.nifi.NiFi.main(NiFi.java:330)
> 2022-05-24 15:13:04,261 INFO [Thread-1] org.apache.nifi.NiFi Application
> Server shutdown started{code}
> There is not a Nifi Registry in the setup, I have tried to tear everything
> down to freshly install Nifi Cluster, but it keeps failing to start. This has
> been part of a helm chart/k8 setup. This issue occurs in 2 nodes of a 3-node
> Nifi cluster. I manage to fix it when downgrading to 1 node overall, which
> does not make a lot of sense.
>
> Can anyone suggest what I am doing wrong?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10048) NullPointerException in StandardFlowDifference.hashCode Causes Startup Failures
[
https://issues.apache.org/jira/browse/NIFI-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt resolved NIFI-10048.
-
Fix Version/s: 1.18.0
Resolution: Fixed
> NullPointerException in StandardFlowDifference.hashCode Causes Startup
> Failures
> ---
>
> Key: NIFI-10048
> URL: https://issues.apache.org/jira/browse/NIFI-10048
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.16.1
>Reporter: Andreas Adamides
>Assignee: Emilio Setiadarma
>Priority: Critical
> Fix For: 1.18.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The following exception keeps occurring on the Apache NiFi Cluster, this is
> from the app logs:
> {code:java}
> 2022-05-24 15:13:03,669 INFO [main] o.a.n.c.s.VersionedFlowSynchronizer
> Synching FlowController with proposed flow: Controller Already Synchronized =
> false
> 2022-05-24 15:13:04,260 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.registry.flow.diff.StandardFlowDifference.hashCode(StandardFlowDifference.java:92)
> at java.util.HashMap.hash(HashMap.java:340)
> at java.util.HashMap.put(HashMap.java:613)
> at java.util.HashSet.add(HashSet.java:220)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.addIfDifferent(StandardFlowComparator.java:562)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:447)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:92)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:77)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.compareFlows(VersionedFlowSynchronizer.java:383)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:165)
> at
> org.apache.nifi.controller.serialization.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:43)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1524)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:104)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:815)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:457)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1086)
> at org.apache.nifi.NiFi.(NiFi.java:170)
> at org.apache.nifi.NiFi.(NiFi.java:82)
> at org.apache.nifi.NiFi.main(NiFi.java:330)
> 2022-05-24 15:13:04,261 INFO [Thread-1] org.apache.nifi.NiFi Application
> Server shutdown started{code}
> There is not a Nifi Registry in the setup, I have tried to tear everything
> down to freshly install Nifi Cluster, but it keeps failing to start. This has
> been part of a helm chart/k8 setup. This issue occurs in 2 nodes of a 3-node
> Nifi cluster. I manage to fix it when downgrading to 1 node overall, which
> does not make a lot of sense.
>
> Can anyone suggest what I am doing wrong?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10048) NullPointerException in StandardFlowDifference.hashCode Causes Startup Failures
[
https://issues.apache.org/jira/browse/NIFI-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597321#comment-17597321
]
Joe Witt commented on NIFI-10048:
-
[~emilio.setiadarma][~exceptionfactory] it appears the PR for this was merged
already. Can we close this ticket and would that be on 1.18 then?
> NullPointerException in StandardFlowDifference.hashCode Causes Startup
> Failures
> ---
>
> Key: NIFI-10048
> URL: https://issues.apache.org/jira/browse/NIFI-10048
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.16.1
>Reporter: Andreas Adamides
>Assignee: Emilio Setiadarma
>Priority: Critical
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The following exception keeps occurring on the Apache NiFi Cluster, this is
> from the app logs:
> {code:java}
> 2022-05-24 15:13:03,669 INFO [main] o.a.n.c.s.VersionedFlowSynchronizer
> Synching FlowController with proposed flow: Controller Already Synchronized =
> false
> 2022-05-24 15:13:04,260 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.registry.flow.diff.StandardFlowDifference.hashCode(StandardFlowDifference.java:92)
> at java.util.HashMap.hash(HashMap.java:340)
> at java.util.HashMap.put(HashMap.java:613)
> at java.util.HashSet.add(HashSet.java:220)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.addIfDifferent(StandardFlowComparator.java:562)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:447)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:92)
> at
> org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:77)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.compareFlows(VersionedFlowSynchronizer.java:383)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:165)
> at
> org.apache.nifi.controller.serialization.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:43)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1524)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:104)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:815)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:457)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1086)
> at org.apache.nifi.NiFi.(NiFi.java:170)
> at org.apache.nifi.NiFi.(NiFi.java:82)
> at org.apache.nifi.NiFi.main(NiFi.java:330)
> 2022-05-24 15:13:04,261 INFO [Thread-1] org.apache.nifi.NiFi Application
> Server shutdown started{code}
> There is not a Nifi Registry in the setup, I have tried to tear everything
> down to freshly install Nifi Cluster, but it keeps failing to start. This has
> been part of a helm chart/k8 setup. This issue occurs in 2 nodes of a 3-node
> Nifi cluster. I manage to fix it when downgrading to 1 node overall, which
> does not make a lot of sense.
>
> Can anyone suggest what I am doing wrong?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10405) Update to latest Apache Maven Parent 27 and address other plugin versions
[ https://issues.apache.org/jira/browse/NIFI-10405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597276#comment-17597276 ] Joe Witt commented on NIFI-10405: - created a different JIRA to address the need to update to assembly plugin 3.4.2 but it breaks the build so excluding that from this change. > Update to latest Apache Maven Parent 27 and address other plugin versions > - > > Key: NIFI-10405 > URL: https://issues.apache.org/jira/browse/NIFI-10405 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.18.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10406) Update nifi parent to assembly plugin 3.4.2
Joe Witt created NIFI-10406: --- Summary: Update nifi parent to assembly plugin 3.4.2 Key: NIFI-10406 URL: https://issues.apache.org/jira/browse/NIFI-10406 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Mark Payne Fix For: 1.18.0 In working on NIFI-10405 it was discovered the build for stateless nifi breaks when updating to maven assembly plugin 3.4.2 from 3.3.0. This appears to be due to changes related to https://issues.apache.org/jira/browse/MASSEMBLY-969 potentially. In any case whatever happens with assembly formation for stateless appears to break. [ERROR] Failures: [ERROR] TestExecuteStateless.testErrorBulletinSurfaced:180->testBulletinSurfaced:194 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testInfoBulletinNotSurfaced:170->testBulletinSurfaced:194 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testMultipleFailurePortNames:126 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testProcessorExceptionRoutesToFailure:165 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testRouteToFailureInnerGroup:139 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testRouteToFailureWithInput:103 expected: <3> but was: <0> [ERROR] TestExecuteStateless.testSimplePassThrough:58 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testSplitWithParameters:73 expected: <3> but was: <0> [ERROR] TestExecuteStateless.testTimeout:154 expected: <1> but was: <0> [ERROR] TestExecuteStateless.testWarnBulletinSurfaced:175->testBulletinSurfaced:194 expected: <1> but was: <0> [INFO] [ERROR] Tests run: 11, Failures: 10, Errors: 0, Skipped: 0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10405) Update to latest Apache Maven Parent 27 and address other plugin versions
[ https://issues.apache.org/jira/browse/NIFI-10405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10405: Summary: Update to latest Apache Maven Parent 27 and address other plugin versions (was: Update to latest Apache Maven Parent 27) > Update to latest Apache Maven Parent 27 and address other plugin versions > - > > Key: NIFI-10405 > URL: https://issues.apache.org/jira/browse/NIFI-10405 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.18.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10405) Update to latest Apache Maven Parent 27
Joe Witt created NIFI-10405: --- Summary: Update to latest Apache Maven Parent 27 Key: NIFI-10405 URL: https://issues.apache.org/jira/browse/NIFI-10405 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt Fix For: 1.18.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10392) ResizeImage - add option to maintain aspect ratio
[ https://issues.apache.org/jira/browse/NIFI-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10392: Fix Version/s: 1.18.0 > ResizeImage - add option to maintain aspect ratio > - > > Key: NIFI-10392 > URL: https://issues.apache.org/jira/browse/NIFI-10392 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.18.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add an option to the ResizeImage processor to retain the aspect ratio of the > input image. This property will be a boolean defaulting to false for > maintaining backward compatibility/behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10392) ResizeImage - add option to maintain aspect ratio
[ https://issues.apache.org/jira/browse/NIFI-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10392: Resolution: Fixed Status: Resolved (was: Patch Available) > ResizeImage - add option to maintain aspect ratio > - > > Key: NIFI-10392 > URL: https://issues.apache.org/jira/browse/NIFI-10392 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.18.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Add an option to the ResizeImage processor to retain the aspect ratio of the > input image. This property will be a boolean defaulting to false for > maintaining backward compatibility/behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-9572) Failed to index Provenance Events and (Too many Files)
[
https://issues.apache.org/jira/browse/NIFI-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580868#comment-17580868
]
Joe Witt commented on NIFI-9572:
[~giocapi] Here again as the examples before the lsof output provided shows
only 4000 or so open files (4192 in your case). If you hit out of file limits
with only 4000 or so files open yet you think the limit on your system is 999K
then something isn't right. We've seen more and more confusion around what
people meant to set for max open files vs what they're actually seeing. You
will want to show more from your logs/output and dumps so we can get the full
context of what might be happening for you. Thanks
> Failed to index Provenance Events and (Too many Files)
> --
>
> Key: NIFI-9572
> URL: https://issues.apache.org/jira/browse/NIFI-9572
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI
>Affects Versions: 1.15.2
>Reporter: mayki
>Priority: Major
> Attachments: bootstrap.conf, lsof (1).txt, nifi-app.log,
> nifi-app.log.tar.gz, nifi.properties, nifi_691106_pid.tar.gz
>
>
> Hello
> I have upgraded NIFI 1.15.2 since 2022/01/05
> No issue until this night 2022/01/13
> * nifi version 1.15.2
> * jdk-1.8.0_311
> And the limit is high
> {code:java}
> Last login: Fri Jan 14 09:57:06 CET 2022 on pts/2
> -bash-4.2@nifi$ ulimit -a
> core file size (blocks, -c) 0
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (blocks, -f) rg
> pending signals (-i) 63278
> max locked memory (kbytes, -l) 64
> max memory size (kbytes, -m) unlimited
> open files (-n) 5
> pipe size (512 bytes, -p) 8
> POSIX message queues (bytes, -q) 819200
> real-time priority (-r) 0
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) 1
> virtual memory (kbytes, -v) unlimited
> file locks (-x) unlimited
> {code}
>
> We got a lot error about provenance_repository, it fill our filesystem logs ..
>
> {code:java}
> 2022-01-14 10:19:00,963 ERROR [Index Provenance Events-2]
> o.a.n.p.index.lucene.EventIndexTask Failed to index Provenance Events
> org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
> at
> org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:877)
> at
> org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:891)
> at
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1468)
> at
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1444)
> at
> org.apache.nifi.provenance.lucene.LuceneEventIndexWriter.index(LuceneEventIndexWriter.java:70)
> at
> org.apache.nifi.provenance.index.lucene.EventIndexTask.index(EventIndexTask.java:202)
> at
> org.apache.nifi.provenance.index.lucene.EventIndexTask.run(EventIndexTask.java:113)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.file.FileSystemException:
> /data/nifi/provenance_repository/lucene-8-index-1642145908399/_4_Lucene80_0.dvd:
> Too many open files
> {code}
>
>
> We expect upgrade all nifi instances to 1.15.2 to avoid log4j vulnerability.
> But it is impossible to do that if we got this error.
>
> Thanks for you help.
>
> Regards
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-10342) SplitText 'Line Split Count' should support expression language
Joe Witt created NIFI-10342: --- Summary: SplitText 'Line Split Count' should support expression language Key: NIFI-10342 URL: https://issues.apache.org/jira/browse/NIFI-10342 Project: Apache NiFi Issue Type: Improvement Reporter: Joe Witt The SplitText processor 'Line Split Count' property (and possibly others) should allow for expression language. Since each flowfile is split on its own this should be reasonably simple to implement provided the expression language result is numeric/positive. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-2827) CompressContent should support brotli (MIT) and zstd (BSD)
[ https://issues.apache.org/jira/browse/NIFI-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577616#comment-17577616 ] Joe Witt commented on NIFI-2827: Thanks for contributing an example patch. Adding support for these is fine but we'll definitely want the key things related to compression levels included. We use specific libraries for specific compression types (or at least had in the past) because different libraries gave different trade-offs including for things like memory usage/etc.. We'll likely retain that unless research has been done to show it is no longer necessary. In any case adding new compression/decompression types is often painless and certain commons compress helps a lot there. So happy to add support for these but we'll need someone to write up the full patch and someone to review it. Truthfully these days basically all patches that make it in go through Github/Pull Requests because there is some extremely helpful automation that comes along with that to reduce the review timeline. Thanks > CompressContent should support brotli (MIT) and zstd (BSD) > -- > > Key: NIFI-2827 > URL: https://issues.apache.org/jira/browse/NIFI-2827 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Andre F de Miranda >Priority: Major > Attachments: NIFI-2827-zstd.patch > > > brotli and zstd are gaining lots of momentum across the IoT sphere and I > suspect it would be a nice to have in NiFi to be able to support those two > emerging compression algorithms. > Both brotli and zstd JAVA implementations are JNIs > https://github.com/MeteoGroup/jbrotli (ASL 2) > https://github.com/luben/zstd-jni (3 clause BSD) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10258) Continuously getting the error "ERROR: Failed to index Provenance Events. See logs for more information. " in the Bulletin Board
[ https://issues.apache.org/jira/browse/NIFI-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577615#comment-17577615 ] Joe Witt commented on NIFI-10258: - That would be a perfectly fine option. It would help you be confident in the root problem. You could then if necessary re-install it and ensure it doesn't impact critical directories NiFi uses to perform its function. > Continuously getting the error "ERROR: Failed to index Provenance Events. See > logs for more information. " in the Bulletin Board > > > Key: NIFI-10258 > URL: https://issues.apache.org/jira/browse/NIFI-10258 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.3 > Environment: Operating System: Red Hat Enterprise Linux Server 7.9 > (Maipo) > Architecture: amd 64 > Kernel: Linux 3.10.0-1160.53.1.el7.x86_64 > Java Version:1.8.0_322 >Reporter: Deepak Reddy Chirthani >Priority: Critical > Attachments: Nifi_logs_deepak.txt, Provenance_properties.PNG > > Original Estimate: 336h > Remaining Estimate: 336h > > we have started to use the reporting task *SiteToSiteProvenanceReportingTask > 1.15.3* for auditing purposes on provenance events for a few of our > dataflows. We started to see error quite frequently now in the Bulletin Board. > *ERROR: Failed to index Provenance Events. See logs for more information.* > Also, below are attached snaps of nifi.provenance.properties file and from > logs regarding this error. > Please let me know if you need anything more. > Update: Even though S2SProvenanceReportingTask is stopped, the error still > exisits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10330) PutOrc processor missing in 1.17
[ https://issues.apache.org/jira/browse/NIFI-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10330. - Resolution: Information Provided You may download the required nifi archive (nar) for it. This is referenced in the migration guidance here https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance Though admittedly most people would not realize that processor is in that bundle. https://repo1.maven.org/maven2/org/apache/nifi/nifi-hive-nar/1.17.0/nifi-hive-nar-1.17.0.nar https://repo1.maven.org/maven2/org/apache/nifi/nifi-hive-services-api-nar/1.17.0/nifi-hive-services-api-nar-1.17.0.nar > PutOrc processor missing in 1.17 > > > Key: NIFI-10330 > URL: https://issues.apache.org/jira/browse/NIFI-10330 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build >Affects Versions: 1.17.0 > Environment: Rhel7, java 1.8 >Reporter: Zenkovac >Priority: Major > > PutOrc processor is missing in version 1.17 but no documentacion stated being > deprecated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-9383) Nashorn deprecation warning
[ https://issues.apache.org/jira/browse/NIFI-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17576967#comment-17576967 ] Joe Witt commented on NIFI-9383: When starting NiFi under Java 17 a slew of warnings print and are likely related. 2022-08-08 12:26:09,713 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to document: class org.apache.nifi.processors.script.ExecuteScript java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:185) at org.apache.nifi.processors.script.ExecuteScript.getSupportedPropertyDescriptors(ExecuteScript.java:124) at org.apache.nifi.components.AbstractConfigurableComponent.getPropertyDescriptors(AbstractConfigurableComponent.java:231) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeProperties(HtmlDocumentationWriter.java:465) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeBody(HtmlDocumentationWriter.java:161) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.write(HtmlDocumentationWriter.java:93) at org.apache.nifi.documentation.DocGenerator.document(DocGenerator.java:142) at org.apache.nifi.documentation.DocGenerator.documentConfigurableComponent(DocGenerator.java:104) at org.apache.nifi.documentation.DocGenerator.generate(DocGenerator.java:65) at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:786) at org.apache.nifi.NiFi.(NiFi.java:172) at org.apache.nifi.NiFi.(NiFi.java:83) at org.apache.nifi.NiFi.main(NiFi.java:332) 2022-08-08 12:26:10,646 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to document: class org.apache.nifi.processors.script.InvokeScriptedProcessor java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:185) at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:139) at org.apache.nifi.processors.script.InvokeScriptedProcessor.getSupportedPropertyDescriptors(InvokeScriptedProcessor.java:157) at org.apache.nifi.components.AbstractConfigurableComponent.getPropertyDescriptors(AbstractConfigurableComponent.java:231) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeProperties(HtmlDocumentationWriter.java:465) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeBody(HtmlDocumentationWriter.java:161) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.write(HtmlDocumentationWriter.java:93) at org.apache.nifi.documentation.DocGenerator.document(DocGenerator.java:142) at org.apache.nifi.documentation.DocGenerator.documentConfigurableComponent(DocGenerator.java:104) at org.apache.nifi.documentation.DocGenerator.generate(DocGenerator.java:65) at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:786) at org.apache.nifi.NiFi.(NiFi.java:172) at org.apache.nifi.NiFi.(NiFi.java:83) at org.apache.nifi.NiFi.main(NiFi.java:332) 2022-08-08 12:26:10,766 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to document: class org.apache.nifi.lookup.script.ScriptedLookupService java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:185) at org.apache.nifi.script.ScriptingComponentHelper.createResources(ScriptingComponentHelper.java:139) at org.apache.nifi.lookup.script.BaseScriptedLookupService.getSupportedPropertyDescriptors(BaseScriptedLookupService.java:81) at org.apache.nifi.components.AbstractConfigurableComponent.getPropertyDescriptors(AbstractConfigurableComponent.java:231) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeProperties(HtmlDocumentationWriter.java:465) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.writeBody(HtmlDocumentationWriter.java:161) at org.apache.nifi.documentation.html.HtmlDocumentationWriter.write(HtmlDocumentationWriter.java:93) at org.apache.nifi.documentation.DocGenerator.document(DocGenerator.java:142) at org.apache.nifi.documentation.DocGenerator.documentConfigurableComponent(DocGenerator.java:104) at org.apache.nifi.documentation.DocGenerator.generate(DocGenerator.java:66) at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:786) at org.apache.nifi.NiFi.(NiFi.java:172) at org.apache.nifi.NiFi.(NiFi.java:83) at org.apache.nifi.NiFi.main(NiFi.java:332) 2022-08-08 12:26:10,779 WARN [main] o.apache.nifi.documentation.DocGenerator Unable to
[jira] [Created] (NIFI-10328) Correct Readme For Mailing List/Slack links
Joe Witt created NIFI-10328: --- Summary: Correct Readme For Mailing List/Slack links Key: NIFI-10328 URL: https://issues.apache.org/jira/browse/NIFI-10328 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10137) Change OkHttp 2 to Jersey 2 in Generated Toolkit API
[
https://issues.apache.org/jira/browse/NIFI-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10137:
Fix Version/s: 1.18.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Change OkHttp 2 to Jersey 2 in Generated Toolkit API
>
>
> Key: NIFI-10137
> URL: https://issues.apache.org/jira/browse/NIFI-10137
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Tools and Build
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.18.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The Swagger Codegen configuration in {{nifi-toolkit-api}} uses the default
> HTTP client library setting, which requires OkHttp 2. OkHttp 2 is deprecated,
> and Swagger Codegen does not support OkHttp 3 or 4. Changing the generated
> code to use Jersey 2 provides a supported HTTP client library.
> The default configuration also requires Joda Time, which should be replaced
> with Java 8 modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10272) Conduct 1.17.0 Release
[ https://issues.apache.org/jira/browse/NIFI-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10272. - Resolution: Fixed > Conduct 1.17.0 Release > -- > > Key: NIFI-10272 > URL: https://issues.apache.org/jira/browse/NIFI-10272 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Minor > Fix For: 1.17.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10081) MergeContent processor is not executed when Scheduling Strategy is set to Cron Driven.
[ https://issues.apache.org/jira/browse/NIFI-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572072#comment-17572072 ] Joe Witt commented on NIFI-10081: - For a case where a specific time/time interval is the desire in terms of batching I dont know that we make that easy. This is biased toward a continuous stream of input whereby some various features dictate when it is time to kick off a merged result. We should arguably block the usage of cron scheduling for this processor at least as it is written OR we need to update its behavior to be more appropriate in the case of cron scheduling. I'd be curious to hear what others think who are familiar with this thing. We might need to create a time biased MergeContent and MergeRecordto make handling such cases easier to reason over. > MergeContent processor is not executed when Scheduling Strategy is set to > Cron Driven. > -- > > Key: NIFI-10081 > URL: https://issues.apache.org/jira/browse/NIFI-10081 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.1, 1.16.2 > Environment: RHEL 7.9, Linux 3.10.0-1160.21.1.el7.x86_64 > java version "1.8.0_331" > Java(TM) SE Runtime Environment (build 1.8.0_331-b09) > Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) > Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz > 6 cores >Reporter: Angel Oropeza >Priority: Minor > Labels: crondriven, merge-content, scheduling > Attachments: image-2022-06-01-22-22-32-958.png, > image-2022-06-01-22-33-10-811.png, image-2022-06-01-22-33-47-519.png > > > I was able to replicate my problem using the following configuration: > !image-2022-06-01-22-22-32-958.png! > The MergeContent configuration is as follows > !image-2022-06-01-22-33-10-811.png! > !image-2022-06-01-22-33-47-519.png! > Although the conditions of the MergeContent processor are met, it does not > concatenate the incoming flowfiles. > The last version in which the above flow worked was version 1.15.3. > Any suggestions on how to solve this? Is this a bug? > P.S.: The flow is so designed due to a dependency on only writing one file > per day. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10081) MergeContent processor is not executed when Scheduling Strategy is set to Cron Driven.
[ https://issues.apache.org/jira/browse/NIFI-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572043#comment-17572043 ] Joe Witt commented on NIFI-10081: - [~eneveu] Yeah that makes perfect sense and is a super common case/pattern. What I'm suggesting though is schedule MergeContent to run all the time. As is always the case with creating batches of data there are various characteristics one might want to use to determine a batch is 'ready'. We support any or all of the following at once: - Minimum Number of Entries - Maximum Number of Entries - Min size of the combined entires - Max size of the combined entries - Max Bin Age In your case I'd suggest you likely have a max size you'd like to see. For instance you want no more than 10GB of data batched together or something else. And certainly you want the batch to go out once it is 20 minutes old so for that use 'Max Bin Age' of 20 mins. This will let the processor behave and bundle as designed and give you your desired 20 minute batches (or less if there was a ton of data that met a size or number of entries threshold). . Now having said this presuming you're using ConsumeKafkaRecord (which you should be/want to be most likely) then you should pair this with MergeRecord. Similar otions/logic apply. Long story short - this is a common, powerful, important use case. You have great options to choose from here that achieve high performance and reliable outcomes. Thanks > MergeContent processor is not executed when Scheduling Strategy is set to > Cron Driven. > -- > > Key: NIFI-10081 > URL: https://issues.apache.org/jira/browse/NIFI-10081 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.1, 1.16.2 > Environment: RHEL 7.9, Linux 3.10.0-1160.21.1.el7.x86_64 > java version "1.8.0_331" > Java(TM) SE Runtime Environment (build 1.8.0_331-b09) > Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) > Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz > 6 cores >Reporter: Angel Oropeza >Priority: Minor > Labels: crondriven, merge-content, scheduling > Attachments: image-2022-06-01-22-22-32-958.png, > image-2022-06-01-22-33-10-811.png, image-2022-06-01-22-33-47-519.png > > > I was able to replicate my problem using the following configuration: > !image-2022-06-01-22-22-32-958.png! > The MergeContent configuration is as follows > !image-2022-06-01-22-33-10-811.png! > !image-2022-06-01-22-33-47-519.png! > Although the conditions of the MergeContent processor are met, it does not > concatenate the incoming flowfiles. > The last version in which the above flow worked was version 1.15.3. > Any suggestions on how to solve this? Is this a bug? > P.S.: The flow is so designed due to a dependency on only writing one file > per day. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10081) MergeContent processor is not executed when Scheduling Strategy is set to Cron Driven.
[ https://issues.apache.org/jira/browse/NIFI-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572033#comment-17572033 ] Joe Witt commented on NIFI-10081: - I dont recommend running MergeContent or MergeRecord on such a basis. If you want to kick out batches based on the age reached the properties of MergeContent are likely to result in better and easier to reason over behavior. That processor is designed to be running frequently as those runs are the mechanism by which it most efficiently and correctly creates batches. We should make a blog about this. > MergeContent processor is not executed when Scheduling Strategy is set to > Cron Driven. > -- > > Key: NIFI-10081 > URL: https://issues.apache.org/jira/browse/NIFI-10081 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.1, 1.16.2 > Environment: RHEL 7.9, Linux 3.10.0-1160.21.1.el7.x86_64 > java version "1.8.0_331" > Java(TM) SE Runtime Environment (build 1.8.0_331-b09) > Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) > Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz > 6 cores >Reporter: Angel Oropeza >Priority: Minor > Labels: crondriven, merge-content, scheduling > Attachments: image-2022-06-01-22-22-32-958.png, > image-2022-06-01-22-33-10-811.png, image-2022-06-01-22-33-47-519.png > > > I was able to replicate my problem using the following configuration: > !image-2022-06-01-22-22-32-958.png! > The MergeContent configuration is as follows > !image-2022-06-01-22-33-10-811.png! > !image-2022-06-01-22-33-47-519.png! > Although the conditions of the MergeContent processor are met, it does not > concatenate the incoming flowfiles. > The last version in which the above flow worked was version 1.15.3. > Any suggestions on how to solve this? Is this a bug? > P.S.: The flow is so designed due to a dependency on only writing one file > per day. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10286) C2 API libraries present in root library directory
[
https://issues.apache.org/jira/browse/NIFI-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10286:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> C2 API libraries present in root library directory
> --
>
> Key: NIFI-10286
> URL: https://issues.apache.org/jira/browse/NIFI-10286
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Blocker
> Fix For: 1.17.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The introduction of new Command and Control capabilities introduced several
> new C2 API and implementation modules in multiple locations. Refactoring
> efforts removed the need for {{c2-client-api}} references in
> {{{}NarClassLoaders{}}}, but did not remove all references to C2 client
> classes. As a result of including {{c2-client-api}} in
> {{{}nifi-nar-utils{}}}, several C2 API libraries, as well as the Swagger
> annotations library, are present the the root {{lib}} directory in the
> current main branch.
> The unnecessary references and dependency on {{c2-client-api}} should be
> removed from {{nifi-nar-utils}} to remove these dependencies from the root
> {{lib}} directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10286) C2 API libraries present in root library directory
[
https://issues.apache.org/jira/browse/NIFI-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10286:
Fix Version/s: 1.17.0
> C2 API libraries present in root library directory
> --
>
> Key: NIFI-10286
> URL: https://issues.apache.org/jira/browse/NIFI-10286
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Blocker
> Fix For: 1.17.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The introduction of new Command and Control capabilities introduced several
> new C2 API and implementation modules in multiple locations. Refactoring
> efforts removed the need for {{c2-client-api}} references in
> {{{}NarClassLoaders{}}}, but did not remove all references to C2 client
> classes. As a result of including {{c2-client-api}} in
> {{{}nifi-nar-utils{}}}, several C2 API libraries, as well as the Swagger
> annotations library, are present the the root {{lib}} directory in the
> current main branch.
> The unnecessary references and dependency on {{c2-client-api}} should be
> removed from {{nifi-nar-utils}} to remove these dependencies from the root
> {{lib}} directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10284) HTTP Request Log Missing Authenticated User
[
https://issues.apache.org/jira/browse/NIFI-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10284:
Fix Version/s: 1.17.0
> HTTP Request Log Missing Authenticated User
> ---
>
> Key: NIFI-10284
> URL: https://issues.apache.org/jira/browse/NIFI-10284
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.17.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The framework HTTP {{nifi-request.log}} records the authenticated username,
> when available, for HTTP request that the Jetty server handles. The
> {{RequestAuthenticationFilter}} in the {{nifi-jetty}} module provides
> authenticated user integration for Jetty Requests based on a request
> attribute that a separate Spring Security filter provides.
> Changes to the Jetty Server filter configuration introduced a different
> Headers Writer filter, which wraps the {{HttpServletRequest}}. As a result of
> request wrapping, the {{RequestAuthenticationFilter}} is unable to set the
> authenticated user on the Jetty Request, which results in a null value being
> logged for all HTTP requests in {{nifi-request.log}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10283) adjust display of ListQueue window to handle UTF-8 filenames
[ https://issues.apache.org/jira/browse/NIFI-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571659#comment-17571659 ] Joe Witt commented on NIFI-10283: - Wow. GOod find. Pretty surprised we're not handling that well already... > adjust display of ListQueue window to handle UTF-8 filenames > -- > > Key: NIFI-10283 > URL: https://issues.apache.org/jira/browse/NIFI-10283 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Attachments: listqueue.png, listqueueentry.png > > > Display of list queue information does not seem to handle UTF-8 characters. > Screenshots attached. Information should resemble the following: > > |し回亡丹し工z丹卞工回几.txt| > |اختبار.txt| > |Госагїzатїой.txt| > |æøå.txt| > |1.txt| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10258) Continuously getting the error "ERROR: Failed to index Provenance Events. See logs for more information. " in the Bulletin Board
[ https://issues.apache.org/jira/browse/NIFI-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571543#comment-17571543 ] Joe Witt commented on NIFI-10258: - [~cdeepakreddy20] You'll need to determine what the best course of action is to meet your systems requirements/obligations. But NiFi cannot have an external process injecting itself into its file handling operations for its repositories or we cannot reason over what the result would be. I would disable such virus scanning for the flowfile, content, and provenance repositories as well as the log directory and h2-database directory. Given the information you've shared so far this is likely the problem and the solution to it. If you have data going through the flow which you're concerned about from a virus scanning point of view it is perfectly fine and often done that a processor in the flow would stream the content to a virus scanning endpoint and identify whether any hits are present. I have no specific guidance to share on that but it has been done by many and is pretty powerful. This is a little different than the above paragraph about disable live scanning of these various locations but wanted to mention this. Thanks > Continuously getting the error "ERROR: Failed to index Provenance Events. See > logs for more information. " in the Bulletin Board > > > Key: NIFI-10258 > URL: https://issues.apache.org/jira/browse/NIFI-10258 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.3 > Environment: Operating System: Red Hat Enterprise Linux Server 7.9 > (Maipo) > Architecture: amd 64 > Kernel: Linux 3.10.0-1160.53.1.el7.x86_64 > Java Version:1.8.0_322 >Reporter: Deepak Reddy Chirthani >Priority: Critical > Attachments: Nifi_logs_deepak.txt, Provenance_properties.PNG > > Original Estimate: 336h > Remaining Estimate: 336h > > we have started to use the reporting task *SiteToSiteProvenanceReportingTask > 1.15.3* for auditing purposes on provenance events for a few of our > dataflows. We started to see error quite frequently now in the Bulletin Board. > *ERROR: Failed to index Provenance Events. See logs for more information.* > Also, below are attached snaps of nifi.provenance.properties file and from > logs regarding this error. > Please let me know if you need anything more. > Update: Even though S2SProvenanceReportingTask is stopped, the error still > exisits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10258) Continuously getting the error "ERROR: Failed to index Provenance Events. See logs for more information. " in the Bulletin Board
[ https://issues.apache.org/jira/browse/NIFI-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10258. - Resolution: Information Provided > Continuously getting the error "ERROR: Failed to index Provenance Events. See > logs for more information. " in the Bulletin Board > > > Key: NIFI-10258 > URL: https://issues.apache.org/jira/browse/NIFI-10258 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.3 > Environment: Operating System: Red Hat Enterprise Linux Server 7.9 > (Maipo) > Architecture: amd 64 > Kernel: Linux 3.10.0-1160.53.1.el7.x86_64 > Java Version:1.8.0_322 >Reporter: Deepak Reddy Chirthani >Priority: Critical > Attachments: Nifi_logs_deepak.txt, Provenance_properties.PNG > > Original Estimate: 336h > Remaining Estimate: 336h > > we have started to use the reporting task *SiteToSiteProvenanceReportingTask > 1.15.3* for auditing purposes on provenance events for a few of our > dataflows. We started to see error quite frequently now in the Bulletin Board. > *ERROR: Failed to index Provenance Events. See logs for more information.* > Also, below are attached snaps of nifi.provenance.properties file and from > logs regarding this error. > Please let me know if you need anything more. > Update: Even though S2SProvenanceReportingTask is stopped, the error still > exisits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10277) Intermittent Failures in ConnectionLoadBalanceServerTest
[
https://issues.apache.org/jira/browse/NIFI-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10277:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Intermittent Failures in ConnectionLoadBalanceServerTest
>
>
> Key: NIFI-10277
> URL: https://issues.apache.org/jira/browse/NIFI-10277
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.17.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ConnectionLoadBalanceServerTest}} fails intermittently on automated
> builds, including the recent failure on a Windows build:
> {noformat}
> Error:
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServerTest.testRequestPeerListShouldUseTLS
> Time elapsed: 0.748 s <<< ERROR!
> java.io.IOException: Could not begin listening for incoming connections in
> order to load balance data across the cluster. Please verify the values of
> the 'nifi.cluster.load.balance.port' and 'nifi.cluster.load.balance.host'
> properties as well as the 'nifi.security.*' properties
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer.start(ConnectionLoadBalanceServer.java:86)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer$start.call(Unknown
> Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServerTest.testRequestPeerListShouldUseTLS(ConnectionLoadBalanceServerTest.groovy:77)
> 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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
>
[jira] [Resolved] (NIFI-10278) ConsumeTwitter brittle test breaking build
[ https://issues.apache.org/jira/browse/NIFI-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10278. - Fix Version/s: 1.17.0 Resolution: Fixed > ConsumeTwitter brittle test breaking build > -- > > Key: NIFI-10278 > URL: https://issues.apache.org/jira/browse/NIFI-10278 > Project: Apache NiFi > Issue Type: Test > Environment: > https://github.com/apache/nifi/runs/7506557761?check_suite_focus=true >Reporter: Joe Witt >Assignee: Emilio Setiadarma >Priority: Major > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Error: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.635 > s <<< FAILURE! - in org.apache.nifi.processors.twitter.TestConsumeTwitter > Error: > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream > Time elapsed: 2.521 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <1> but was: <0> > at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at > org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > 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:527) > at > org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360) > at > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream(TestConsumeTwitter.java:79) > 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:725) > 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:149) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84) > at > org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105) > 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.ExecutableInvoker.invoke(ExecutableInvoker.java:104) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66) > 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] [Updated] (NIFI-10279) Increase timeouts in automated tests around NiFi Stateless
[
https://issues.apache.org/jira/browse/NIFI-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10279:
Fix Version/s: 1.17.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Increase timeouts in automated tests around NiFi Stateless
> --
>
> Key: NIFI-10279
> URL: https://issues.apache.org/jira/browse/NIFI-10279
> Project: Apache NiFi
> Issue Type: Task
> Components: Core Framework, Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.17.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> NiFi Stateless tends to be very fast. However, on constrained resources like
> Github Actions, the setup (such as unpacking nars) can take a while. This
> causes intermittent timeouts.
> For example, in the Stateless System Tests, several tests have a timeout of
> 10 seconds. This is generally plenty of time to run on a laptop that's not
> overly taxed. For example, on a 2019 Macbook Pro, the tests run in about 2
> seconds for me. However, we had a period of about 1 week in which Github
> Actions was frequently failing with an error such as:
> {code:java}
> Error:
> org.apache.nifi.stateless.basics.AsyncCommitCallbackIT.testSynchronousCommitCleanupAfterFlowFilesTerminated
> Time elapsed: 10.067 s <<< ERROR!
> 300 {code}
> A timeout of 10 seconds is too restrictive for this environment.
> Similarly, the ExecuteStateless unit test can take a while when it must
> unpack NARs. We occasionally see the following error in the ci-workflow build
> due to a unit test failure:
> {code:java}
> Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 83.578 s <<<
> FAILURE! - in org.apache.nifi.processors.stateless.TestExecuteStateless
> org.apache.nifi.processors.stateless.TestExecuteStateless.testRouteToFailureWithInput
> Time elapsed: 72.185 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <3> but was: <1>
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at
> org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> 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:527)
> at
> org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360)
> at
> org.apache.nifi.processors.stateless.TestExecuteStateless.testRouteToFailureWithInput(TestExecuteStateless.java:104)
> ... {code}
> At first glance, it appears to indicate that data was improperly processed.
> But this occurs only occasionally. This appears to be due the fact that the
> ordering of tests is not guaranteed and can change from invocation to
> invocation. If this test (testRouteToFailureWithInput) is the first test to
> be run, this test can fail. This is because of this line of code in the test:
> {code:java}
> runner.run(3, true, true, 6L); {code}
> It specifies that the processor should run 3 iterations and times out after
> 60,000 milliseconds. If we analyze the log output, we see that indeed this
> was the first test run and this log line attracts a lot of attention:
> {code:java}
> 2022-07-26 03:24:38:527 +0900 [pool-2-thread-1] INFO
> org.apache.nifi.nar.NarUnpacker - NAR loading process took 51455278686
> nanoseconds (51 seconds).{code}
> So here we can see that unpacking NARs took 51 seconds. Indeed, updating the
> test to have a timeout of 100 milliseconds (a very short timeout that we
> expect to trigger) produces the exact same output for me locally.
> We need to use a longer timeout here, as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10278) ConsumeTwitter brittle test breaking build
[ https://issues.apache.org/jira/browse/NIFI-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571070#comment-17571070 ] Joe Witt commented on NIFI-10278: - removed 1.17 indicator for now as also relaxed parallel builds which likely makes this test safer > ConsumeTwitter brittle test breaking build > -- > > Key: NIFI-10278 > URL: https://issues.apache.org/jira/browse/NIFI-10278 > Project: Apache NiFi > Issue Type: Test > Environment: > https://github.com/apache/nifi/runs/7506557761?check_suite_focus=true >Reporter: Joe Witt >Assignee: Emilio Setiadarma >Priority: Major > > Error: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.635 > s <<< FAILURE! - in org.apache.nifi.processors.twitter.TestConsumeTwitter > Error: > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream > Time elapsed: 2.521 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <1> but was: <0> > at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at > org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > 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:527) > at > org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360) > at > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream(TestConsumeTwitter.java:79) > 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:725) > 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:149) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84) > at > org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105) > 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.ExecutableInvoker.invoke(ExecutableInvoker.java:104) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66) > 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] [Updated] (NIFI-10278) ConsumeTwitter brittle test breaking build
[ https://issues.apache.org/jira/browse/NIFI-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10278: Fix Version/s: (was: 1.17.0) > ConsumeTwitter brittle test breaking build > -- > > Key: NIFI-10278 > URL: https://issues.apache.org/jira/browse/NIFI-10278 > Project: Apache NiFi > Issue Type: Test > Environment: > https://github.com/apache/nifi/runs/7506557761?check_suite_focus=true >Reporter: Joe Witt >Assignee: Emilio Setiadarma >Priority: Major > > Error: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.635 > s <<< FAILURE! - in org.apache.nifi.processors.twitter.TestConsumeTwitter > Error: > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream > Time elapsed: 2.521 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <1> but was: <0> > at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at > org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > 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:527) > at > org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360) > at > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream(TestConsumeTwitter.java:79) > 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:725) > 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:149) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84) > at > org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105) > 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.ExecutableInvoker.invoke(ExecutableInvoker.java:104) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66) > 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 > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at >
[jira] [Created] (NIFI-10278) ConsumeTwitter brittle test breaking build
Joe Witt created NIFI-10278: --- Summary: ConsumeTwitter brittle test breaking build Key: NIFI-10278 URL: https://issues.apache.org/jira/browse/NIFI-10278 Project: Apache NiFi Issue Type: Test Environment: https://github.com/apache/nifi/runs/7506557761?check_suite_focus=true Reporter: Joe Witt Assignee: Emilio Setiadarma Error: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.635 s <<< FAILURE! - in org.apache.nifi.processors.twitter.TestConsumeTwitter Error: org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream Time elapsed: 2.521 s <<< FAILURE! org.opentest4j.AssertionFailedError: expected: <1> but was: <0> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) 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:527) at org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360) at org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream(TestConsumeTwitter.java:79) 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:725) 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:149) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84) at org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115) at org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105) 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.ExecutableInvoker.invoke(ExecutableInvoker.java:104) at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66) 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 org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) at java.util.ArrayList.forEach(ArrayList.java:1259) at
[jira] [Updated] (NIFI-10278) ConsumeTwitter brittle test breaking build
[ https://issues.apache.org/jira/browse/NIFI-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10278: Fix Version/s: 1.17.0 > ConsumeTwitter brittle test breaking build > -- > > Key: NIFI-10278 > URL: https://issues.apache.org/jira/browse/NIFI-10278 > Project: Apache NiFi > Issue Type: Test > Environment: > https://github.com/apache/nifi/runs/7506557761?check_suite_focus=true >Reporter: Joe Witt >Assignee: Emilio Setiadarma >Priority: Major > Fix For: 1.17.0 > > > Error: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.635 > s <<< FAILURE! - in org.apache.nifi.processors.twitter.TestConsumeTwitter > Error: > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream > Time elapsed: 2.521 s <<< FAILURE! > org.opentest4j.AssertionFailedError: expected: <1> but was: <0> > at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at > org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > 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:527) > at > org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360) > at > org.apache.nifi.processors.twitter.TestConsumeTwitter.testReceiveSingleTweetInStream(TestConsumeTwitter.java:79) > 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:725) > 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:149) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84) > at > org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105) > 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.ExecutableInvoker.invoke(ExecutableInvoker.java:104) > at > org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66) > 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] [Updated] (NIFI-10277) Intermittent Failures in ConnectionLoadBalanceServerTest
[
https://issues.apache.org/jira/browse/NIFI-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-10277:
Fix Version/s: 1.17.0
> Intermittent Failures in ConnectionLoadBalanceServerTest
>
>
> Key: NIFI-10277
> URL: https://issues.apache.org/jira/browse/NIFI-10277
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.17.0
>
>
> The {{ConnectionLoadBalanceServerTest}} fails intermittently on automated
> builds, including the recent failure on a Windows build:
> {noformat}
> Error:
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServerTest.testRequestPeerListShouldUseTLS
> Time elapsed: 0.748 s <<< ERROR!
> java.io.IOException: Could not begin listening for incoming connections in
> order to load balance data across the cluster. Please verify the values of
> the 'nifi.cluster.load.balance.port' and 'nifi.cluster.load.balance.host'
> properties as well as the 'nifi.security.*' properties
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer.start(ConnectionLoadBalanceServer.java:86)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer$start.call(Unknown
> Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServerTest.testRequestPeerListShouldUseTLS(ConnectionLoadBalanceServerTest.groovy:77)
> 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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
>
[jira] [Commented] (NIFI-10277) Intermittent Failures in ConnectionLoadBalanceServerTest
[
https://issues.apache.org/jira/browse/NIFI-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570981#comment-17570981
]
Joe Witt commented on NIFI-10277:
-
will keep an eye on this and review/merge. Dont want this tripping up our RC
builds
> Intermittent Failures in ConnectionLoadBalanceServerTest
>
>
> Key: NIFI-10277
> URL: https://issues.apache.org/jira/browse/NIFI-10277
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.17.0
>
>
> The {{ConnectionLoadBalanceServerTest}} fails intermittently on automated
> builds, including the recent failure on a Windows build:
> {noformat}
> Error:
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServerTest.testRequestPeerListShouldUseTLS
> Time elapsed: 0.748 s <<< ERROR!
> java.io.IOException: Could not begin listening for incoming connections in
> order to load balance data across the cluster. Please verify the values of
> the 'nifi.cluster.load.balance.port' and 'nifi.cluster.load.balance.host'
> properties as well as the 'nifi.security.*' properties
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer.start(ConnectionLoadBalanceServer.java:86)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer$start.call(Unknown
> Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServerTest.testRequestPeerListShouldUseTLS(ConnectionLoadBalanceServerTest.groovy:77)
> 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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
>
[jira] [Updated] (NIFI-10272) Conduct 1.17.0 Release
[ https://issues.apache.org/jira/browse/NIFI-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10272: Fix Version/s: 1.17.0 > Conduct 1.17.0 Release > -- > > Key: NIFI-10272 > URL: https://issues.apache.org/jira/browse/NIFI-10272 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Minor > Fix For: 1.17.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10266) Use latest NAR Maven Plugin 1.3.5
[ https://issues.apache.org/jira/browse/NIFI-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10266: Resolution: Fixed Status: Resolved (was: Patch Available) > Use latest NAR Maven Plugin 1.3.5 > - > > Key: NIFI-10266 > URL: https://issues.apache.org/jira/browse/NIFI-10266 > Project: Apache NiFi > Issue Type: Task >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 1.17.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update NAR plugin version to newly released 1.3.5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10268) Upgrade to Spring Framework 5.3.22 and Spring Boot 2.7.2
[ https://issues.apache.org/jira/browse/NIFI-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10268: Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade to Spring Framework 5.3.22 and Spring Boot 2.7.2 > > > Key: NIFI-10268 > URL: https://issues.apache.org/jira/browse/NIFI-10268 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Spring Framework > [5.3.22|https://github.com/spring-projects/spring-framework/releases/tag/v5.3.22] > and Spring Boot > [2.7.2|https://github.com/spring-projects/spring-boot/releases/tag/v2.7.2] > for NiFi Registry include several minor bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10267) Upgrade Netty to 4.1.79
[ https://issues.apache.org/jira/browse/NIFI-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10267: Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Netty to 4.1.79 > --- > > Key: NIFI-10267 > URL: https://issues.apache.org/jira/browse/NIFI-10267 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Netty [4.1.79|https://netty.io/news/2022/07/11/4-1-79-Final.html] and > [4.1.78|https://netty.io/news/2022/06/14/4-1-78-Final.html] include several > minor bug fixes over the current version 4.1.77. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10271) Upgrade Xerces to 2.12.2
[ https://issues.apache.org/jira/browse/NIFI-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10271: Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Xerces to 2.12.2 > > > Key: NIFI-10271 > URL: https://issues.apache.org/jira/browse/NIFI-10271 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Several extension components, including Scripting Processors and Media > Processors, depend on Xerces 2.12.1, which is vulnerable to resource > exhaustion when parsing crafted XML documents, as described in > [CVE-2022-23437|https://nvd.nist.gov/vuln/detail/CVE-2022-23437]. > Xerces 2.12.2 addresses CVE-2022-23437. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10269) Upgrade H2 to 2.1.214
[ https://issues.apache.org/jira/browse/NIFI-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10269: Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade H2 to 2.1.214 > - > > Key: NIFI-10269 > URL: https://issues.apache.org/jira/browse/NIFI-10269 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > H2 [2.1.214|https://h2database.com/html/changelog.html] includes several > improvements over version 2.1.210, such as correcting several exception cases > and providing better error messaging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10270) Upgrade AWS SDK to 1.2.267
[ https://issues.apache.org/jira/browse/NIFI-10270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10270: Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade AWS SDK to 1.2.267 > -- > > Key: NIFI-10270 > URL: https://issues.apache.org/jira/browse/NIFI-10270 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, MiNiFi >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Several NiFi extension components depend on version 1 of the AWS SDK for > various service operations. > [CVE-2022-31159|https://nvd.nist.gov/vuln/detail/CVE-2022-31159] impacts the > S3 TransferManager in AWS SDK versions prior to 1.2.260. > Although NiFi components do not include direct usage of the S3 > TransferManager, library references should be upgraded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10272) Conduct 1.17.0 Release
Joe Witt created NIFI-10272: --- Summary: Conduct 1.17.0 Release Key: NIFI-10272 URL: https://issues.apache.org/jira/browse/NIFI-10272 Project: Apache NiFi Issue Type: Task Components: Tools and Build Reporter: Joe Witt Assignee: Joe Witt -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10268) Upgrade to Spring Framework 5.3.22 and Spring Boot 2.7.2
[ https://issues.apache.org/jira/browse/NIFI-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10268: Fix Version/s: 1.17.0 > Upgrade to Spring Framework 5.3.22 and Spring Boot 2.7.2 > > > Key: NIFI-10268 > URL: https://issues.apache.org/jira/browse/NIFI-10268 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.17.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Spring Framework > [5.3.22|https://github.com/spring-projects/spring-framework/releases/tag/v5.3.22] > and Spring Boot > [2.7.2|https://github.com/spring-projects/spring-boot/releases/tag/v2.7.2] > for NiFi Registry include several minor bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10267) Upgrade Netty to 4.1.79
[ https://issues.apache.org/jira/browse/NIFI-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10267: Fix Version/s: 1.17.0 > Upgrade Netty to 4.1.79 > --- > > Key: NIFI-10267 > URL: https://issues.apache.org/jira/browse/NIFI-10267 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Netty [4.1.79|https://netty.io/news/2022/07/11/4-1-79-Final.html] and > [4.1.78|https://netty.io/news/2022/06/14/4-1-78-Final.html] include several > minor bug fixes over the current version 4.1.77. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10270) Upgrade AWS SDK to 1.2.267
[ https://issues.apache.org/jira/browse/NIFI-10270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10270: Fix Version/s: 1.17.0 > Upgrade AWS SDK to 1.2.267 > -- > > Key: NIFI-10270 > URL: https://issues.apache.org/jira/browse/NIFI-10270 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, MiNiFi >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Several NiFi extension components depend on version 1 of the AWS SDK for > various service operations. > [CVE-2022-31159|https://nvd.nist.gov/vuln/detail/CVE-2022-31159] impacts the > S3 TransferManager in AWS SDK versions prior to 1.2.260. > Although NiFi components do not include direct usage of the S3 > TransferManager, library references should be upgraded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10271) Upgrade Xerces to 2.12.2
[ https://issues.apache.org/jira/browse/NIFI-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10271: Fix Version/s: 1.17.0 > Upgrade Xerces to 2.12.2 > > > Key: NIFI-10271 > URL: https://issues.apache.org/jira/browse/NIFI-10271 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Several extension components, including Scripting Processors and Media > Processors, depend on Xerces 2.12.1, which is vulnerable to resource > exhaustion when parsing crafted XML documents, as described in > [CVE-2022-23437|https://nvd.nist.gov/vuln/detail/CVE-2022-23437]. > Xerces 2.12.2 addresses CVE-2022-23437. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10269) Upgrade H2 to 2.1.214
[ https://issues.apache.org/jira/browse/NIFI-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10269: Fix Version/s: 1.17.0 > Upgrade H2 to 2.1.214 > - > > Key: NIFI-10269 > URL: https://issues.apache.org/jira/browse/NIFI-10269 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.17.0 > > Time Spent: 10m > Remaining Estimate: 0h > > H2 [2.1.214|https://h2database.com/html/changelog.html] includes several > improvements over version 2.1.210, such as correcting several exception cases > and providing better error messaging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10258) Continuously getting the error "ERROR: Failed to index Provenance Events. See logs for more information. " in the Bulletin Board
[ https://issues.apache.org/jira/browse/NIFI-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570177#comment-17570177 ] Joe Witt commented on NIFI-10258: - So is there any kind anti-virus or file scanning tool employed on this system? Is this an NFS mount or anything otherwise special? > Continuously getting the error "ERROR: Failed to index Provenance Events. See > logs for more information. " in the Bulletin Board > > > Key: NIFI-10258 > URL: https://issues.apache.org/jira/browse/NIFI-10258 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.3 > Environment: Operating System: Red Hat Enterprise Linux Server 7.9 > (Maipo) > Architecture: amd 64 > Kernel: Linux 3.10.0-1160.53.1.el7.x86_64 > Java Version:1.8.0_322 >Reporter: Deepak Reddy Chirthani >Priority: Critical > Attachments: Nifi_logs_deepak.txt, Provenance_properties.PNG > > Original Estimate: 336h > Remaining Estimate: 336h > > we have started to use the reporting task *SiteToSiteProvenanceReportingTask > 1.15.3* for auditing purposes on provenance events for a few of our > dataflows. We started to see error quite frequently now in the Bulletin Board. > *ERROR: Failed to index Provenance Events. See logs for more information.* > Also, below are attached snaps of nifi.provenance.properties file and from > logs regarding this error. > Please let me know if you need anything more. > Update: Even though S2SProvenanceReportingTask is stopped, the error still > exisits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10266) Use latest NAR Maven Plugin 1.3.5
[ https://issues.apache.org/jira/browse/NIFI-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570173#comment-17570173 ] Joe Witt commented on NIFI-10266: - will review/merge before RC1 > Use latest NAR Maven Plugin 1.3.5 > - > > Key: NIFI-10266 > URL: https://issues.apache.org/jira/browse/NIFI-10266 > Project: Apache NiFi > Issue Type: Task >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Update NAR plugin version to newly released 1.3.5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10266) Use latest NAR Maven Plugin 1.3.5
[ https://issues.apache.org/jira/browse/NIFI-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10266: Fix Version/s: 1.17.0 > Use latest NAR Maven Plugin 1.3.5 > - > > Key: NIFI-10266 > URL: https://issues.apache.org/jira/browse/NIFI-10266 > Project: Apache NiFi > Issue Type: Task >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Major > Fix For: 1.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Update NAR plugin version to newly released 1.3.5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-6848) Migrate NiFi Site to ASF git build/deploy
[ https://issues.apache.org/jira/browse/NIFI-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-6848: --- Fix Version/s: (was: 1.17.0) > Migrate NiFi Site to ASF git build/deploy > - > > Key: NIFI-6848 > URL: https://issues.apache.org/jira/browse/NIFI-6848 > Project: Apache NiFi > Issue Type: Task > Components: Documentation Website >Reporter: Aldrin Piri >Assignee: David Handermann >Priority: Major > > Currently, NiFi's site is versioned in > https://gitbox.apache.org/repos/asf?p=nifi-site.git but a scripted process > via grunt, manually executed, is used to publish this site to the legacy CMS > (svn) system. The CMS system is largely deprecated and targeted for EOL in > the upcoming months. We should look to transition our repository/site over > to the new approach outlined at https://s.apache.org/asfyaml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10223) Add ListGoogleDrive processor
[ https://issues.apache.org/jira/browse/NIFI-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10223: Issue Type: New Feature (was: Task) > Add ListGoogleDrive processor > - > > Key: NIFI-10223 > URL: https://issues.apache.org/jira/browse/NIFI-10223 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 1.17.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Add a processor that is able list files within a given Google Drive folder. > Recursively on not recursively, configurable by the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10263) Update Website Privacy and License Links
[ https://issues.apache.org/jira/browse/NIFI-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10263: Fix Version/s: (was: 1.17.0) > Update Website Privacy and License Links > > > Key: NIFI-10263 > URL: https://issues.apache.org/jira/browse/NIFI-10263 > Project: Apache NiFi > Issue Type: Task > Components: Documentation Website >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > > The [Apache Project Website > Checks|https://whimsy.apache.org/site/project/nifi] system performs an > automated evaluation of project websites for adherence to Apache Software > Foundation policies. > The current status indicates that the License link should be updated, and a > link should be added to the ASF Privacy Policy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10264) Update Website People Listing
[ https://issues.apache.org/jira/browse/NIFI-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-10264: Fix Version/s: (was: 1.17.0) > Update Website People Listing > - > > Key: NIFI-10264 > URL: https://issues.apache.org/jira/browse/NIFI-10264 > Project: Apache NiFi > Issue Type: Task > Components: Documentation Website >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > > The listing of Apache NiFi Team members does not reflect the current roster > information. The list should be updated to reflect PMC and Committers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10117) Allow VersionedComponentSynchronizer to update remote ports
[ https://issues.apache.org/jira/browse/NIFI-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt resolved NIFI-10117. - Resolution: Fixed > Allow VersionedComponentSynchronizer to update remote ports > --- > > Key: NIFI-10117 > URL: https://issues.apache.org/jira/browse/NIFI-10117 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joe Gresock >Assignee: Joe Gresock >Priority: Major > Fix For: 1.17.0 > > Time Spent: 1h > Remaining Estimate: 0h > > The StandardVersionedComponentSynchronizer allows updates to > VersionedRemoteProcessGroups, and appears to be intended to allow updates to > the VersionedRemoteGroupPorts enclosed, but updates to these fields, such as > batchSize, are not applied to the flow. > It should be possible to update the batchSize, > concurrentlySchedulableTaskCount, and useCompression fields. -- This message was sent by Atlassian Jira (v8.20.10#820010)
