tim.peters at gmail
May 15, 2005, 10:52 AM
Post #8 of 11
[.Andreas Jung, wonders about the seemingly consistent
failure of the ZEO checkCrossDBInvalidations test on
Stefan's box, but only using Python 2.3.5 on Zope trunk]
[Stefan H. Holek]
> This test passes with Python 2.4.1 on that (Linux)
Except there's no conceivable reason for why that could make a
difference ...except perhaps that 2.3.5 is just slower here.
> box and it passes fine with both 2.3.5 and 2.4.1 on
> Mac OS X.
Also passes under all Pythons on Windows.
> Also, when I run the ZEO tests alone:
> python2.3 test.py --dir lib/python/ZEO they pass as well.
> The box I use to run the nightly tests is rather sluggish, so it
> may just be an artefact of that (like other test failures have
> turned out to be).
That's my guess. The test is in ZEO/tests/ConnectionTests.py. It
would help if you tried editing a local copy of that, changing
for i in range(10):
for i in range(1000):
At this point in the test, it's waiting for a separate ZEO process to
receive a database invalidation message. With "10" in the loop, it
waits no longer than a second. While that's an eternity of clock
cycles on modern boxes, vagaries of OS process scheduling could make
it take longer. It will break out of the loop as soon as the
invalidation it's expecting arrives, so boosting the loop trip count
doesn't make the test slower, it just makes it willing to wait longer.
OK, this test changed recently: it's not just waiting for the
invalidation to arrive, it's also waiting for the the client to
process the invalidation, ghostifying its copy of the root object as a
result. So it can take longer now than it used to take.
> Do you have a Linux box you could confirm the failure on?
Since it passes in isolation for you, MHz probably isn't the only contributor.
Zope-Coders mailing list
Zope-Coders [at] zope