Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
niceqlik
Partner - Contributor III
Partner - Contributor III

Intermittent "No Connection" Message In AccessPoint When Opening Document Via Ajax Client With Clustered QlikView Servers

Hi,

In a two-server cluster environment, sometimes users get an immidiate "no connection" error. When they refresh the page for several times then they finally succeed to open the document. Next time , they may or may not get the same error message. It totally depends on something unknown for now. All we could track is the web server logs generated at the same time this error occurs like:

.....

Create client: Mode=Authenticate, Host=sparrow:4747, ClientIP=10.250.20.80, MachineId=3fb55203-8987-4789-a3ff-d981174f1044, Slot=

Warning: m_Sock.Receive throws zero

.....

Is there any specific description of  "Warning: m_Sock.Receive throws zero" record in the generated Web Server logs.

Labels (2)
1 Solution

Accepted Solutions
niceqlik
Partner - Contributor III
Partner - Contributor III
Author

Hi,

We are also restarting all services every night but this doesn't help.

It is stated by QlikTech Support that this problem is resulted from a sync issue of "TicketData.pgo" file among cluster nodes. We have figured out that some of our Ticketdata.pgo files are not updating so we had to remove and have QVS's recreate them.

Many thanks for your comments,

Main Cause:

The TicketData.pgo file has become corrupted or out of sync, and a new version needs to be created.

There is nothing in the file that will cause a loss of anything by recreating new versions. You may also

notice in the QlikView Server Event logs that one server is creating a ticket and the other server is

attempting to consume it but the ticket cannot be found. The reason is the 'shared' TicketData.pgo file is

not updating correctly so the clustered servers will not have access to all tickets generated.

After following the below instructions, the problem has gone:

  1. Go to C:\Documents and Settings\All Users\Application Data\QlikTech\QlikViewServer (Server 2003) or C:\ProgramData\QlikTech\QlikViewServer (Server 2008) and confirm the TicketData.pgo file timestamp is updating with each user login.
  2. Go to the location of your QVServer Root Folder path as specified in the Management Console under System\Setup\QlikView Servers\QVS resource\Folders tab (default is C:\Documents and Settings\All Users\Application Data\QlikTech\Documents [Server 2003] or C:\ProgramData\QlikTech\Documents [Server 2008]). Verify the copy of TicketData.pgo is also updating with each user login.
  3. If either of the above TicketData.pgo files is not updating (check timestamp), stop the QVS services on each server running in the clustered configuration.
  4. Remove all copies of the TicketData.pgo files.
  5. Restart the QVS services.
  6. Verify all copies of TicketData.pgo are now updating as expected

View solution in original post

6 Replies
ashfaq_haseeb
Champion III
Champion III

Hi,

I haven't heard that before.

But I would suggest you to start you services by selecting Automatic (Delayed Start)

Regards

ASHFAQ

sudeepkm
Specialist III
Specialist III

You may have to check the services and restart them whenever the No connections message displays.

niceqlik
Partner - Contributor III
Partner - Contributor III
Author

Hi,

Thanks for your comments. But the error that I receive is "No connection" not "No Server" message.

I think that windows services have nothing to do with this problem. All services are up and running all the time.

sudeepkm
Specialist III
Specialist III

Few days before our clients reported seeing "No Connection" message like below on the Access Point. We restarted the QlikView Server and it worked. If it is happening consistently with your environment then I think you may have to check the QlikView server.

No Connections.png

Not applicable

HI,

this problem hast to do with the qlik view services on your server when you start them new everything should work fine again. We used to have the same problem and we solved it by restarting the services every night.

In our case the problem was theat our ram on the server was full.

regards,

MT

niceqlik
Partner - Contributor III
Partner - Contributor III
Author

Hi,

We are also restarting all services every night but this doesn't help.

It is stated by QlikTech Support that this problem is resulted from a sync issue of "TicketData.pgo" file among cluster nodes. We have figured out that some of our Ticketdata.pgo files are not updating so we had to remove and have QVS's recreate them.

Many thanks for your comments,

Main Cause:

The TicketData.pgo file has become corrupted or out of sync, and a new version needs to be created.

There is nothing in the file that will cause a loss of anything by recreating new versions. You may also

notice in the QlikView Server Event logs that one server is creating a ticket and the other server is

attempting to consume it but the ticket cannot be found. The reason is the 'shared' TicketData.pgo file is

not updating correctly so the clustered servers will not have access to all tickets generated.

After following the below instructions, the problem has gone:

  1. Go to C:\Documents and Settings\All Users\Application Data\QlikTech\QlikViewServer (Server 2003) or C:\ProgramData\QlikTech\QlikViewServer (Server 2008) and confirm the TicketData.pgo file timestamp is updating with each user login.
  2. Go to the location of your QVServer Root Folder path as specified in the Management Console under System\Setup\QlikView Servers\QVS resource\Folders tab (default is C:\Documents and Settings\All Users\Application Data\QlikTech\Documents [Server 2003] or C:\ProgramData\QlikTech\Documents [Server 2008]). Verify the copy of TicketData.pgo is also updating with each user login.
  3. If either of the above TicketData.pgo files is not updating (check timestamp), stop the QVS services on each server running in the clustered configuration.
  4. Remove all copies of the TicketData.pgo files.
  5. Restart the QVS services.
  6. Verify all copies of TicketData.pgo are now updating as expected