[Glass] [GS/SS Beta] Set session duration
Dale Henrichs
dale.henrichs at gemtalksystems.com
Tue Mar 11 18:29:13 PDT 2014
In a Pharo image the continuations could take up a lot of object memory and
that can up a load on the in-memory garbage collector ...
in gemstone, since we persist session state, the in-memory garbage
collector is not impacted by a "bloated" continuations cache ...
of course you end up paying the piper by having to watch your repository
size and run regular MFCs ... the epoch gc can help cut down on the amount
of persistent garbage created when the cache entries expire ...
Finally I think that Johan has played around with not even bothering to
save the older cache entries at all ... they really only need to be saved
for the back button to work and if your app is using AJAX the back button
is not used ... I think...
Dale
On Tue, Mar 11, 2014 at 2:04 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:
>
>
>
> On Tue, Mar 11, 2014 at 5:38 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Mariano,
>>
>> I haven't delved into the timeouts for quite some time, so this is from
>> memory and I could be completely wrong:).
>>
>> IIRC, there are two caches that are two caches that are subject to
>> timeouts: the session cache and "continuation cache" ... when the session
>> is timed out, the session itself is no longer accessible ...
>>
>> The "continuation cache" manages the lifetime of individual link
>> continuations for a particular page and when a continuation is timed out
>> that particular link is no longer accessible while the session and other
>> links are still available ...
>>
>> the mtce vm process is responsible for timing out both the session cache
>> and continuation cache (see WABasicDevelopment
>> class>>reapHandlerCache:dispatchers:) and the reaping is done via the
>> message gemstoneReap ....
>>
>> GemStone uses the WARcLastAccessExpiryPolicy and this should not be
>> changed as the reduced conflict aspect is important for GemStone ... if
>> other types of Expiry polices are needed, they just need to be made RC ...
>> the implication of this is that timeout is used to determine expiration...
>>
>> I think that standard Seaside uses a different scheme (least recently
>> used?) for continuations and I seem to recall that a count of some kind was
>> involved (not sure about this bit) ...
>>
>> The timeout will impact links from the aspect that if a link isn't used
>> during the timeout period it will be reaped while the session itself can
>> continue to live as long as it has been accessed so continuations are not
>> kept alive for the duration of a session ...
>>
>>
> Yes..that was what was happening to me. I had the main component of my app
> (the one that is present at anytime) and if I click in any menu or
> something then I was kickoff. But what can I do if it is not clicking or
> doing something?
>
>
>> Given this information I can't think of a reason why you would need to
>> set the timeout for continuations less than the session timeout and I don't
>> think it makes sense to set the continuation timeout longer than the
>> session timeout, since I don't think that old links are in danger of being
>> accessed past the link timeout ...
>>
>
> Exactly!!!! That was my reasoning too...but then I wonder why the
> continuations time out existed at all ;)
>
> Thanks,
>
>
>> Dale
>>
>>
>>
>>
>> On Tue, Mar 11, 2014 at 12:53 PM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> I am reviving this old thread because I have been caught by the same
>>> problem. In my case, I wanted to expire at the same time I have defined for
>>> the app (moreover, same session class could be used in different apps with
>>> different expiration times). Also, I wanted to use the same session class
>>> for Pharo and for GemStone. So what I did was to implement:
>>>
>>> MyWASessionSubclass >> setParent: aRequestHandler
>>> super setParent: aRequestHandler.
>>> continuations expiryPolicy configuration attributeAt: #cacheTimeout
>>> ifAbsent: [ ^ self ].
>>> continuations expiryPolicy configuration attributeAt: #cacheTimeout
>>> put: (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).
>>>
>>>
>>> I couldn't use the #initialize because at that point my app was not yet
>>> set..and I wanted to grab the timeout from there. The ugly IF is just so
>>> that it works in Pharo as well....
>>>
>>> Now...the question is...what is this timeout of continuations? How does
>>> it impacts me as a developer? it is correct to set the same time as the
>>> app? From my tests it does seem the case, but I just wonder....
>>>
>>> Thanks in advance,
>>>
>>>
>>>
>>>
>>> On Mon, Apr 23, 2012 at 9:19 AM, keropotter <keropotter at gmail.com>wrote:
>>>
>>>> Yes, that's what Dale suggested and it worked perfectly.
>>>>
>>>> Thank you!!
>>>> Ale
>>>>
>>>> On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden
>>>> email] <http://user/SendEmail.jtp?type=node&node=4580243&i=0>> wrote:
>>>>
>>>>> On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]<http://user/SendEmail.jtp?type=node&node=4578211&i=0>>
>>>>> wrote:
>>>>> > It doesn't look like there is any way to actually control the
>>>>> timeout used by the continuation cache without directly editing the code.
>>>>> The WASession>>createCache method looks like the following:
>>>>> >
>>>>>
>>>>> Subclassing WASession and overriding #createCache should work.
>>>>>
>>>>> Cheers
>>>>> Philippe
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> If you reply to this email, your message will be added to the
>>>>> discussion below:
>>>>> http://forum.world.st/Set-session-duration-tp4553027p4578211.html
>>>>> To unsubscribe from Set session duration, click here.
>>>>> NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> View this message in context: Re: Set session duration<http://forum.world.st/Set-session-duration-tp4553027p4580243.html>
>>>>
>>>> Sent from the GLASS mailing list archive<http://forum.world.st/GLASS-f1460844.html>at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140311/4c7d6e73/attachment.html>
More information about the Glass
mailing list