[jira] [Comment Edited] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[ https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831362#comment-17831362 ] Stephanie Ambrose edited comment on NIFI-12918 at 3/27/24 2:05 PM: --- Okay, so after some back and forth here is my final conclusion to this bug: I've submitted two PRs [https://github.com/apache/nifi/pull/8572/checks] <-- for support/1.x branch [https://github.com/apache/nifi/pull/8536/checks] <-- for main branch Here is what's happening. If you run a versioned stateless flow that has sub-versioned progress group, there is a NullPointerException thrown on the build method of StandardVersionControlInformation where there is a non-null requirement on "registryId". Code has changed in main versus support/1.x, but the bug exists on both. What I've found is the JerseyClient calls that are made to map the response from the registry-api back to the higher level VersionedProcessGroup -> VersionedFlowCoordinates both return JSON where the VersionedFlowCoordinates > registryId is always null. Now in the main branch, stateless uses some of these new "synchronizer" classes, so the best place to insert a solution is to add an else on the null check where the code runs the "determineRegistryId" method and set the value to "1" for versioned flows that do not have a registryId associated to them. Doing this passes all of the integration tests and code checks and fixes the bug. Since this class does not exist in the 1.x support branch, my best solution is to just comment out the null check (this breaks integration tests in main, but not in 1.x). I continued to look further at this idea of a "registryId" within the registry api code. The GET method on buckets/flow/version returns the same class that the stateless code uses to map into on the JerseyClient call. I then looked at the api code to POST new versioned flows, and it also expect the json as a parameter to match the same class. Well, since there is no "non-null" requirement on the registryId, versioned flows are stored in the database (or whichever storage adapter used) with this property as null. I did not check to see if the latest NiFi Registry UI is now setting this property, but making it non-null would break any older version of registry and not be backwards compatible. Therefore, the only solution at this point to fix stateless NiFi in its current state is to just set registryId to "1" if it is null. I believe this code is still probably prototype being worked and evolving, so this will be a temporary fix until those mandates are in place on a concept of "registryId". [~markap14] was (Author: JIRAUSER299049): Okay, so after some back and forth here is my final conclusion to this bug: I've submitted two PRs [https://github.com/apache/nifi/pull/8572/checks] <-- for support/1.x branch [https://github.com/apache/nifi/pull/8536/checks] <-- for main branch Here is what's happening. If you run a versioned stateless flow that has sub-versioned progress group, there is a NullPointerException thrown on the build method of StandardVersionControlInformation where there is a non-null requirement on "registryId". Code has changed in main versus support/1.x, but the bug exists on both. What I've found is the JerseyClient calls that are made to map the response from the registry-api back to the higher level VersionedProcessGroup -> VersionedFlowCoordinates both return JSON where the VersionedFlowCoordinates > registryId is always null. Now in the main branch, stateless uses some of these new "synchronizer" classes, so the best place to insert a solution is to add an else on the null check where the code runs the "determineRegistryId" method and set the value to "1" for versioned flows that do not have a registryId associated to them. Doing this passes all of the integration tests and code checks and fixes the bug. Since this class does not exist in the 1.x support branch, my best solution is to just comment out the null check (this breaks integration tests in main, but not in 1.x). I continued to look further at this idea of a "registryId" within the registry api code. The GET method on buckets/flow/version returns the same class that the stateless code uses to map into on the JerseyClient call. I then looked at the api code to POST new versioned flows, and it also expect the json as a parameter to match the same class. Well, since there is no "non-null" requirement on the registryId, versioned flows are stored in the database (or whichever storage adapter used) with this property as null. I did not check to see if the latest NiFi Registry UI is now setting this property, but making it non-null would break any older version of registry and not be backwards compatible. Therefore, the only solution at this point to fix stateless NiFi in its current state is to just set registryId to
[jira] [Commented] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831362#comment-17831362
]
Stephanie Ambrose commented on NIFI-12918:
--
Okay, so after some back and forth here is my final conclusion to this bug:
I've submitted two PRs
[https://github.com/apache/nifi/pull/8572/checks] <-- for support/1.x branch
[https://github.com/apache/nifi/pull/8536/checks] <-- for main branch
Here is what's happening. If you run a versioned stateless flow that has
sub-versioned progress group, there is a NullPointerException thrown on the
build method of StandardVersionControlInformation where there is a non-null
requirement on "registryId".
Code has changed in main versus support/1.x, but the bug exists on both. What
I've found is the JerseyClient calls that are made to map the response from the
registry-api back to the higher level VersionedProcessGroup ->
VersionedFlowCoordinates both return JSON where the VersionedFlowCoordinates >
registryId is always null. Now in the main branch, stateless uses some of these
new "synchronizer" classes, so the best place to insert a solution is to add an
else on the null check where the code runs the "determineRegistryId" method and
set the value to "1" for versioned flows that do not have a registryId
associated to them. Doing this passes all of the integration tests and code
checks and fixes the bug. Since this class does not exist in the 1.x support
branch, my best solution is to just comment out the null check (this breaks
integration tests in main, but not in 1.x).
I continued to look further at this idea of a "registryId" within the registry
api code. The GET method on buckets/flow/version returns the same class that
the stateless code uses to map into on the JerseyClient call. I then looked at
the api code to POST new versioned flows, and it also expect the json as a
parameter to match the same class. Well, since there is no "non-null"
requirement on the registryId, versioned flows are stored in the database (or
whichever storage adapter used) with this property as null. I did not check to
see if the latest NiFi Registry UI is now setting this property, but making it
non-null would break any older version of registry and not be backwards
compatible. Therefore, the only solution at this point to fix stateless NiFi in
its current state is to just set registryId to "1" if it is null. I believe
this code is still probably prototype being worked and evolving, so this will
be a temporary fix until those mandates are in place on a concept of
"registryId".
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one and commit that to its own version
> control, it will throw a NullPointerException:
> *NOTE: This error only occurs for stateless nifi processing.*
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
>
[jira] [Commented] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829955#comment-17829955
]
Stephanie Ambrose commented on NIFI-12918:
--
[~dstiegli1] - I confirmed the problem exists on 2.0 as well as 1.x. I also
confirmed that the PR submitted fixes the problem on both versions. Apparently,
there is an integration test that is now failing, so I'm troubleshooting that
now.
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one and commit that to its own version
> control, it will throw a NullPointerException:
> *NOTE: This error only occurs for stateless nifi processing.*
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
>
[jira] [Updated] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephanie Ambrose updated NIFI-12918:
-
Description:
If you create a process group and commit that to version control, and then add
a sub-process group under that one and commit that to its own version control,
it will throw a NullPointerException:
*NOTE: This error only occurs for stateless nifi processing.*
{code:java}
2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
o.a.nifi.groups.StandardProcessGroup
StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
2024-03-15T12:25:38.570693223Z Exception in thread "main"
java.lang.NullPointerException: Registry ID must be specified
at java.base/java.util.Objects.requireNonNull(Unknown Source)
2024-03-15T12:25:38.570722016Z at
org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
2024-03-15T12:25:38.570725111Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
2024-03-15T12:25:38.570729455Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
2024-03-15T12:25:38.573083029Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
2024-03-15T12:25:38.573086447Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
2024-03-15T12:25:38.573092747Z at
org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
2024-03-15T12:25:38.573095677Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
2024-03-15T12:25:38.573098999Z at
org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
at
org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
at
org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
2024-03-15T12:25:38.573108177Z at
org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
at
org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
{code}
When stepping through the debugger, it appears the "registryId" property is
null. The JerseyClient call is supposed to map the response from registry to
the proper class, but registryId is never set:
{code:java}
java.lang.Thread.State: RUNNABLE
at
org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
Source:-1)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source:-1)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source:-1)
at java.lang.reflect.Method.invoke(Unknown Source:-1)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
at
com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
at
com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244)
at
com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:28)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
[jira] [Updated] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephanie Ambrose updated NIFI-12918:
-
Fix Version/s: (was: 1.26.0)
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one which is also under a separate version
> control, it will throw a NullPointerException.
>
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:28)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
>
[jira] [Commented] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828474#comment-17828474
]
Stephanie Ambrose commented on NIFI-12918:
--
[https://github.com/apache/nifi/pull/8533] <-- for support/1.x branch
[https://github.com/apache/nifi/pull/8536] <-- for main branch
(We are still dependent on the 1. versions and need the fix available in the
next 1. release)
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Fix For: 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one which is also under a separate version
> control, it will throw a NullPointerException.
>
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
>
[jira] [Comment Edited] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828469#comment-17828469
]
Stephanie Ambrose edited comment on NIFI-12918 at 3/19/24 5:54 PM:
---
[~dstiegli1] - Yes, I believe so. I'm submitting separate patch to support the
main branch now. (same change)
was (Author: JIRAUSER299049):
Submitting separate patch to support the main branch.
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Fix For: 1.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one which is also under a separate version
> control, it will throw a NullPointerException.
>
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
>
[jira] [Commented] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828469#comment-17828469
]
Stephanie Ambrose commented on NIFI-12918:
--
Submitting separate patch to support the main branch.
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Fix For: 1.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one which is also under a separate version
> control, it will throw a NullPointerException.
>
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:28)
> at
>
[jira] [Updated] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephanie Ambrose updated NIFI-12918:
-
Fix Version/s: 1.26.0
Status: Patch Available (was: In Progress)
Patch was submitted based off of the support/1.x branch.
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Fix For: 1.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one which is also under a separate version
> control, it will throw a NullPointerException.
>
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244)
> at
>
[jira] [Assigned] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephanie Ambrose reassigned NIFI-12918:
Assignee: Stephanie Ambrose
> Stateless NiFi NullPointerException on versioned PGs
>
>
> Key: NIFI-12918
> URL: https://issues.apache.org/jira/browse/NIFI-12918
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Stephanie Ambrose
>Assignee: Stephanie Ambrose
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you create a process group and commit that to version control, and then
> add a sub-process group under that one which is also under a separate version
> control, it will throw a NullPointerException.
>
> {code:java}
> 2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
> o.a.nifi.groups.StandardProcessGroup
> StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
> Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
> 2024-03-15T12:25:38.570693223Z Exception in thread "main"
> java.lang.NullPointerException: Registry ID must be specified
> at java.base/java.util.Objects.requireNonNull(Unknown Source)
> 2024-03-15T12:25:38.570722016Zat
> org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
> 2024-03-15T12:25:38.570725111Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
> 2024-03-15T12:25:38.570729455Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
> 2024-03-15T12:25:38.573083029Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
> 2024-03-15T12:25:38.573086447Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
> 2024-03-15T12:25:38.573092747Zat
> org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
> 2024-03-15T12:25:38.573095677Zat
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
> 2024-03-15T12:25:38.573098999Zat
> org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
> at
> org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
> 2024-03-15T12:25:38.573108177Zat
> org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
> at
> org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
> {code}
> When stepping through the debugger, it appears the "registryId" property is
> null. The JerseyClient call is supposed to map the response from registry to
> the proper class, but registryId is never set:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
> Source:-1)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source:-1)
> at java.lang.reflect.Method.invoke(Unknown Source:-1)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
> at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244)
> at
> com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:28)
> at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
>
[jira] [Created] (NIFI-12918) Stateless NiFi NullPointerException on versioned PGs
Stephanie Ambrose created NIFI-12918:
Summary: Stateless NiFi NullPointerException on versioned PGs
Key: NIFI-12918
URL: https://issues.apache.org/jira/browse/NIFI-12918
Project: Apache NiFi
Issue Type: Bug
Reporter: Stephanie Ambrose
If you create a process group and commit that to version control, and then add
a sub-process group under that one which is also under a separate version
control, it will throw a NullPointerException.
{code:java}
2024-03-15T12:25:38.565156967Z 2024-03-15 12:25:38,564 INFO [main]
o.a.nifi.groups.StandardProcessGroup
StandardProcessGroup[identifier=9688e64b-3f4a-3668-81b9-e25d9ea61454,name=Sub
Group] added to StandardProcessGroup[identifier=stateless-flow,name=Test Flow]
2024-03-15T12:25:38.570693223Z Exception in thread "main"
java.lang.NullPointerException: Registry ID must be specified
at java.base/java.util.Objects.requireNonNull(Unknown Source)
2024-03-15T12:25:38.570722016Z at
org.apache.nifi.registry.flow.StandardVersionControlInformation$Builder.build(StandardVersionControlInformation.java:134)
2024-03-15T12:25:38.570725111Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:354)
2024-03-15T12:25:38.570729455Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.addProcessGroup(StandardVersionedComponentSynchronizer.java:1185)
at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronizeChildGroups(StandardVersionedComponentSynchronizer.java:528)
2024-03-15T12:25:38.573083029Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:426)
2024-03-15T12:25:38.573086447Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.lambda$synchronize$0(StandardVersionedComponentSynchronizer.java:265)
2024-03-15T12:25:38.573092747Z at
org.apache.nifi.controller.flow.AbstractFlowManager.withParameterContextResolution(AbstractFlowManager.java:551)
2024-03-15T12:25:38.573095677Z at
org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.synchronize(StandardVersionedComponentSynchronizer.java:260)
2024-03-15T12:25:38.573098999Z at
org.apache.nifi.groups.StandardProcessGroup.synchronizeFlow(StandardProcessGroup.java:3977)
at
org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3957)
at
org.apache.nifi.stateless.engine.StandardStatelessEngine.createFlow(StandardStatelessEngine.java:180)
2024-03-15T12:25:38.573108177Z at
org.apache.nifi.stateless.flow.StandardStatelessDataflowFactory.createDataflow(StandardStatelessDataflowFactory.java:243)
at
org.apache.nifi.stateless.bootstrap.StatelessBootstrap.createDataflow(StatelessBootstrap.java:73)
{code}
When stepping through the debugger, it appears the "registryId" property is
null. The JerseyClient call is supposed to map the response from registry to
the proper class, but registryId is never set:
{code:java}
java.lang.Thread.State: RUNNABLE
at
org.apache.nifi.flow.VersionedProcessGroup.setVersionedFlowCoordinates(VersionedProcessGroup.java:150)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Unknown
Source:-1)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source:-1)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source:-1)
at java.lang.reflect.Method.invoke(Unknown Source:-1)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:141)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
at
com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:359)
at
com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244)
at
com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:28)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:314)
at
[jira] [Resolved] (NIFI-12780) Stateless NiFi properties missing in stateless.properties base config
[ https://issues.apache.org/jira/browse/NIFI-12780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose resolved NIFI-12780. -- Resolution: Won't Fix Ignore, we have a way to support camelCase. > Stateless NiFi properties missing in stateless.properties base config > - > > Key: NIFI-12780 > URL: https://issues.apache.org/jira/browse/NIFI-12780 > Project: Apache NiFi > Issue Type: Bug >Reporter: Stephanie Ambrose >Priority: Major > > These new properties from NIFI-11471 need to be added to the base > stateless.properties file otherwise you won't be able to override them with > environment variables in the replace docker scripts: > > nifi.stateless.component.enableTimeout > nifi.stateless.processor.startTimeout > > Alternatively, make the properties not case-sensitive. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12780) Stateless NiFi properties missing in stateless.properties base config
[ https://issues.apache.org/jira/browse/NIFI-12780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose updated NIFI-12780: - Description: These new properties from NIFI-11471 need to be added to the base stateless.properties file otherwise you won't be able to override them with environment variables in the replace docker scripts: nifi.stateless.component.enableTimeout nifi.stateless.processor.startTimeout Alternatively, make the properties not case-sensitive. was: These new properties from NIFI-11471 need to be added to the base stateless.properties file otherwise you won't be able to override them with environment variables in the replace docker scripts: nifi.stateless.component.enableTimeout nifi.stateless.processor.startTimeout > Stateless NiFi properties missing in stateless.properties base config > - > > Key: NIFI-12780 > URL: https://issues.apache.org/jira/browse/NIFI-12780 > Project: Apache NiFi > Issue Type: Bug >Reporter: Stephanie Ambrose >Priority: Major > > These new properties from NIFI-11471 need to be added to the base > stateless.properties file otherwise you won't be able to override them with > environment variables in the replace docker scripts: > > nifi.stateless.component.enableTimeout > nifi.stateless.processor.startTimeout > > Alternatively, make the properties not case-sensitive. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12780) Stateless NiFi properties missing in stateless.properties base config
Stephanie Ambrose created NIFI-12780: Summary: Stateless NiFi properties missing in stateless.properties base config Key: NIFI-12780 URL: https://issues.apache.org/jira/browse/NIFI-12780 Project: Apache NiFi Issue Type: Bug Reporter: Stephanie Ambrose These new properties from NIFI-11471 need to be added to the base stateless.properties file otherwise you won't be able to override them with environment variables in the replace docker scripts: nifi.stateless.component.enableTimeout nifi.stateless.processor.startTimeout -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11812) Stateless hardcodes "nexus" as the only extension option - Requesting NiFi Registry and/or S3 as additional ExtensionClient options
Stephanie Ambrose created NIFI-11812: Summary: Stateless hardcodes "nexus" as the only extension option - Requesting NiFi Registry and/or S3 as additional ExtensionClient options Key: NIFI-11812 URL: https://issues.apache.org/jira/browse/NIFI-11812 Project: Apache NiFi Issue Type: New Feature Reporter: Stephanie Ambrose Right now stateless NiFi has a hard-coded check on extension type of "nexus" on line 302 of StandardStatelessDataflowFactory. It would be nice to configure stateless to pull nars from additional extensions such as NiFi Registry and/or S3. "stateful" NiFi allows you to set the nar provider to NiFi Registry, which can be configured to store to S3. It'd be nice to have this feature for stateless as well versus being tied to only nexus. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (NIFI-11231) Stateless Nifi Supports Sensitive Parameter Context Variables
[ https://issues.apache.org/jira/browse/NIFI-11231 ]
Stephanie Ambrose deleted comment on NIFI-11231:
--
was (Author: JIRAUSER299049):
[~jgresock] Remember, this was for overriding values in the
stateless.properties file, not for flow environment variables. For example, you
can't override this property via command line:
nifi.stateless.security.keystorePassword the same way your override some other
values in the flow and engine property files. I'd want to run something like:
command: ["/bin/sh", "-c", "/opt/nifi/nifi-current/bin/nifi-stateless.sh -c -p
\"nifi.stateless.security.keystorePasswd=${KEYSTORE_PASSWORD}\""]
> Stateless Nifi Supports Sensitive Parameter Context Variables
> -
>
> Key: NIFI-11231
> URL: https://issues.apache.org/jira/browse/NIFI-11231
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Stateless
>Affects Versions: 1.20.0
>Reporter: Dye357
>Assignee: Stephanie Ambrose
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently Sensitive Parameter Context Variables are not supported in
> Stateless Nifi - this is due to StatelessFlowManager being stubbed to throw a
> "Not Implemented" exception when providing a process group configured with a
> secure Parameter Context variable.
> Desired functionality: Sensitive Parameter Context Variables can be used with
> stateless Nifi. If a process group contains a Sensitive Parameter Context
> Variable the context is used to hydrate all parameters within the provided
> flow including any marked sensitive.
> Acceptance Criteria: Process Groups using secure parameters can be used in
> stateless Nifi.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11231) Stateless Nifi Supports Sensitive Parameter Context Variables
[
https://issues.apache.org/jira/browse/NIFI-11231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737104#comment-17737104
]
Stephanie Ambrose commented on NIFI-11231:
--
[~jgresock] Remember, this was for overriding values in the
stateless.properties file, not for flow environment variables. For example, you
can't override this property via command line:
nifi.stateless.security.keystorePassword the same way your override some other
values in the flow and engine property files. I'd want to run something like:
command: ["/bin/sh", "-c", "/opt/nifi/nifi-current/bin/nifi-stateless.sh -c -p
\"nifi.stateless.security.keystorePasswd=${KEYSTORE_PASSWORD}\""]
> Stateless Nifi Supports Sensitive Parameter Context Variables
> -
>
> Key: NIFI-11231
> URL: https://issues.apache.org/jira/browse/NIFI-11231
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Stateless
>Affects Versions: 1.20.0
>Reporter: Dye357
>Assignee: Stephanie Ambrose
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently Sensitive Parameter Context Variables are not supported in
> Stateless Nifi - this is due to StatelessFlowManager being stubbed to throw a
> "Not Implemented" exception when providing a process group configured with a
> secure Parameter Context variable.
> Desired functionality: Sensitive Parameter Context Variables can be used with
> stateless Nifi. If a process group contains a Sensitive Parameter Context
> Variable the context is used to hydrate all parameters within the provided
> flow including any marked sensitive.
> Acceptance Criteria: Process Groups using secure parameters can be used in
> stateless Nifi.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11650) Stateless NiFi does not support ssl properties passed in from environment variables
[
https://issues.apache.org/jira/browse/NIFI-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephanie Ambrose updated NIFI-11650:
-
Description:
When deploying stateless NiFi in an environment like k8s, we have the
stateless.properties file as a configMap. We need to pass in the keystore
password, retrieved by the k8s secret (or environment variable). According to
the stateless documentation, this should be supported; however, it looks like
the ssl properties specifically don't allow for override. For example, I'm
trying to pass this in when running stateless from my deployment.yaml:
command:
["/bin/sh", "-c", "/opt/nifi/nifi-current/bin/nifi-stateless.sh -c -p
\"nifi.stateless.security.keystorePasswd=${KEYSTORE_PASSWORD}\""]
Similarly to how the env-flow-config.properties file can reference environment
variables with env\{VAR_NAME}, the stateless.properties file should be able to
do the same.
The expected behavior would be that the nifi.stateless.security.keystorePasswd
property in stateless.properties would be updated by environment variables.
Documentation referenced here
([https://github.com/apache/nifi/blob/main/nifi-stateless/nifi-stateless-assembly/README.md#passing-parameters)]
Chatted briefly w/ Joe Gresock to verify and requested a ticket be submitted.
was:
When deploying stateless NiFi in an environment like k8s, we have the
stateless.properties file as a configMap. We need to pass in the keystore
password, retrieved by the k8s secret (or environment variable). According to
the stateless documentation, this should be supported; however, it looks like
the ssl properties specifically don't allow for override. For example, I'm
trying to pass this in when running stateless from my deployment.yaml:
command:
["/bin/sh", "-c", "/opt/nifi/nifi-current/bin/nifi-stateless.sh -c -p
\"nifi.stateless.security.keystorePasswd=${KEYSTORE_PASSWORD}\""]
The expected behavior would be that the nifi.stateless.security.keystorePasswd
property in stateless.properties would be updated.
Documentation referenced here
([https://github.com/apache/nifi/blob/main/nifi-stateless/nifi-stateless-assembly/README.md#passing-parameters)]
Chatted briefly w/ Joe Gresock to verify and requested a ticket be submitted.
Summary: Stateless NiFi does not support ssl properties passed in from
environment variables (was: Stateless NiFi does not support ssl properties
passed in.)
> Stateless NiFi does not support ssl properties passed in from environment
> variables
> ---
>
> Key: NIFI-11650
> URL: https://issues.apache.org/jira/browse/NIFI-11650
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Stephanie Ambrose
>Priority: Major
>
> When deploying stateless NiFi in an environment like k8s, we have the
> stateless.properties file as a configMap. We need to pass in the keystore
> password, retrieved by the k8s secret (or environment variable). According to
> the stateless documentation, this should be supported; however, it looks like
> the ssl properties specifically don't allow for override. For example, I'm
> trying to pass this in when running stateless from my deployment.yaml:
> command:
> ["/bin/sh", "-c", "/opt/nifi/nifi-current/bin/nifi-stateless.sh -c -p
> \"nifi.stateless.security.keystorePasswd=${KEYSTORE_PASSWORD}\""]
> Similarly to how the env-flow-config.properties file can reference
> environment variables with env\{VAR_NAME}, the stateless.properties file
> should be able to do the same.
> The expected behavior would be that the
> nifi.stateless.security.keystorePasswd property in stateless.properties would
> be updated by environment variables.
>
> Documentation referenced here
> ([https://github.com/apache/nifi/blob/main/nifi-stateless/nifi-stateless-assembly/README.md#passing-parameters)]
>
>
> Chatted briefly w/ Joe Gresock to verify and requested a ticket be submitted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-11650) Stateless NiFi does not support ssl properties passed in.
Stephanie Ambrose created NIFI-11650:
Summary: Stateless NiFi does not support ssl properties passed in.
Key: NIFI-11650
URL: https://issues.apache.org/jira/browse/NIFI-11650
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 1.20.0
Reporter: Stephanie Ambrose
When deploying stateless NiFi in an environment like k8s, we have the
stateless.properties file as a configMap. We need to pass in the keystore
password, retrieved by the k8s secret (or environment variable). According to
the stateless documentation, this should be supported; however, it looks like
the ssl properties specifically don't allow for override. For example, I'm
trying to pass this in when running stateless from my deployment.yaml:
command:
["/bin/sh", "-c", "/opt/nifi/nifi-current/bin/nifi-stateless.sh -c -p
\"nifi.stateless.security.keystorePasswd=${KEYSTORE_PASSWORD}\""]
The expected behavior would be that the nifi.stateless.security.keystorePasswd
property in stateless.properties would be updated.
Documentation referenced here
([https://github.com/apache/nifi/blob/main/nifi-stateless/nifi-stateless-assembly/README.md#passing-parameters)]
Chatted briefly w/ Joe Gresock to verify and requested a ticket be submitted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-11297) Prometheus Reporting Task throws a NullPointerException for Stateless NiFi
[ https://issues.apache.org/jira/browse/NIFI-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose resolved NIFI-11297. -- Assignee: Stephanie Ambrose Resolution: Not A Problem [https://github.com/apache/nifi/tree/main/nifi-stateless/nifi-stateless-assembly#reporting-tasks] ^ This could use some verbiage on required properties for specific reporting tasks The nifi.stateless.reporting.task.prometheus.frequency=10 sec ...property sets the getSchedulingPeriod method on the ReportingTaskNode class, which throws a NullPointerException without it. > Prometheus Reporting Task throws a NullPointerException for Stateless NiFi > -- > > Key: NIFI-11297 > URL: https://issues.apache.org/jira/browse/NIFI-11297 > Project: Apache NiFi > Issue Type: Bug >Reporter: Stephanie Ambrose >Assignee: Stephanie Ambrose >Priority: Critical > > When configuring the Prometheus reporting task for Stateless NiFi, a > NullPointerException is thown and it does not work. > Here are my config properties: > nifi.stateless.reporting.task.prometheus.name=Prometheus > nifi.stateless.reporting.task.prometheus.type=PrometheusReportingTask > nifi.stateless.reporting.task.prometheus.bundle=org.apache.nifi:nifi-prometheus-nar:1.12.1 > nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-metrics-endpoint-port=9100 > nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-instance-id=statelessNiFi1 > nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-metrics-strategy=All > Components > nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-metrics-send-jvm=false > nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-client-auth=No > Authentication > And here is the error that is thrown to my Prometheus server: > HTTP ERROR 500 java.lang.NullPointerException > URI: /metrics/ > STATUS: 500 > MESSAGE: java.lang.NullPointerException > SERVLET: > org.apache.nifi.reporting.prometheus.PrometheusServer$MetricsServlet-6d1c2fd6 > CAUSED BY:java.lang.NullPointerException > Caused by: > java.lang.NullPointerException > at > org.apache.nifi.reporting.prometheus.PrometheusReportingTask.lambda$onScheduled$0(PrometheusReportingTask.java:133) > at > org.apache.nifi.reporting.prometheus.PrometheusServer$MetricsServlet.doGet(PrometheusServer.java:69) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:554) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at org.eclipse.jetty.server.Server.handle(Server.java:516) > at > org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) > at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) > at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) > at java.base/java.lang.Thread.run(Thread.java:829) > > We intend to use the Prometheus reporting task in Stateless NiFi for HPA and > pod health, so for us this would be a critical bug fix. > > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11297) Prometheus Reporting Task throws a NullPointerException for Stateless NiFi
Stephanie Ambrose created NIFI-11297: Summary: Prometheus Reporting Task throws a NullPointerException for Stateless NiFi Key: NIFI-11297 URL: https://issues.apache.org/jira/browse/NIFI-11297 Project: Apache NiFi Issue Type: Bug Reporter: Stephanie Ambrose When configuring the Prometheus reporting task for Stateless NiFi, a NullPointerException is thown and it does not work. Here are my config properties: nifi.stateless.reporting.task.prometheus.name=Prometheus nifi.stateless.reporting.task.prometheus.type=PrometheusReportingTask nifi.stateless.reporting.task.prometheus.bundle=org.apache.nifi:nifi-prometheus-nar:1.12.1 nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-metrics-endpoint-port=9100 nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-instance-id=statelessNiFi1 nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-metrics-strategy=All Components nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-metrics-send-jvm=false nifi.stateless.reporting.task.prometheus.properties.prometheus-reporting-task-client-auth=No Authentication And here is the error that is thrown to my Prometheus server: HTTP ERROR 500 java.lang.NullPointerException URI:/metrics/ STATUS: 500 MESSAGE:java.lang.NullPointerException SERVLET: org.apache.nifi.reporting.prometheus.PrometheusServer$MetricsServlet-6d1c2fd6 CAUSED BY: java.lang.NullPointerException Caused by: java.lang.NullPointerException at org.apache.nifi.reporting.prometheus.PrometheusReportingTask.lambda$onScheduled$0(PrometheusReportingTask.java:133) at org.apache.nifi.reporting.prometheus.PrometheusServer$MetricsServlet.doGet(PrometheusServer.java:69) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:554) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.server.Server.handle(Server.java:516) at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) at java.base/java.lang.Thread.run(Thread.java:829) We intend to use the Prometheus reporting task in Stateless NiFi for HPA and pod health, so for us this would be a critical bug fix. Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11239) Stateless-Nifi not logging performance counters
[ https://issues.apache.org/jira/browse/NIFI-11239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose updated NIFI-11239: - Status: Patch Available (was: In Progress) > Stateless-Nifi not logging performance counters > --- > > Key: NIFI-11239 > URL: https://issues.apache.org/jira/browse/NIFI-11239 > Project: Apache NiFi > Issue Type: Bug > Components: NiFi Stateless >Affects Versions: 1.20.0 >Reporter: Dye357 >Assignee: Stephanie Ambrose >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Description: It appears at some point work was done to log the performance > counters for flows running in stateless-nifi. I've tested on 1.19.1 and > 1.20.0 and found that the functionality is broken, the headers for the > logging print however no component counts displayed: > > - > 2023-03-02 10:14:03,503 INFO [Background Tasks] > o.a.n.c.reporting.LogComponentStatuses Counters: > -- > | Counter Context | Counter Name > | Counter Value | Increase/sec | > -- > -- > > Further investigating the code reveals that the LogComponentStatues class is > being passed a FlowCounterContext which is effectively empty. It looks like > StatelessRepositoryContext.java is not overriding the requisite abstract > method to inject the peromanceCounters into the FlowCounterContext. > > Acceptance Criteria: The flow performance counters are correctly logged when > logCounters() is invokes in LogComponentStatuses.java. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11231) Stateless Nifi Supports Sensitive Parameter Context Variables
[ https://issues.apache.org/jira/browse/NIFI-11231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose updated NIFI-11231: - Summary: Stateless Nifi Supports Sensitive Parameter Context Variables (was: Stateless Nifi Supports Secure Parameter Context Variables) > Stateless Nifi Supports Sensitive Parameter Context Variables > - > > Key: NIFI-11231 > URL: https://issues.apache.org/jira/browse/NIFI-11231 > Project: Apache NiFi > Issue Type: Bug > Components: NiFi Stateless >Affects Versions: 1.20.0 >Reporter: Dye357 >Assignee: Stephanie Ambrose >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently Secure Parameter Context Variables are not supported in Stateless > Nifi - this is due to StatelessFlowManager being stubbed to throw a "Not > Implemented" exception when providing a process group configured with a > secure Parameter Context variable. > Desired functionality: Secure Parameter Context Variables can be used with > stateless Nifi. If a process group contains a Secure Parameter Context > Variable the context is used to hydrate all parameters within the provided > flow including any marked sensitive. > Acceptance Criteria: Process Groups using secure parameters can be used in > stateless Nifi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11231) Stateless Nifi Supports Sensitive Parameter Context Variables
[ https://issues.apache.org/jira/browse/NIFI-11231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose updated NIFI-11231: - Description: Currently Sensitive Parameter Context Variables are not supported in Stateless Nifi - this is due to StatelessFlowManager being stubbed to throw a "Not Implemented" exception when providing a process group configured with a secure Parameter Context variable. Desired functionality: Sensitive Parameter Context Variables can be used with stateless Nifi. If a process group contains a Sensitive Parameter Context Variable the context is used to hydrate all parameters within the provided flow including any marked sensitive. Acceptance Criteria: Process Groups using secure parameters can be used in stateless Nifi. was: Currently Secure Parameter Context Variables are not supported in Stateless Nifi - this is due to StatelessFlowManager being stubbed to throw a "Not Implemented" exception when providing a process group configured with a secure Parameter Context variable. Desired functionality: Secure Parameter Context Variables can be used with stateless Nifi. If a process group contains a Secure Parameter Context Variable the context is used to hydrate all parameters within the provided flow including any marked sensitive. Acceptance Criteria: Process Groups using secure parameters can be used in stateless Nifi. > Stateless Nifi Supports Sensitive Parameter Context Variables > - > > Key: NIFI-11231 > URL: https://issues.apache.org/jira/browse/NIFI-11231 > Project: Apache NiFi > Issue Type: Bug > Components: NiFi Stateless >Affects Versions: 1.20.0 >Reporter: Dye357 >Assignee: Stephanie Ambrose >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently Sensitive Parameter Context Variables are not supported in > Stateless Nifi - this is due to StatelessFlowManager being stubbed to throw a > "Not Implemented" exception when providing a process group configured with a > secure Parameter Context variable. > Desired functionality: Sensitive Parameter Context Variables can be used with > stateless Nifi. If a process group contains a Sensitive Parameter Context > Variable the context is used to hydrate all parameters within the provided > flow including any marked sensitive. > Acceptance Criteria: Process Groups using secure parameters can be used in > stateless Nifi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11231) Stateless Nifi Supports Secure Parameter Context Variables
[ https://issues.apache.org/jira/browse/NIFI-11231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephanie Ambrose updated NIFI-11231: - Status: Patch Available (was: In Progress) > Stateless Nifi Supports Secure Parameter Context Variables > -- > > Key: NIFI-11231 > URL: https://issues.apache.org/jira/browse/NIFI-11231 > Project: Apache NiFi > Issue Type: Bug > Components: NiFi Stateless >Affects Versions: 1.20.0 >Reporter: Dye357 >Assignee: Stephanie Ambrose >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently Secure Parameter Context Variables are not supported in Stateless > Nifi - this is due to StatelessFlowManager being stubbed to throw a "Not > Implemented" exception when providing a process group configured with a > secure Parameter Context variable. > Desired functionality: Secure Parameter Context Variables can be used with > stateless Nifi. If a process group contains a Secure Parameter Context > Variable the context is used to hydrate all parameters within the provided > flow including any marked sensitive. > Acceptance Criteria: Process Groups using secure parameters can be used in > stateless Nifi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
