Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi All,
We have a multi-node site in which we have one Central Node and two Rim Nodes. I have noticed some behavior recently where we will make an update to a Security Rule, for example granting a group access to a new stream, and while the Rule instantly goes into effect on the Central Node, it can take a while for it to go into effect on the Rim Nodes. I was wondering if anyone else has experienced this behavior and what the reasoning/resolution may be.
Thanks,
Mark
To clarify a bit more:
Qlik Sense Enteprise utilizes a cache concept for security rules. While applying new rules there is sometimes a "lag" between instant change and cache refresh on Rim nodes.
This was a known issue fixed in September 2018 (https://support.qlik.com/articles/000074467) but we had encountered it on April 2019 as well using an external Postgre SQL for configuration. Shutting down the environment and setting max_connections to 150 per node (higher than suggested 100 per node) mitigated the issue.
Security cache is refreshed after reset and can also be forced to refresh with QRS API (https://support.qlik.com/articles/000081585).
If you can make the rule "simpler" then it might help your issue also (we found that using custom properties in rules sometimes make it "lag" more than if the rule is set to use different parameters).
Hello,
Make sure you have upped the "max_connections" parameter in postgresql.conf accordingly to your nodes number (you might wanna give a bit higher number than in the link):
Regardless we found that more complex rules sometimes "lag". You can troubleshoot and force the security cache to reload and check if that helps.
To clarify a bit more:
Qlik Sense Enteprise utilizes a cache concept for security rules. While applying new rules there is sometimes a "lag" between instant change and cache refresh on Rim nodes.
This was a known issue fixed in September 2018 (https://support.qlik.com/articles/000074467) but we had encountered it on April 2019 as well using an external Postgre SQL for configuration. Shutting down the environment and setting max_connections to 150 per node (higher than suggested 100 per node) mitigated the issue.
Security cache is refreshed after reset and can also be forced to refresh with QRS API (https://support.qlik.com/articles/000081585).
If you can make the rule "simpler" then it might help your issue also (we found that using custom properties in rules sometimes make it "lag" more than if the rule is set to use different parameters).
Thanks for much for these responses, reading through the support articles now. The rule in question was using a custom property, so I will look into seeing if simplifying is possible. I love functionality that the CustomProperties provide but it seems to come at a cost.
Thanks again,
Mark
Hello,
I confirm you, sometimes, we encounter this is issue too ( QSE June 2020, 5 RIM nodes). This is an intermittent issue.
We restart the Repository services on the RIM nodes and this did help, but it is really an annoying issue.
Thanks,
James
I can also confirm that we experience this problem, with Qlik Sense June 2020 SR4. Two rim nodes.
Restarting the Repository service fixed our problem.
At least for now.
Security cache is refreshed after reset and can also be forced to refresh with QRS API (https://support.qlik.com/articles/000081585).
this article seems to be GONE..., is there a replacement link for this?