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