[Zope-Coders] Zope 2.6 breaks CMF Tests

[Shane Hathaway]

Chris Withers wrote:
> Shane Hathaway wrote:
>> to slightly modify the way Zope starts up to deal with a big ZEO bug.
> 
> 
> Hmmm... why did thsi require the 'import Zope' idiom to stop working?

It sounds like you're asking for full details.  Here you go.

Python has an import lock, meaning that only one thread can import 
modules at a time.  The import lock is not released until the outermost 
import statement is finished.  Until now, "import Zope" held the import 
lock during the entire process of starting up databases.

Unpickling frequently requires use of the import mechanism.  ZEO storage 
servers use pickles to send exceptions to ZEO clients.  ZEO clients talk 
with storage servers in a thread.

Therefore, if the import lock is held during database initialization and 
a storage server attempts to send an exception to a ZEO client at 
startup, Zope deadlocks.  No thread can release the import lock.  The 
exception cannot be reported, either.

There's a good chance that many who have used ZEO has been bitten by 
this.  It especially drew our attention when we realized that Zope 
Replication Server (ZRS) no longer worked with Zope!

Changing this was absolutely vital for a current deployment.  But we 
worked double-overtime to make sure the change was backward compatible. 
  You can get the old behavior back using the environment variable 
ZOPE_COMPATIBLE_STARTUP.  Just set it and "import Zope" will behave as 
before.

It is unfortunate we didn't discover this before.  The change is 
documented in CHANGES.txt, there is a big comment in the new 
Zope/__init__.py, and the new environment variable has been tested. 
Note that it isn't really an issue for users of plain Zope nor for 
script writers, since Zope.app() now automatically starts up Zope if it 
hasn't started yet.  The only issue seems to be with unit test runners. 
  We'll get that sorted out somehow.

Shane