[Zope] Zope leaking memory?

[Chris McDonough]

On Wed, 2004-09-15 at 00:49, Chris McDonough wrote:
> On Wed, 2004-09-15 at 00:01, Richard Jones wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Wed, 15 Sep 2004 08:11 am, Richard Jones wrote:
> > > On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
> > > > Something I've done in the interim, which I *think* will help things, if
> > > > I'm reading the various tracker issues and email threads correctly, is my
> > > > standard_error_message DTML page doesn't email the REQUEST to me (and
> > > > hence the SESSION) any more, as that accesses the Transience stuff during
> > > > exception handling, which is apparently bad.
> > >
> > > Several new POSKeyErrors overnight tell me that I was barking up the wrong
> > > tree here. Sigh.
> > 
> > I just realised that the error_log object has the REQUEST/SESSION information 
> > in it, so my changes would have had no impact.

> Yikes.  That's actually really bad.  I will change REQUEST's __str__ to
> prevent a session data object from being created as a side effect!

False alarm, sorry.  A session data object doesn't actually get created
as a result of str(REQUEST) -- the 'SESSION' item in the request remains
"lazy" in this case.  Whew. ;-)

FYI, if you see something like:

SESSION <bound method SessionDataManager.getSessionData of
<SessionDataManager instance at f3a87710>>

... in a REQUEST rendering, it indicates a session that is still "lazy",
which means a session hasn't actually been created during this request.

OTOH, if you see something like:

SESSION   id: 10952247771174881012, token: 06504336A1fW8kmVMHc,
contents: [('count', 0)]

... in the log, it means that a session was created at some point during
the request.

A session data object always gets created as a side effect of
REQUEST.keys(), REQUEST['SESSION'], REQUEST.SESSION,
REQUEST.get('SESSION') or REQUEST.has_key('SESSION'), or when
sdm.getSessionData() is called explicitly.

But unless you did any of the latter in the email, you're no better or
worse off than when you started really.  Not that you would have been
bad off anyway. ;-)  It *should* be fine to do transience operations
during an exception (the publisher behavior that made it not so was
fixed before 2.7.1).  The worst thing that should be able to happen is
that the standard error message itself errors out with a conflict error,
the emergency error handler runs as a result, and renders that conflict
error to the requesting user agent.

- C