Highlighted
Contributor.. Anton_Labachev Contributor..
Contributor..
310 views

<QC/ALM Support Tip> How does WAIT_BEFORE_DISCONNECT methodology work

Hello customers,

 

Here is some useful information about WAIT_BEFORE_DISCONNECT methodology

 

From client side:

Every client session is aware of this parameter value. Every 5 minutes, each client machine (the Webgate on the client machine) sends a PING to the server to notify that the client is alive. Part of the data that is being sent is the interval in milliseconds from the last action that this specific client did (action that is not PING). After WAIT_BEFORE_DISCONNET interval the Webgate of that client stops sending PING requests and the client session will display the message, "You have been disconnected by the server."

 

From server side:

Every 15 minutes a job called CInactiveTdSessionsCleanerJob is being executed on the QC server. The purpose of this job is to locate inactive sessions, clean their resources (license, locks, etc) and then clean the sessions themselves from the SESSIONS table.

 

In order to locate inactive sessions, the server runs an SQL query that finds all sessions where their last PING time is greater than 10 minutes. In other words, sessions that did not send PING request to the server in the last 10 minutes are considered as inactive. As you can see the server is NOT aware of the WAIT_BEFORE_DISCONNECT interval.

 

As a result, after the last valid ping between client and server, it could take up to a minimum of the minutes set in WAIT_BEFORE_DISCONNECT and a maximum of 10 minutes + 15 minutes + WAIT_BEFORE_DISCONNECT.

 

Another way to look at this:

The last action time in Site Administrator -> Connections tab holds the time of the last "real" request of the session. Where "real" means request that was made by the client, and not a ping. If a user is running a manual or automated test and they just leave the manual runner session open for manual runs, then their client will send pings to the server to stay alive but it will not update the last action time. Same thing for automated tests, if the test set takes 4 hours to finish then last action time will not get updated and the Quality Center administrator might think that WAIT_BEFORE_DISCONNECT is not working.

So, most likely the disconnects that are not working are because the users are running either manual (left window open in execution of manual test) or running automated tests, which is as designed.

 

NOTE:

This mechanism has been implemented for performance reasons. It is intended for users to use in order to disconnect any "forgotten" sessions and free up their resources. For example, if a user has connected to QC and then leaves for an extended period of time. Hewlett-Packard does not recommend to set this time to less than 60 minutes. The default value is set to 600 minutes.

 

**NOTE : This information is found in KB article :

http://support.openview.hp.com/selfsolve/document/KM198005 

Best regards,
Anton Labachev

HP Support
[If this post or any other post helps to resolve your issue or query, mark the thread as solved and give KUDOS to the author for their assistance. ]

If you haven’t tried it yet, come and join us in our entitled forums at http://h30499.www3.hp.com/t5/News/Support-Customer-Forums-now-available/m-p/5610181/message-uid/5610181#U5610181
Labels (1)
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.