Session log session duration inaccurate values. Possible bug?

[anthony2]

There are some strange values for Session Duration in my session logs that I can't explain. I'm seeing session duration's of 15, 44, 59, and 94 hours for  sessions. In QMS I have the time out set to 30 minutes. If I calculate the duration of the Session Start column to the Timestamp column it produces the duration time column value. So, session duration is being calculated correctly off those columns but the number of hours is way too high.

How can this be explained?

I have session logging enabled in QMC and split files to Monthly.

QVS: 11.20.12577.0

Sample of sessions with abnormally high Session Duration. Format HH:MM:SS

Timestamp	Exit Reason	Session Start	Session Duration	CPU spent	Bytes Recvd	Bytes Sent	Calls	Selections
4/3/2019 9:05	Socket closed by client	4/1/2019 12:09	44:56:36	0.001	2571929	3805520	160457	0
4/8/2019 7:49	Socket closed by client	4/5/2019 19:52	59:56:32	0.001	3432244	5205665	214268	2
4/15/2019 9:31	Session expired after idle time	4/11/2019 10:47	94:44:40	0.002	5449569	7402497	340199	16
4/16/2019 9:33	Killed because Named User Cal was needed from another client	4/15/2019 16:25	17:08:14	0	984440	1465824	61335	4
4/18/2019 7:16	Socket closed by client	4/16/2019 16:38	38:38:23	0	2207439	2950432	137783	2
4/19/2019 14:03	Socket closed by client	4/19/2019 9:20	4:43:27	0.001	282059	705664	17439	2
4/22/2019 1:00	Socket closed by client	4/21/2019 9:36	15:23:59	0.001	908490	1733632	56592	2

[Brett_Bleess]

The most likely explanation is a bug in the release you are running, it is approaching 5 years old at this point, many many changes since then in the newer 11.20 tracks, so we would need to know whether the issue is present in one of the latest 11.20 SR's in order to look into this further.

That being said, there is one other plausible explanation, but will likely be hard to prove.  I know there are hardware devices out there that you can get that will keep you from being logged out or lock your workstation etc., folks get these to avoid having to login all the time when things timeout, the one thing that goes against that in your case is the one exit reason that does end up saying session expired, in that case, the hardware device would have had to have been removed in order for things to actually expire...  

Thus, my best guess here is it is most likely a bug in the release, I did check Release Notes for SR13, as release notes after this changed, and I could not find anything that fits your scenario, so either there is an environmental component etc., or nobody ever reported anything.  About the best I can offer, hopefully helps.  

I would highly recommend you upgrade to at least the latest SR for 11.20 as well, that will be SR19 as there are a couple of serious security vulnerabilities that have been fixed in that release, so would be sure to review that.  Support for 11.20 is due to end March of 2020 as well, so you may want to consider moving to one of the supported 12.xx tracks as well potentially.  

Oh, I did run a quick test in 12.30 SR3, and everything was reporting as I expected, I did close my Ajax session using the Close link, but otherwise I would expect the session to timeout after the Maximum Inactive Session Timeout setting in the QVS Performance tab settings in QMC.  In your case, it does seem the users pretty much got into the app, made some selections and then left things sit, so why the session durations ended up being as long as they are is an interesting question, but again, not much we can do on a 5 year old release at this point, so first step would be the update to a more current release, and if you can replicate there, then we could potentially look into things, but I would suspect something in the networking being the culprit at that point most likely, but the one way to try to ensure things would be to have the users click the Close link in the upper right corner of the app before they stop, that should send the stop to the QVS immediately for the Ajax clients and record things properly in the Session logs for you, about the best workaround I have.  I do not recall if the Document Extension for closing things on browser close will work back then or not, but here is article link to that as well:  https://support.qlik.com/articles/000003498

Regards,
Brett