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 results depending on which rim node you are connected to.
This usually happens in multi node environments deployed in cloud premises such as Microsoft Azure.
If you are looking for information on Streams not being visible after an Upgarde to Qlik Sense May 2022, see Stream are not visible in Qlik Sense May 2022.
You can check if you are impacted by a problem with your database listeners via the video below or using the pgadmin instructions here.
Environment
- Qlik Sense Enterprise on Windows (any version)
Resolution
Click here for Video Transcript
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 the Connection String Editor and Read the current configuration, decrypting the current data.
- At the end of the Connection String for "QSR" and "QSMQ", add the following key KeepAlive=30;
<connectionStrings>
<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" />
</connectionStrings>
- 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 above.
Workaround(s):
- There is also a possible workaround to clear all the QRS cache entitities which has worked in some scenarios with this issue.
DELETE /qrs/internal/management/cache/
QRS API: Delete management cache
- 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.
ping.exe -t <DestinationFileServer_IP> | Foreach{"{0} - {1}" -f (Get-Date),$_} > ping_DestinationFileServerName.txt
Option 3: Using psping on tcp port 4432.
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.
See Test latency to Qlik Server on a specific port
Cause
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.
Related Content:
