[Zope] Re: CST 0.9 Problems under load?

[Chris McDonough]

> I did a quick search on the nip list archive, but couldn't find Terry
Kerr's
> patch.  Where can I find it?  I'd like to give the patches a try.  The
only
> problem is, the server probably won't see the same kind of load until this
> time next year.  Do you have any good ways of programmatically loading the
> server and invoking the session machinery?  Is this where 'ab' comes in?

Terry's message to me on the subject is attached.  It doesn't sound like the
same problem, though. :-(

There is a module named "Sessions.stresstests.stresstestMultiThread.py" in
the Zope 2.5 sessioning stuff that tries to put the sessioning machinery
under load.  It might be adapted for CST.

If you could create the same problem with "ab", that would be just as valid
a test.  Anything to recreate the error condition(s).

> > I'm afraid for now that I'm going to have to suggest that you either
wait
> > for CST 1.0 (which has not ETA as of now) or try the Zope 2.5 Sessioning
> > machinery.
>
> OK, fair enough.  I realise that CST has turned into a bit of a
side-project
> for you now.  If I manage to reproduce the same sort of results using the
> 2.5.0 session machinery, will I stand a better chance of seeing a fix?
I'd
> love to be able to help, but I'm well over my head at the moment.

If there was a replicable test case that reproduced a specific failure for
CST 0.9, I'd almost certainly be able to fix it in a reasonable amount of
time.  But I'm unable to take action on "it does X under nonspecific
conditions" types of bugreports because I can't even begin to estimate how
long it would take to guess the conditions under which the error is raised.

There's an equal chance of seeing a fix for either CST or Zope 2.5 out of me
the moment, which is just about zero for at least the next two weeks.
:-(  That said, I believe the sessioning stuff in Zope 2.5 is very stable.
I want to write a compatibility layer between its API and the CST API and
release *that* as "CST 1.0 " (for use in Zope older than 2.5) as soon as I
can (if that's even possible).  I've realized that I cannot support both in
good faith and I need to find a way to merge the two codebases somehow.

If I find anything out, I'll send mail to the list.

Sorry again!

- C


Terry's message follows:

Chris,

The problem I was having with the DB connection locking last week is solved.
The patch I explained to you did not fix the problem on our live server,
even
though it did stop the hang for the example on my workstation, so obviosly
the
problem was not related.

The problem on our live server was with CST 0.9.  I noticed many of the
following error, but always ignored them and assumed they were harmless as
advised by somebody on zope-dev a while agao

2001-11-16T06:46:22 ERROR(200) ZODB Close callback failed for
<Products.CoreSessionTracking.SessionDataManager.ConnectionCloser instance
at
0x880680c>
Traceback (innermost last):
   File /usr/local/zope/Zope-2.4.3-src/lib/python/ZODB/Connection.py, line
283,
in close
   File
/usr/local/zope/Zope-2.4.3-src/lib/python/Products/CoreSessionTracking/Sessi
onDataManager.py,
line 581, in __call__
KeyError: _v_container


I noticed that there were exactly 5 of these between each server hang...so I
assume that each one was killing a thread.  So I patched CST 0.9 to prevent
the
exception, and the server has gone from restarting every 20 minutes, to no
restarts in 3 days (since I did the patch)

*** SessionDataManager.py       Fri Oct  5 15:54:29 2001
--- /home/zope/instance/Products/CoreSessionTracking/SessionDataManager.py
Fri Feb  1 16:02:10 2002
***************
*** 578,584 ****
           """ This is called by the 'parent' connection's onCloseCallback
           handler, so that our 'spawned' connection will be closed when
           our parent connection is closed. """
!         del self.sdm._v_container
           if self.conn is not None:
               self.conn.close()
               self.conn=None
--- 579,586 ----
           """ This is called by the 'parent' connection's onCloseCallback
           handler, so that our 'spawned' connection will be closed when
           our parent connection is closed. """
!         if hasattr(self.sdm, '_v_container'):
!             del self.sdm._v_container
           if self.conn is not None:
               self.conn.close()
               self.conn=None


Is there going to be another release of CST, or is session tracking in zope
2.5 it?

terry