[
https://issues.apache.org/jira/browse/NIFI-14599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuanhao Zhu updated NIFI-14599:
-------------------------------
Description:
We recently upgrade to nifi 2.4.0 from 1.x and have noticed something weird
about the parameter provider in 2.x. From time to time, for some reason, the
parameter provider will complain about invalid revision given when fetching for
parameters with nifi-cli. Specifically we are using
AzureKeyvaultParameterProvider. And once this happens, the only way to get rid
of it is the re-creation of the parameter provider.
See the screenshot
!https://community.cloudera.com/t5/image/serverpage/image-id/45570i701517E88FD12C48/image-size/large/is-moderation-mode/true?v=v2&px=999!
And it looks like the revision manager was messed up that every time the new
revision is always one version below, we are running nifi in a standalone mode
and consecutively triggering of the parameter fetch will constantly get the
invalid revision(each time the revision is up by 1) until the parameter
provider is recreated, even restarting nifi won't help. I'm also quite sure
there is only one person sending request to fetch for parameter and attempt to
change the parameter provider at the same time so no concurrent operation.
And once this problem happens, fetching parameters from UI also does not work,
it would just fail silently and the value of the secrets remains unchanged.
Also FYI, this never happened in 1.x
Another FYI, if we restart the nifi container, it does not go away, and the
revision number in the complaint will start over from 0
Steps to reproduce:
# Add secrets for multiple groups from the source for the same parameter
provider. e.g. add one secret where group-name set to a and one secret where
group-name set to b in Azure keyvault.
# In Nifi, trigger the parameter provider to fetch parameter
Now you should see that the parameter provider failed to be updated in the logs
I think the exact problem is that the update for parameter contexts related to
a parameter provider is always based on the revision given in the request,
after the first parameter context update, the other parameter context update
will still try to make the change based on the outdated revision given in the
request
was:
We recently upgrade to nifi 2.4.0 from 1.x and have noticed something weird
about the parameter provider in 2.x. From time to time, for some reason, the
parameter provider will complain about invalid revision given when fetching for
parameters with nifi-cli. Specifically we are using
AzureKeyvaultParameterProvider. And once this happens, the only way to get rid
of it is the re-creation of the parameter provider.
See the screenshot
!https://community.cloudera.com/t5/image/serverpage/image-id/45570i701517E88FD12C48/image-size/large/is-moderation-mode/true?v=v2&px=999!
And it looks like the revision manager was messed up that every time the new
revision is always one version below, we are running nifi in a standalone mode
and consecutively triggering of the parameter fetch will constantly get the
invalid revision(each time the revision is up by 1) until the parameter
provider is recreated, even restarting nifi won't help. I'm also quite sure
there is only one person sending request to fetch for parameter and attempt to
change the parameter provider at the same time so no concurrent operation.
And once this problem happens, fetching parameters from UI also does not work,
it would just fail silently and the value of the secrets remains unchanged.
Also FYI, this never happened in 1.x
Another FYI, if we restart the nifi container, it does not go away, and the
revision number in the complaint will start over from 0
Steps to reproduce:
# Add secrets for multiple groups from the source for the same parameter
provider. e.g. add one secret where group-name set to a and one secret where
group-name set to b in Azure keyvault.
# In Nifi, trigger the parameter provider to fetch parameter
Now you should see that the parameter provider failed to be updated in the logs
> Parameter provider invalid revision issue
> -----------------------------------------
>
> Key: NIFI-14599
> URL: https://issues.apache.org/jira/browse/NIFI-14599
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 2.1.0, 2.2.0, 2.3.0, 2.4.0
> Reporter: Yuanhao Zhu
> Priority: Major
> Attachments: image-2025-06-02-09-24-01-141.png
>
>
> We recently upgrade to nifi 2.4.0 from 1.x and have noticed something weird
> about the parameter provider in 2.x. From time to time, for some reason, the
> parameter provider will complain about invalid revision given when fetching
> for parameters with nifi-cli. Specifically we are using
> AzureKeyvaultParameterProvider. And once this happens, the only way to get
> rid of it is the re-creation of the parameter provider.
> See the screenshot
> !https://community.cloudera.com/t5/image/serverpage/image-id/45570i701517E88FD12C48/image-size/large/is-moderation-mode/true?v=v2&px=999!
> And it looks like the revision manager was messed up that every time the new
> revision is always one version below, we are running nifi in a standalone
> mode and consecutively triggering of the parameter fetch will constantly get
> the invalid revision(each time the revision is up by 1) until the parameter
> provider is recreated, even restarting nifi won't help. I'm also quite sure
> there is only one person sending request to fetch for parameter and attempt
> to change the parameter provider at the same time so no concurrent operation.
>
> And once this problem happens, fetching parameters from UI also does not
> work, it would just fail silently and the value of the secrets remains
> unchanged.
>
> Also FYI, this never happened in 1.x
>
> Another FYI, if we restart the nifi container, it does not go away, and the
> revision number in the complaint will start over from 0
>
> Steps to reproduce:
> # Add secrets for multiple groups from the source for the same parameter
> provider. e.g. add one secret where group-name set to a and one secret where
> group-name set to b in Azure keyvault.
> # In Nifi, trigger the parameter provider to fetch parameter
> Now you should see that the parameter provider failed to be updated in the
> logs
>
> I think the exact problem is that the update for parameter contexts related
> to a parameter provider is always based on the revision given in the request,
> after the first parameter context update, the other parameter context update
> will still try to make the change based on the outdated revision given in the
> request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
