关于QC的自动踢人功能的问题

aishifu1

症状：
    WAIT_BEFORE_DISCONNECT设置为30，昨天晚上有同事登录的，今天早上链接还在，没有断开。貌似设置貌似不生效。

详情分析：
    WAIT_BEFORE_DISCONNECT参数描述为：Quality Center 客户端与 Quality Center 服务器断开连接之前可以保持非活动状态的时间间隔 (分钟)。断开该客户端的连接后，许可证可由另一 Quality Center 用户使用。默认情况下，该值设置为 600 分钟。如果将该值设置为 -1，则无论客户端处于非活动状态多长时间，Quality Center 都不会断开连接。

截图：
     图片1：今天早上的用户连接截图
     图片2：参数设置截图

联系方式:
    1、在线等
     2、zhangweijian399@foxmail.com

[ 本帖最后由 aishifu1 于 2009-10-28 10:13 编辑 ]

kuangquanshui

没太明白

aishifu1

完结这个帖子，这个是偶然现象，重启MQC后问题消失。

aishifu1

根据上面的解释，查看了下数据库qcsiteadmin_db
下面有张表LOGIN_SESSIONS下的LS_LAST_TOUCH_TIME列。
时间为：2009-10-28 9:20:27
可见踢人程序没有清理这条记录。难道是踢人程序出错了，没启动？

aishifu1

找到段解释，大致意思是。
客户端会5分钟ping一次服务端，假如非活动状态超过了WAIT_BEFORE_DISCONNECT的时间，客户端就不ping了。服务端10-15分钟会清理一次用户。
假如客户端在手工执行或自动化执行案例时，客户端不理会WAIT_BEFORE_DISCONNECT。

但是不能解释我的问题。
Problem ID: 44967 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. Mercury does not recommend to set this time to less than 60 minutes. The default value is set to 600 minutes.

aishifu1

求达人