Qlik Community

QlikView Security & Governance

Discussion Board for collaboration on QlikView Security and Governance.

Highlighted
anthonyv
New Contributor

Session log session duration inaccurate values. Possible bug?

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

TimestampExit ReasonSession StartSession DurationCPU spentBytes RecvdBytes SentCallsSelections
4/3/2019 9:05Socket closed by client4/1/2019 12:0944:56:360.001257192938055201604570
4/8/2019 7:49Socket closed by client4/5/2019 19:5259:56:320.001343224452056652142682
4/15/2019 9:31Session expired after idle time4/11/2019 10:4794:44:400.0025449569740249734019916
4/16/2019 9:33Killed because Named User Cal was needed from another client4/15/2019 16:2517:08:1409844401465824613354
4/18/2019 7:16Socket closed by client4/16/2019 16:3838:38:230220743929504321377832
4/19/2019 14:03Socket closed by client4/19/2019 9:204:43:270.001282059705664174392
4/22/2019 1:00Socket closed by client4/21/2019 9:3615:23:590.0019084901733632565922
1 Reply
Support
Support

Re: Session log session duration inaccurate values. Possible bug?

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

To help users find verified answers, please don't forget to mark a correct resolution or answer to your problem or question as correct.