Qlikview Access Point lost connection to server and not displaying images

[J_Mulholland]

We have migrated out Qlikveiw 12.60 environment over to new servers.  During testing we noticed we get intermittent "lost connection to server" "reconnecting" message when accessing docs.   When navigating the doc this message will pop up from time to time but users are eventually able to continue through or are brought back to the first page of the doc.  We also have buttons and images not displaying or appearing broken.  We have applied the recommended fixes per the below article but no improvement.

 https://community.qlik.com/t5/Knowledge/Lost-connection-to-server-Reconnecting-or-Session-Lost-when/...

We are using 2 load balanced IIS servers and 2 Qlikview app servers.  Would appreciate any thoughts.

[Ray_Strother]

Hello ,

Please confirm and try the following:

1. Confirm the Qlikview IIS Apppool is running as the Qlikview Service account

2. Try to access the AccessPoint while logged onto the QVS server as 

3. Can you access the servers outside the load balancers

[J_Mulholland]

thanks Ray.  Yes the Qlik service account is running the apppool and I can access the access point from the server and outside the load balancers.

[Chip_Matejowsky]

Hi @J_Mulholland,

Users are receiving the Reconnecting message only when they are initially attempting to open the QVW? Or can they open the QVW and then after a period of time receive the Reconnecting message?

Have you reviewed the QlikView Server Events log for any errors or warnings regarding this.  Really helpful if you know the timestamp and UserID to help in narrowing down scope of reviewing the QVS Events log.

You stated that you followed all items in article https://community.qlik.com/t5/Knowledge/Lost-connection-to-server-Reconnecting-or-Session-Lost-when/...  Can you share what the configurations are for the SocketTimeOutInSeconds and executionTimeout values for IIS. 
 

Suggest that you also open a case with Qlik Support.

Best Regards

[J_Mulholland]

thanks Chip.

yes, users can open the QVW but then receive the "reconnecting" message.  

we did look at the logs.  there are only a couple users testing right now.  we see warnings and notices like the below.

Notice CAL usage: Using CAL of type "Named User" for user "xx". Named user cals in use: 1
Notice CAL usage: Using CAL of type "Named User" for user "xx". Named user cals in use: 1
Warning System: MetaService - HasAccess: Empty User has found. Access deny into document  xx
Warning System: MetaService - HasAccess: Empty User has found. Access deny into document  xx
Notice CAL usage: Named CAL session for user "xx" stopped 0

Notice CAL usage: Named CAL session for user "xx" stopped 0

I'm assuming the cals in use and session stopped are when the reconnects happen.  I wonder why the same user always gets 2 cals?

we set the SocketTimeOutInSeconds to 600 and the execution timeout to 20:00

[Chip_Matejowsky · Accepted solution]

@J_Mulholland,

Thanks for the response.  Seems you may have a low or medium verbosity level configured for the QVS Events log.  And thinking about this issue more, I believe the QVS Sessions log would have better information actually.

As users can initially open a QVW from the AccessPoint and then receive the Reconnecting... message, I believe the issue may reside with your load balancer.  Have a look at the requirements in the Help entry QVS Load Balancing Options > Load Balancing the Web Server, which stipulates the following requirements on the load balancer:

• Support for session persistence / sticky sessions: This ensures a user's session persists on the same node within the cluster, usually by using a cookie.
• Availability: The load balancer checks the availability of the AccessPoint web server and the QlikView servers.
• Some form of load balancing algorithm to determine which server is the least loaded.

Typically the scenario you're describing is due to session persistence / sticky sessions needing to be enabled on the load balancer.  

Hope this helps!

 

[jdmulholland · Accepted solution]

thanks Chip.  yes it was the "persistent cookie" setting on the load balancer.