Server communication lost -- closing document --- event ID 105

[Anonymous]

What happens is that the clients get the notification:

Server communication lost -- closing document.

In the Eventlog of the server some Event ID's are visible but we have no clue what these eventID's mean ...
We did try to find some documentation about these ID's but did not find a clue.

Maybe someone can help us out on what these event ID's mean??

We have EventID 105 -- think this has to do with memory problems??
And we have EventID 108 and sometimes EventID 107

Thx in advance

Anita

[#2]

Hi,

we do have this Event 105 too in our event viewer. The QEMC indicates an connection failure to the Qlikview Server. in the Service Controlpanel windows indicated the service is still running and the QVS gives no error to the eventlog, just Event 105 from time to time in the Informatioon Section of the event log. The server logfiles doesnt give a hint to a problem either.

System Envirement is:

Windows Server 2008

QV Server 9 SP2 (had the problem in SP1 also)

Serviceuser ist Domain User with lokal admin rights.

Any glue what happend?

[vgutkovsky]

Anita,

EventID 105 means that the network has become unavailable. Boris, I suspect that is why QVS doesn't give any errors. It might be that a patch cable along the way has a contact problem, or the switch port is lossy, or any of the other problems that could lead to packets being lost. Another possibility is that the server is overloaded with client requests.

Unfortunately, there's no easy fix for this. You just need to have your network checked out most likely.

[#4]

Hi Vlad,

Thx for you hint about EventID 105.

All services run on the same machine. Most work is done on the server itself, so loosing packages could not be the reason for this behaviour. I never heard of lost packages in local loopback..

Maybe this EventId 105 has nothing to do with the server connection problem. We will observethis issue and try to figure out the circumstances.

[vgutkovsky]

Have you checked the QVS logs?

[#6]

Yes we did. Nothing dramatic in there. Some sessions expired and some infos about reloading of qvw files. There was realy no hint why the QVS windows service was still running and the QVEMC, as well as the Access Point.. etc lost connection to the QVS.

A restart of the service solved the problem, but from my point of view the service should have been stoped if the server stopped working. The last iregular I rember was, that we triggerd EDX from a commandline tool witch retured no sucess in the result XML file but "Other Error". I think It could have happend same time the server stoped working.

[vgutkovsky]

When the crash happened, what were your VM levels like? There is a bug in SR2 that causes a virtual memory leak which, in turn, causes the server to crash and drop connections eventually...

[#8]

Hi Vlad,

I dont know exactly what my VM level was like... I will observe this. Along we are trying to monitoring the connectivity of the server with some monitoring tools. Dont know exactly how to do that, but I gues that we have to triggering the command center as as website....

[#9]

Hi folks,

I found the solution to this problem in another forum and I like to share with you.

The behaviour is determinated by the settings in the document. As of current, there are three modes:

1. Client disconnects on document reload (above behaviour)
2. Client initiates refresh automatically
3. Server performs refresh

Option 2 has some suboptions such as "Show messagebox".

To find these options, open the document, go to Settings -> Document Properties -> Server (tab).

After playing with those options I finally can have my document open 10 minutes (600 seconds) and after click it, it still works without any message.

I just changed and played with thouse values and that's all.

I hope this can help someone else.

Regards,

Diego.