<div dir="ltr">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 ... <div><br></div><div style>in gemstone, since we persist session state, the in-memory garbage collector is not impacted by a "bloated" continuations cache ... </div>
<div style><br></div><div style>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 ...</div>
<div style><br></div><div style>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...</div>
<div style><br></div><div style>Dale</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 2:04 PM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Tue, Mar 11, 2014 at 5:38 PM, Dale Henrichs <span dir="ltr"><<a href="mailto:dale.henrichs@gemtalksystems.com" target="_blank">dale.henrichs@gemtalksystems.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Mariano,<div><br></div><div>I haven't delved into the timeouts for quite some time, so this is from memory and I could be completely wrong:).</div>
<div><br></div><div>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 ... </div>
<div><br></div><div>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 ...</div>
<div><br></div><div>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 ....</div>
<div><br></div><div>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... </div>
<div><br></div><div>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) ...</div>
<div><br></div><div>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 ...</div>
<div><br></div></div></blockquote><div><br></div></div><div>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?</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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 ... </div>
</div></blockquote><div><br></div></div><div>Exactly!!!! That was my reasoning too...but then I wonder why the continuations time out existed at all ;)</div><div><br></div><div>Thanks, </div><div><div class="h5"><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Dale</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Tue, Mar 11, 2014 at 12:53 PM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi guys,<div><br></div><div>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:</div>
<div><br></div><div>MyWASessionSubclass >> setParent: aRequestHandler</div><div><span style="white-space:pre-wrap"> </span>super setParent: aRequestHandler.</div><div><span style="white-space:pre-wrap"> </span>continuations expiryPolicy configuration attributeAt: #cacheTimeout ifAbsent: [ ^ self ].</div>
<div><span style="white-space:pre-wrap"> </span>continuations expiryPolicy configuration attributeAt: #cacheTimeout put: (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).</div><div><br></div><div><br>
</div><div>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....</div><div><br></div><div>
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....</div><div><br>
</div><div>Thanks in advance, </div><div><br></div><div> </div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Mon, Apr 23, 2012 at 9:19 AM, keropotter <span dir="ltr"><<a href="mailto:keropotter@gmail.com" target="_blank">keropotter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">Yes, that's what Dale suggested and it worked perfectly.<br><br>Thank you!!<br>Ale<br><br>
<div class="gmail_quote">On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <span dir="ltr"><<a href="http://user/SendEmail.jtp?type=node&node=4580243&i=0" rel="nofollow" link="external" target="_blank">[hidden email]</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <<a href="http://user/SendEmail.jtp?type=node&node=4578211&i=0" rel="nofollow" link="external" target="_blank">[hidden email]</a>> wrote:
<br>> 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:
<br>>
<br><br></div>Subclassing WASession and overriding #createCache should work.
<br><br>Cheers
<br>Philippe
<br>
<br>
<br>
</div><hr size="1" color="#cccccc" noshade>
<div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif"><div><div>
<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
</div></div><a href="http://forum.world.st/Set-session-duration-tp4553027p4578211.html" rel="nofollow" link="external" target="_blank">http://forum.world.st/Set-session-duration-tp4553027p4578211.html</a>
</div><div><div><div>
<div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
To unsubscribe from Set session duration, <a rel="nofollow" link="external">click here</a>.<br>
<a href="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" rel="nofollow" style="font:9px serif" link="external" target="_blank">NAML</a>
</div></div></div></div></blockquote></div><br></div>
<br><hr align="left" width="300">
View this message in context: <a href="http://forum.world.st/Set-session-duration-tp4553027p4580243.html" target="_blank">Re: Set session duration</a><div><div><br>
Sent from the <a href="http://forum.world.st/GLASS-f1460844.html" target="_blank">GLASS mailing list archive</a> at Nabble.com.<br></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>
Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
</font></span></div>
<br></div></div>_______________________________________________<br>
Glass mailing list<br>
<a href="mailto:Glass@lists.gemtalksystems.com" target="_blank">Glass@lists.gemtalksystems.com</a><br>
<a href="http://lists.gemtalksystems.com/mailman/listinfo/glass" target="_blank">http://lists.gemtalksystems.com/mailman/listinfo/glass</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
</font></span></div></div>
</blockquote></div><br></div>