Qlik Sense - Randomly, some streams or applications are not available in the Hub
From time to time, when a user accesses the Qlik Sense Hub, they do not retrieve the Streams they should have access to after recent changes in the security rules setup. You may even see different result depending on which rim node you are connected to.
This usually happens in multi node environments deployed in cloud premises such as Microsoft Azure.
You can check if you are impacted by a problem with your database listeners via the video below or using the pgadmin instructions here.
A service restart on the affected node(s) will recover the connectivity and issue should be resolved.
There is a setting called "Keep Alive" that will have the effect of sending a TCP keepalive packet at regular intervals. It is by default turned off (value 0), but setting the value to 1 (keepalive sent every second) makes the system recover when the connection has been lost.
To configure the "Keep Alive" you will need to apply the following on each node (including Central node)
Open QlikSenseUtil. By default, this will be installed under C:\Program Files\Qlik\Sense\Repository\Util\QlikSenseUtil\QlikSenseUtil.exe
Open theConnection String EditorandReadthe current configuration, decrypting the current data.
At the end of the Connection String for "QSR" and "QSMQ", add the following key KeepAlive=30;
<add name="QSR" connectionString="User ID=qliksenserepository;Host='<host>';Port='4432';Database=QSR;Pooling=true;Min Pool Size=0;Max Pool Size=90;Connection Lifetime=3600;Unicode=true;Password='<pwd>';Keep Alive=30;" providerName="Devart.Data.PostgreSql" />
<add name="QSMQ" connectionString="User ID=qliksenserepository;Host='<host>';Port='4432';Database=QSMQ;Pooling=true;Min Pool Size=0;Max Pool Size=90;Connection Lifetime=3600;Unicode=true;Password='<pwd>';Keep Alive=30;" providerName="Devart.Data.PostgreSql" />
<add name="postgres" connectionString="User ID=postgres;Host=localhost;Port=4432;Database=postgres;Pooling=true;Min Pool Size=0;Max Pool Size=90;Connection Lifetime=3600;Unicode=true;" providerName="Devart.Data.PostgreSql" />
Hit Save Value in config file encrypted, committing any changes.
Finally restart the Qlik Sense Repository Service and Qlik Sense Dispatcher on the node.
When upgrading Qlik Sense to a newer release, check if the setting is still present, if not please re-implement the steps from a-e
I. There is also a possible workaround to clear all the QRS cache entitities which has worked in some scenarios with this issue.
II. Also, we can identify this drop in connection by initiating a ping processes on each of the rim nodes towards the central node. In a command shell on the two rim nodes run the following command and leave it running for at least 24 hours then compare the two resulting files:
Option 1:Using cmd (Ok but will not identify the time)
ping -t <central node> > ping_log.txt
Option 2:Using PowerShell. This will use Get-Date to generate a timestamp for each ping which helps with cross-referencing environmental events.
This is useful in environment where either QoS is implemented, ping is blocked, or has other environmental restrictions that could affect TCP connections only. In this scenario, Ping (which uses ICMP protocol) would not indicate latency which can mislead to concluding TCP protocol is not observing latency as well. To rule this out use psping.
Qlik Sense Enterprise on Windows relies on database listeners to notify nodes when changes have occurred, it is possible for these connections to be silently closed, which can result in a variety of strange behavior such as newly published apps not being visible on all nodes, or newly created streams or load balancing rules appearing to not take effect until the node is restarted.