Bug 1263 - "Current Sessions" is often too high
Summary: "Current Sessions" is often too high
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: 1.3.2
Hardware: PC Linux
: P2 Normal
Target Milestone: 4.8.0
Assignee: Peter Åstrand
Keywords: astrand_tester
Depends on:
Reported: 2005-04-11 09:51 CEST by Peter Åstrand
Modified: 2017-04-04 12:41 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:

Last 300 lines of vsmserver.log on primary (24.61 KB, text/plain)
2005-04-11 17:25 CEST, Peter Åstrand
Last 800 lines of vsmserver.log on secondary (80.94 KB, text/plain)
2005-04-11 17:25 CEST, Peter Åstrand

Description Peter Åstrand cendio 2005-04-11 09:51:13 CEST
I've noticed that the "Curren Sessions" figure, as written to
/var/log/thinlinc-user-licenses, often is too high. Currently, on my RHEL
cluster, it says 5, even though I only have one single session.
Comment 1 Peter Åstrand cendio 2005-04-11 09:51:59 CEST
This bug is critical when running VSM without a system.license, since then we
have a hard limit of 1 user. 
Comment 2 Erik Forsberg cendio 2005-04-11 09:59:49 CEST
Does this happen both when running in HA mode and when running without HA enabled?
Comment 3 Peter Åstrand cendio 2005-04-11 10:05:27 CEST
I'm not sure. I think I've seen this on non-HA system as well. I'll try to
reproduce this with HA disabled. 
Comment 4 Peter Åstrand cendio 2005-04-11 10:19:05 CEST
Yes, I've been able to reproduce this with HA disabled:

Currently, /var/log/thinlinc-user-licenses says 4, but I only have 3 sessions

If restarting vsmserver, vsmserver.log says:

Current number of users: 3

...but /var/log/thinlinc-user-licenses still says 4. 
Comment 5 Erik Forsberg cendio 2005-04-11 12:58:38 CEST
I think I've fixed this now. Problem occured because the new sessionstore code
didn't update the license log as often as the old code.

I might have fixed bug 1262 as well, so please test what happends when running
in HA mode.
Comment 6 Peter Åstrand cendio 2005-04-11 14:05:08 CEST
Works when HA is disabled. Will test with HA as well. 
Comment 7 Peter Åstrand cendio 2005-04-11 14:25:14 CEST
I've been unable to reproduce the problem, even with HA. Seems to work good. 
Comment 8 Peter Åstrand cendio 2005-04-11 17:23:34 CEST
No, this is still a problem. After testing on my HA cluster,
thinlinc-user-licenses says 5, and there are 5 sessions in
/var/lib/vsm/sessions, even though all my started sessions have terminated. 
Comment 9 Peter Åstrand cendio 2005-04-11 17:25:04 CEST
Created attachment 97 [details]
Last 300 lines of vsmserver.log on primary
Comment 10 Peter Åstrand cendio 2005-04-11 17:25:32 CEST
Created attachment 98 [details]
Last 800 lines of vsmserver.log on secondary
Comment 11 Peter Åstrand cendio 2005-04-11 17:26:21 CEST
One interesting thing is this traceback, on the secondary:

2005-04-11 17:06:53 WARNING vsmserver.HA: Other node told us to remove session
for user24, but our copy of session dat
a does not concur
2005-04-11 17:06:53 DEBUG vsmserver.session: Verifying session for user24 on
2005-04-11 17:06:53 WARNING vsmserver.HA: Session for user24 is OK. Telling
other node.
Traceback (most recent call last):
  File "/opt/thinlinc/modules/xmlrpcserver.py", line 54, in do_POST
  File "/opt/thinlinc/modules/xmlrpclib.py", line 918, in dumps
    data = m.dumps(params)
  File "/opt/thinlinc/modules/xmlrpclib.py", line 578, in dumps
    dump(v, write)
  File "/opt/thinlinc/modules/xmlrpclib.py", line 588, in __dump
    raise TypeError, "cannot marshal %s objects" % type(value)
TypeError: cannot marshal <type 'NoneType'> objects
Comment 12 Peter Åstrand cendio 2005-04-11 18:32:03 CEST
My guess is that the error lies in loadstatus_update_thread(). One problem with
this function is that it's very long and complex: It's 127 lines, with as many
as 8 different indentation levels. 
Comment 13 Peter Åstrand cendio 2005-04-11 22:53:42 CEST
It seems that the problem was that the data in sessionstore.dead_children was
lost when vsmserver exited. Fixed in revision 1.178 of vsmserver. 
Comment 14 Peter Åstrand cendio 2005-04-12 11:10:24 CEST
Regarding the traceback in comment 11: On the other node, this was found in

2005-04-11 17:07:23 DEBUG vsmserver.HA: Trying to contact other node for session
info transfer
2005-04-11 17:07:24 ERROR vsmserver.HA: Unexpected error trying to transfer
session info to tlha-secondary.localdomain
Traceback (most recent call last):
  File "/opt/thinlinc/vsm/HA.py", line 65, in HA_session_update_thread
    iI11 = oO0 . sessionchange ( iiiI11 )
  File "/opt/thinlinc/modules/xmlrpclib.py", line 986, in __call__
    return self.__send(self.__name, args)
  File "/opt/thinlinc/modules/xmlrpclib.py", line 1239, in __request
  File "/opt/thinlinc/modules/xmlrpclib.py", line 1027, in request
ProtocolError: <ProtocolError for tlha-secondary.localdomain:9000/RPC2: 500
Internal error>
Comment 15 Peter Åstrand cendio 2005-04-12 11:13:14 CEST
I'm still able to reproduce this bug, by stopping and starting vsmserver &
heartbeat, and at the same time doing logins. The problem seems to be less
severe now, though, and it only happens if you are trying hard to reproduce this. 

The number of current sessions is corrected when vsmserver is restarted. 

This shouldn't be critical for 1.4.0. 
Comment 16 Erik Forsberg cendio 2005-05-09 16:05:54 CEST
Hmm.. this might be a bit hard to track down. Doing a rough time estimation.
Comment 17 Samuel Mannehed cendio 2017-03-31 14:42:00 CEST
moving from 'mediumprio' to '--', close?
Comment 18 Pierre Ossman cendio 2017-04-04 12:41:05 CEST
We haven't seen this in ages and the code received a major rewrite back in 2.0. Closing.

Note You need to log in before you can comment on or make changes to this bug.