[Zope] Re: More Session errors (now with 2.5.0)

[Chris McDonough]

Thanks for the bugreport Tim...

The traceback is useful, maybe it can help me out as I try to reproduce it.
It's definitely not normal.

Memory leaks are notoriously hard to track down in Zope.  It requires lots
of patience and a good understanding of the debug information presented in
the control panel (mostly patience).  They can come as a result of just
about anything whether it's in the core or its a 3rd-party product and
solving them usually requires a binary search (is it in this half, no... is
it in this half, yes.  ad infinitum ;-)  I'm not sure what else to tell you
about that.  Shane took a stab at a LeakFinder product a while ago that
might be helpful, but I suspect it will still be pretty painful.

The conflict errors are pretty normal... the sessioning machinery attempts
to minimize the number of conflicts, but since the default session data
container is based on ZODB, it's near impossible to eradicate them entirely.
You may get conflicts even on a lightly-loaded site if the site is
frames-heavy and uses sessions in multiple frames.

- C


----- Original Message -----
From: "Tim Hicks" <tim@sitefusion.co.uk>
To: "Chris McDonough" <chrism@zope.com>
Cc: <zope@zope.org>; "Paul Browning" <paul.browning@bristol.ac.uk>
Sent: Friday, March 08, 2002 9:46 AM
Subject: More Session errors (now with 2.5.0)


> Chris/List,
>
> further to my last post (
>
http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/31062F4798B21631
> )about experiencing problems with CST under 2.3.3, I now have a bit more
> information.  Unfortunately, I don't anticipate it will be very helpful in
> diagnosing the problem :-(.
>
> So, the new setup is:
>
> - winNT4
> - zope250
> - DCO2
> - built-in session machinery from zope250 (i.e. not CST anymore)
> - using the same site (exported from zope233 then imported to 250) as
before
>
> The site is under considerably less load now, so errors are few an far
> between, but they *are* happening (I'm fairly certain this is not a load
> issue now).  Here's a sample traceback...
>
> Traceback (innermost last):
>   File C:\PROGRA~1\zope250\lib\python\ZPublisher\Publish.py, line 98, in
> publish
>   File C:\PROGRA~1\zope250\lib\python\ZPublisher\mapply.py, line 88, in
> mapply
>     (Object: details)
>   File C:\PROGRA~1\zope250\lib\python\ZPublisher\Publish.py, line 39, in
> call_object
>     (Object: details)
>   File C:\PROGRA~1\zope250\lib\python\OFS\DTMLDocument.py, line 127, in
> __call__
>     (Object: details)
>   File C:\PROGRA~1\zope250\lib\python\DocumentTemplate\DT_String.py, line
> 473, in __call__
>     (Object: details)
>   File C:\PROGRA~1\zope250\lib\python\DocumentTemplate\DT_Util.py, line
159,
> in eval
>     (Object: sdm.getSessionData().has_key('your_results'))
>     (Info: sdm)
>   File <string>, line 2, in f
>   File
> C:\PROGRA~1\zope250\lib\python\Products\Sessions\SessionDataManager.py,
line
> 91, in getSessionData
>     (Object: sdm)
>   File
> C:\PROGRA~1\zope250\lib\python\Products\Sessions\SessionDataManager.py,
line
> 174, in _getSessionDataObject
>     (Object: sdm)
>   File C:\PROGRA~1\zope250\lib\python\Products\Transience\Transience.py,
> line 133, in new_or_existing
>     (Object: session_data)
>   File C:\PROGRA~1\zope250\lib\python\Products\Transience\Transience.py,
> line 159, in new
>     (Object: session_data)
> KeyError: duplicate key 30923427A0M9AWdSVF0
>
>
> Although obviously different than before (due to the different session
> machinery), it sounds like a pretty similar issue (i.e. the session
> machinery is getting a bit mixed up with session keys - although before it
> seemed that it was losing keys, it now seems like it's duplicating them).
>
> As for your other suggestions last time, I'm afraid we haven't got round
to
> using 'ab' against the site.  Neither have we tried
> "Sessions.stresstests.stresstestMultiThread.py", although now we are using
> the 250 session stuff, this should be fairly easy right?  I'll look into
> this next, but I won't have much spare time for the next 2 weeks.
>
> Other interesting facts are:
>
> We appear to have a memory leak:
>         This was present under zope233 as well, but we didn't spot it at
the
> time.  Do you or anyone else have a good suggestion for tracking this
> problem down?  I am next to clueless in ways to do this :-(.  Could it
> possibly be my web code?  Could it be related to the flakey sessioning? <I
> presume the answer to both is 'Yes', but it's difficult to say either way>
>
> We see periodic zodb conflicts:
>         I can't tell you much more than that until they happen again (we
> lost that particular log).  The confusing thing is, I don't think there
are
> any parts of the site that actually allow people to modify objects in the
> zodb.  People can update an oracle database, and obviously they can query
it
> as well, but that's about it.  So what is trying to write to the zodb?
The
> only thing I can think of is the session machinery, which I why I mention
> it.
>
>
> Sorry to be the bearer of bad tidings.
>
> cheers
>
> tim
>
>