[Seaside-dev] collecting expired stuff

[Sebastian Sastre]

I've found a couple of sh*t of my own and I've already fixed it so things are
collecting well as expected. The fat image was not fixable, I've started from
scratch loading my code in a fresh aupdated pharo 2.9a2 also updated (as Lukas
said which loaded just fine in the fresh one)
I still encourage de-team to design a less error prone chain of session
expiration.
thanks,
sebastian

> -----Mensaje original-----
> De: seaside-dev-bounces at lists.squeakfoundation.org 
> [mailto:seaside-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Julian Fitzell
> Enviado el: Wednesday, March 11, 2009 11:04
> Para: Seaside - developer list
> Asunto: Re: [Seaside-dev] collecting expired stuff
> 
> Actually, I sort of agree with you. The request context should
> indicate the dispatch chain of request handlers but a Session is very
> closely tied to an Application (I have said before that
> ApplicationInvocation or something would really be a more accurate
> name than Session) and it does kind of make sense that it should know
> what Application it is an "invocation" of.
> 
> It would be convenient to be able to call #unregister on a Session
> that is not the "current" session as far as the RequestContext is
> concerned.
> 
> The expiry is always triggered from within the Application though (and
> doesn't use #unregister), so that should not be the cause of your
> lingering sessions.
> 
> Julian
> 
> On Tue, Mar 10, 2009 at 10:15 PM, Sebastian Sastre 
> <ssastre at seaswork.com> wrote:
> > hi there,
> > my dev image reached 100MB somehow so I'm making some 
> instance cleaning.
> > I can see a request not found when sending #unregister to 
> non collected
> > sessions.
> > I don't know yet why those sessions where not collected and 
> is an issue of mine
> > for sure but I can't say the expiring technique of 2.9 is 
> helping nor bullet
> > proof.
> > Are that dependence really needed? I mean, to need a 
> request context for
> > reaching the application of a session?
> >
> > sebastian
> >
> > _______________________________________________
> > seaside-dev mailing list
> > seaside-dev at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> >
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev