|Anonymous | Login | Signup for a new account||12-03-2023 11:34 PST|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000020||[Resin]||minor||always||03-07-05 00:00||11-30-05 14:43|
|Priority||high||Resolution||unable to reproduce||Platform|
|ETA||none||Fixed in Version||3.0.13||Product Version|
|Summary||0000020: Sessions don't get destroyed in srun cluster|
We are using Resin Professional 3.0.12 with an srun cluster setup. Things work normal for some time, then sessions don't get destroyed any more. Sessions accumulate until the server crashes due to overload. With full logging enabled one can see that the cleanup thread which in normal operation cleans the timeouted sessions every second just diappears at some point in time, hence no more sessions get destroyed. Nothing else in the logs.
|Steps To Reproduce|
According to the configuration, there is no persistent store.
So the fact that the configuration is clustered is irrelevant.
Therefore, the maximum number of sessions is the 4096 in the configuration. If that value causes an overload, it would need to be reduced. (Which would indicate that too much information is being put in the session.)
We followed your suggestion to reduce session max (The three in resin.conf defined webapps with new session max values of 2048/200/20), but still the problem occurs.
Some more details:
* some of the nodes work for weeks before the problems occurs ("cleanup" Thread vanishes / does nothing any more)
* on some nodes the problem occurs after some hours
* this happens in random order on all nodes, not always on the same node
* all nodes do the same
|Can't reproduce this issue.|
|03-07-05 00:00||user35||New Issue|
|11-30-05 00:00||administrator||Fixed in Version||=> 3.0.13|
|11-30-05 14:43||ferg||Status||resolved => closed|
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
37 total queries executed.|
29 unique queries executed.