Qlik Community

Deployment & Management

Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.

Announcements
Customer & Partners, DEC. 9, 11 AM ET: Qlik Product & Strategy Roadmap Session: Data Analytics REGISTER NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
mjperreault
Creator
Creator

Security Rules Taking a while to come into effect on Rim Node

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

Labels (5)
1 Solution

Accepted Solutions
gaidamichal
Partner
Partner

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).

View solution in original post

6 Replies
gaidamichal
Partner
Partner

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):

https://help.qlik.com/en-US/sense/June2019/Subsystems/PlanningQlikSenseDeployments/Content/Sense_Dep...

Regardless we found that more complex rules sometimes "lag". You can troubleshoot and force the security cache to reload and check if that helps.

https://support.qlik.com/articles/000089808

gaidamichal
Partner
Partner

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).

View solution in original post

mjperreault
Creator
Creator
Author

@gaidamichal 

 

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

jbouslimi
Contributor III
Contributor III

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

vegard_bakke
Partner
Partner

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.

Ken_T
Creator II
Creator II

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?