“Session Terminated Abnormally” in detailed report

Get help with CAN-8 here. Do not post bug reports or feature requests here.

“Session Terminated Abnormally” in detailed report

Unread postby Richard » Wed Jan 23, 2013 4:40 pm

This posting has been migrated from the old forum as it may be of general interest.


Here is another issue related to the reporting. The teacher was doing summary report for the class usage for particular day and saw that the time for two of the students was 00:00:00. Students claimed that they used the system and when teacher did a detailed report for that day, she saw that students indeed worked in CAN 8, but there was no logout and total duration time for the session. I did a detailed report for those students with no period specified and saw that that the next time they logged in CAN 8 there was 00:00:00 “Session Terminated Abnormally” and total duration time for the previous session in the first line of the detailed report.
Yesterday I tested the same scenario with a test account and it was the same behavior of the 32-bit client - do not terminate the session and do not record the total duration time when can 8 process terminated forcefully. The next time user logs in to CAN 8 it records “Session Terminated Abnormally”.
Just before I left, I tested the same with the 16-bit client and everything was ok - it was terminating the session and showing logout times even if the session was terminated forcefully.
Last night the server on which CAN 8 runs was restarted after some Microsoft updates were installed and this morning I could not reproduce the behavior from yesterday. Even with the new client the session is terminated properly and no “Session Terminated Abnormally” messages anymore.
We would like to know what is the possible reason for that message. And how to avoid such issues in the future.

When a client station logs on, the server writes a logon entry and expects a log off message.
In a normal session, when the Log off message arrives, the server can then calculate the session duration with these 2 times.

When a client loses connection with the server due to a network issue or a client crash, after a minute or so of trying to contact the client, the server writes in a "user watchdog timeout" in the server.log and terminates the session properly. Again we have a login time and a log out time.

If you close the server properly while users are signed in, you (the user) receive a warning that x number of users are still logged in , do you still wish to stop the service. If you say yes, these sessions are closed properly and time stamped as they should, and all goes well.

The problem occurs when the client stations are logged in, and the server is forcefully shut down (the process is killed instead of the software being shut off properly, the server machine crashes or is forcefully shut down while the software is running). Now we have an abnormal situation because the server never got a chance to write the Log off entries, or even an end of its own session.

So let's say
- user A logs in in today at 11 AM
- the server is improperly shut down at 12:00 while this user is still signed on.
- The server is then restarted at 13:00.
- User A logs in in again at 13:30

By 13:00 when the server is restarted, it still does not have a user log off for USER A as the forced shut off prevented it to write the stamp record.
In fact, the only time the server knows that USERS A's session was terminated is when the same user actually logs back on at 13:30.
At which point the server terminates the previous session and generates a new login time stamp.

So far so good. But the server has no way to calculate the real time spent in by USER A on the 11:00 AM session since the log off times stamp has just been generated, icon_sad2.gif and the server is now aware that something went wrong at some point for that user.

- We could calculate it from 11 AM to the next time stamp which is !3:30, but that would be wrong.
- We could also estimate the time spent, but again it would be speculation.
- The server has no way to know when it was killed itself.
So the server instead reports 00:00 and the message "session terminated abnormally."

And since the server only realizes that the user was signed off improperly when the same user sign in again, it can only write this message at the time the user signs in, which is the behavior you have observed.

The Microsoft Update you did most likely had nothing to do with your issues, or getting rid of them, but re-booting the server and stopping the service properly did certainly help generate a proper session log off for all the users that were left in that 1/2 state .
Richard
 
Posts: 16
Joined: Mon Jan 21, 2013 2:03 pm
Location: Toronto

Return to Support

Who is online

Users browsing this forum: No registered users

cron