[Seaside-dev] Handling of session expiration
Dale Henrichs
dale.henrichs at gemstone.com
Wed Nov 7 17:36:05 UTC 2007
Esteban,
In GemStone, since we are oriented towards multiple vms sharing session
state, we've moved the session expiration logic into a separate vm (our
maintenance vm) that expires sessions about once a minute. By persisting
session state we also avoid the load on the in-memory vm garbage
collector, of course we just move the load to the repository garbage
collector, but that only needs to be run on the order of hours to keep
garbage manageable.
I understand that folks use Seaside in production have a couple of
different schemes for managing session state (non-Gemstone instances),
first of which is to spread the session state load across multiple vms
(using session affinity) so that no one vm's garbage colector is slammed
to the wall. Secondly, they leave the session expiry at a low value (say
ten minutes) and then use a browser-based thread that keeps the session
alive as long as the page is visible in the browser.
If you do look at WaRegistry>>shouldCollectHandlers you'll notice that
sessions are expired only when the registry grows .... that logic could
be adjusted to expire sessions when the vm is under memory pressure as
well, so that aged sessions can be expired after a period of intense
activity.
Dale
Lukas Renggli wrote:
>>If I place a background process cleaning all the handlers every 30
>>seconds, the image runs very well, with no unnecesary continuations,
>>nor nothing undesired.
>>
>>[[Processor sleep: 30000. WARegistry clearAllHandlers. true ] repeat]
>>forkAt: Processor userBackgroundPriority .
>>
>>
>
>You will also loose all your active sessions every 30 seconds. Most
>certainly you don't want this.
>
>
>
>>How do you handle the "cleaning" of undesired/expired
>>WARequestHandler's? (and all of its subclasses).
>>
>>
>
>Seaside clears up old sessions every now and then wenn a new session
>is created. Have a look at #shouldCollectHandlers and friends. This is
>also the reason why sessions do not just disappear if not used. You
>will always have a couple of sessions and associated objects lingering
>around, even if none of them are active at the moment.
>
>
>
>>I've run the same test against Seaside on Squeak, and evaluating
>>"Continuation allSubinstances" answer a very large list of instances
>>too, so I believe this issue is not Dolphin-only.
>>
>>
>
>Usually this is not a problem.
>
>Lukas
>
>
>
More information about the seaside-dev
mailing list