On Oct 10, 2008, at 5:14 AM, Christophe Combelles wrote:
> Christophe Combelles a écrit :
>>>>> It is probably worth testing it in the full KGS test suite, to
>>>>> see if it
>>>>> can be part of zope 3.4.0 final?
>>>> Sure. Maybe someone can do that with the next beta (9).
>>> I've run the tests on my box, then upgraded the KGS (along with
>>> setuptools). We
>>> will see if the buildbot is still ok.
>> It's not
>> There is a new failure on ZEO/tests/
>> An there is a problem with file locking on the 64bit slaves with:
> The tests pass if they are run alone : http://zope3.pov.lt/buildbot/
> It would be good to fix these concurrency problems
Yeah. ZEO and ZODB (maybe just ZEO) tests are often sloppy about the
files they create. I recently modified the buildout to create
temporary files in the test part directory, which should have helped.
One of my near future projects will be to try to address this problem.
Of course, the ZEO tests are also very timing sensitive, so running
them simultaneously is still likely to increase the chance of
intermittent failures. In the long term, I plan to re-implement ZEO
on top of zc.ngi, and, at that point, many of the tests won't be so
timing sensitive because they won't need to create real sockets and
> There is another such problem with tests described here:
> I've found a workaround in zope.server tests to avoid the problem in
> the KGS,
> but the real problem comes from ZEO tests and could arise again in
> the future.
This feels like different problem to me. The long term solution is
for ZEO to use it's own socket map. A shorter term fix would be for
the ZEO tests to snapshot and empty the socket map in setUp and
restore it in tear down.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org