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