Multiple User/Document Sessions

[Anonymous]

Users are sometimes reporting a number of symptoms:

They repeatedly receive a "reconnecting to server" message.

Sheets they have created do not appear..

Their sheets do appear but the charts that should be there do not appear.

When we check QMC \ Status \ QVS Statistics

We can see that

Open Documents can show the document open many times

Active Users shows that user with multiple documents (though they only have one open)

So it appears that ta user can have multiple session against the same document.

We believe QVS is not handling User Session properly. Is creating a new session often for a user and not clearing up the old session.

We can also see an increasing memory use on the server, presumably caused by many orphaned sessions.

Has anybody encountered anything similar?

We have just moved to a new 2 server cluster, with IIS as the webserver

[Clever_Anjos]

There´s one option Under System / Performance

"Allow Multiple Copies of Documents", please check if it is marked

[Anonymous]

Clever

We have Allow Only One Copy of Document in Memory set to true, so there should not be multiple copies available to users.

[#4]

Hi Paul,

Did you find a sollution to your problem?

I am experiencing exactly the same issue.

Clustered environment also with 2 nodes and IIs.

I have 1 user with 50 sessions to the same document !!!.

[Anonymous]

George

For this issue we found that our load balancer sitting in front of the two nodes had a timeout of 30 minutes and the QlikView Web Server Settings Service had it's default timeout of 1 minute. We saw that new user sessions were being created every 1 minutes 15 seconds or so, which probably equated to the QVWSSS timeout plus a few seconds for the QlikView Server to poll or be informed of this plus a few seconds overhead creating a new session.

When we set the QVWSSS to also have a timeout of 30 minutes the multiple sessions stopped occurring.

The file you need to edit is located by default in QlikView 11 SR 2 at

C:\ProgramData\QlikTech\WebServer\config.xml

and the setting you need to change is

<QvsTimeout>1800</QvsTimeout>

This is our new 30 minute setting.

We continue to have other problems on our new servers relating to the Shared files and the end users Server objects. Often the server objects do not render for users, sometimes the whole application fails to render. Shared Server objects can spontaneaoulsy become set as no longer shared.

We are using the AJAX client exclusively and we do have some very heavy qvws with lots of server objects.

We have cleansed and purged the Shared files but to no avail.

Be aware of this as you continue with your clustered setup.

Can I ask, what is the setup of your storage that is being shred across the cluster. NAS device, separate Windows server acting as a file server, clustered storage across your two nodes ?

[#6]

HI Paul,

Thank you for your reply.

We also have an NLB setup in front of the 2 Qlikview access points (IIs).

We are using a seperate Windows server acting as a file server (not clustered).

Regards,

George

[#7]

Hi again Paul,

We are going to implement your suggestion in our environment. Will let you know how it goes. Our qlikview files are huge also and we use only AJAX clients. One thing i am seeing often in Windows Logs is ASP.NEt related errors.

We are also going to disable antivirus on Qlikview folders.

I am wondering if switching to Qlikview Web server instead of IIs will have a positive effect on these issues.

Also sometimes i see the same file open in both cluster nodes. Would it be possible that in these cases the shared files become corrupted as both nodes try to access them ? Have you tried to force the files to open ONLy in one node?

[Anonymous]

George

We have not encountered any ASP.NET errors.

We did try distributing documents to only one node but this didn't have any effect for us.

This week we have switched one of the nodes off, we are running on a single node. Things are much more stable now in terms of server sheets and objects rendering.

We continue to have occasional problems where following a document refresh a shared object may not be available until the owner has logged in.