On Wed, 2002-03-13 at 13:03, Brian Lloyd wrote:

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? -- Ideas don't stay in some minds very long because they don't like solitary confinement.

On Wed, 2002-03-13 at 14:04, Brian Lloyd wrote:

The best way to help is to help get this (these) down to a minimal, reproducable test case.

The problem is, as far as I could check, the crashes all happen inside the gc, which runs orthogonal to the requests, so getting a reproduceable test case is really hard.

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.

No, crashes happen all over the map (most of the site runs the same python scripts for authentication and inside ZClass instances)

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

Will do, but since the crashes happen all over the map, I don't think we'll be able to get much out of it

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

Check!

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

Check! As someone else mentioned on this list, maybe if we could force the gc to collect alligned with the requests (say, in the first phase of the two-phase-commit transaction engine, or after the second phase) we could get the crashes to be reproduceable, or at least more localized. Also, as I pointed out before, since '-t 1' solves the crashes, if we could incrementally reduce the contention area around the code, by putting and successively removing locks around certain sections, we might be able to track it down. The problem is, I don't know enough about Zope code to know how to do any of those things, and I suspect the other folks with crashes are in the same situation. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.

On Wed, 2002-03-13 at 12:04, Brian Lloyd wrote:

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

This sounds like it is not specific to any DA. Is that the case? -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons.

"Brian Lloyd" <brian@zope.com> writes:

We are trying to get to the bottom of a few straggling instability reports, so we're planning to go ahead with

Hi Brian, I started with 2.5.1b1 today and have problems with our "one central index_html" approach. It seems that in 2.5.1b1 object lookup doesn't start at the current context when an object is used from another already acquired one. I couldn't find anything about this, so I hope it's something new for you. Example: / index_html (index_html uses method content) content /folder1 content /folder1/subfolder1 content When accessing /folder1 or /folder1/subfolder1 always content from the root folder is used. Do we have a stupid mistake or is there something wrong in 2.5.1b1? The root folder is "made root" by a SiteRoot object and we have a SiteRoot also in Zopes root folder. I tried also with the SiteRoots removed and the behaviour was the same. Regards, Frank

Martijn Faassen <faassen@vet.uu.nl> writes:

I can't reproduce this myself. Are you using DTML, PageTemplates, something else?

I tried with 2.5.0 also and had the same effect. I assume there is some Product interference - I will try to eliminate the one. Maybe it's a patched version of ZSyncer. I will report here. Thanks for taking the time for a check. Regards, Frank