[Seaside] Memory leak?

[Avi Bryant]

On Tue, 28 Jan 2003, Stephen Pair wrote:

> After several weeks of developing and testing in a Seaside image, the
> image has grown to ~66MB when saved.  Upon further inspection, it
> appears that there 4758 instances of WAResponse in my image.  When you
> consider the various strings and streams that a WARequest holds, I think
> this is accounting for the bulk of my image bloat.
>
> Any ideas whether this is a legitimate issue, or is there something I
> should be doing to clean these up?

Is it WAResponse or WARequest that you have a lot of?
Regardless, you should know that Application keeps an LRUCache of
sessions, and Session keeps an LRUCache of continuations, and LRUCache
defaults to keeping the 100 most recently used items - so a single
application can have 10000 continuations around without throwing any out.
Try reinitializing 'sessionCache' on one of your well-used applications,
garbage collect, and see if memory use goes down significantly.  Or just
try

WAApplication resetAllApplications

When I do that on my image, all the response and request objects
disappear.

> Also, related to this topic, here are a couple of feature requests:
>
> 1) The ability to disable web browser backtracking...if disabled and a
> user hits the back button a couple of times, then hits a link...seaside
> could inform the user that the link is expired and that they are being
> redirected to a current view of their session (I prefer this to
> redirecting to a new session because that would make it too easy for a
> user to accidentally dump their session and lose anything they were
> working on).

Seaside does exactly this when a continuation expires - the behavior
you're describing is basically equivalent to setting the capacity of the
continuations LRUCache to 1.

> 2) The ability to restrict the backtacking depth (to conserve server
> resources)...this would allow you to make compromise between usability
> and server resource consumption...for example, if the backtracking depth
> is 10, then the user could back up up to 10 pages and use a link on
> those pages

Ditto above.

> 3) Actually, this is more of a question...how closely is Seaside
> modeling browser behavior wrt to back tracking?  For example, if a user
> backs up one page, then uses a link on that page, Seaside could discard
> the orginal page since there is no way of getting back to that page
> using the browser's back or forward buttons (granted, you could copy and
> paste the URL, but I think it would be quite reasonable if that page and
> any links on it were expired).

Nah, people use tabbed browsers or cloned browser windows all the time.
There's no good way to predict when a user still has access to a url and
when they don't.

> 4) The ability to discard all backtracking information for a given
> session.  This may be simple to accomplish and already implemented...if
> so, could someone describe the proper way to do this?  There are
> circumstances (especially relating to security) where you don't want
> someone to be able to backtrack and use old links...the best example is
> when a user logs out.  I suppose could trash the session and begin a new
> one, but I like have the session map to a web browser/server
> interaction, not to a particular authorization context.

It sounds like what you want is #isolate:.  If you wrap a piece of code in
session isolate: [...], then as soon as the end of that block is reached,
all the pages created within it immediately expire.

> P.S.  Implementing security on top of Seaside has been a dream!  Seaside
> basically has a built in capability framework.  Consider that when you
> hit a seaside component, the only thing a user can do is use the links
> that have been exposed to him/her on that page.  These are the "keys" to
> the capabilities you've granted your user.  All you need to add to the
> equation is a framework (like ACLs) to guard Seaside's keys.

Guard the keys in which way?

Avi