www.cendio.com
Bug 1263 - "Current Sessions" is often too high
: "Current Sessions" is often too high
Status: CLOSED INVALID
: ThinLinc
VSM Server
: 1.3.2
: PC Linux
: P2 Normal
: 4.8.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-04-11 09:51 by
Modified: 2017-04-04 12:41 (History)
Acceptance Criteria:


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


Note

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


Description From cendio 2005-04-11 09:51:13
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 From cendio 2005-04-11 09:51:59 -------
This bug is critical when running VSM without a system.license, since then we
have a hard limit of 1 user. 
------- Comment #2 From cendio 2005-04-11 09:59:49 -------
Does this happen both when running in HA mode and when running without HA
enabled?
------- Comment #3 From cendio 2005-04-11 10:05:27 -------
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 From cendio 2005-04-11 10:19:05 -------
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
started. 

If restarting vsmserver, vsmserver.log says:

Current number of users: 3

...but /var/log/thinlinc-user-licenses still says 4. 
------- Comment #5 From cendio 2005-04-11 12:58:38 -------
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 From cendio 2005-04-11 14:05:08 -------
Works when HA is disabled. Will test with HA as well. 
------- Comment #7 From cendio 2005-04-11 14:25:14 -------
I've been unable to reproduce the problem, even with HA. Seems to work good. 
------- Comment #8 From cendio 2005-04-11 17:23:34 -------
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 From cendio 2005-04-11 17:25:04 -------
Created an attachment (id=97) [details]
Last 300 lines of vsmserver.log on primary
------- Comment #10 From cendio 2005-04-11 17:25:32 -------
Created an attachment (id=98) [details]
Last 800 lines of vsmserver.log on secondary
------- Comment #11 From cendio 2005-04-11 17:26:21 -------
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
tlha-primary.localdomain
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
    methodresponse=1
  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 From cendio 2005-04-11 18:32:03 -------
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 From cendio 2005-04-11 22:53:42 -------
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 From cendio 2005-04-12 11:10:24 -------
Regarding the traceback in comment 11: On the other node, this was found in
vsmserver.log:

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
    verbose=self.__verbose
  File "/opt/thinlinc/modules/xmlrpclib.py", line 1027, in request
    headers
ProtocolError: <ProtocolError for tlha-secondary.localdomain:9000/RPC2: 500
Internal error>
------- Comment #15 From cendio 2005-04-12 11:13:14 -------
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 From cendio 2005-05-09 16:05:54 -------
Hmm.. this might be a bit hard to track down. Doing a rough time estimation.
------- Comment #17 From cendio 2017-03-31 14:42:00 -------
moving from 'mediumprio' to '--', close?
------- Comment #18 From cendio 2017-04-04 12:41:05 -------
We haven't seen this in ages and the code received a major rewrite back in 2.0.
Closing.