> > 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 out: - 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] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )