> > We are trying to get to the bottom of a few straggling
> > instability reports, so we're planning to go ahead with
> > a b2 as soon as we've either a) figured out and fixed them
> > b) figured them out and found it wasn't a Zope core problem
> > or c) decide that we can't make enough progress in a
> > reasonable time to continue holding up the release.
> Is there anything that we with unstable Zopes can do to help?

The best way to help is to help get this (these) down to 
a minimal, reproducable test case. Getting there can be 
tricky, but there are some things that we can try to find 

  - In the logs, is there any pattern to what is being 
    accessed at the time of the crash? If there is a 
    particular object or objects that seems to often be 
    the last accessed before a crash, we can start looking 
    at what PythonScripts the object uses.

  - Use the "big M" log to try to narrow down exactly what 
    is happening at the time of the crash.

  - Ensure that you are getting absolutely no "python scripts 
    need to be recompiled" messages

  - Absolutely eliminate SQL db access as a cause (it sounds 
    like we have proof of this now)

Brian Lloyd        [EMAIL PROTECTED]
V.P. Engineering   540.361.1716       
Zope Corporation   http://www.zope.com

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to