Jim Fulton wrote:

I'll note that I have been able to provoke the error message, but, for me at least, the result was non-fatal. The error occurs during cache verification and causes the connection to fail. The connection thread keeps running and tries again.

Okay, with the proviso that it's been a couple of months since I last
had to deal with this, that fits what I remember, except the retrying
always used to fail, so I'll just get a large number of the same error
in the event log.

The error, as provoked by me, arises from a race condition in a situation in which one client is connecting while other clients are writing. Unless other clients are writing furiously, I don't see why this would prevent a client from connecting eventually. This makes me wonder if, perhaps, I'm not seeing the same error that you are reporting. OTOH, I haven't been able to think of another situation in which this symptom could occur.

Hmmm, well, the setup here is that one client is used for pumping data
into a ZODB, while the other is used mainly for reads but does some
writing (code modification to page templates, etc) That said, I don't know what the setups of the other people experiencing this error were...

If you are seeing this error a lot, I suggest setting invalidation-queue-size to 1 on your storage server (and restarting of course). It would be interesting to know if this setting makes the error go away.

The trouble is that it's a hard to reproduce error ;-)
Disabling persistent client caching was the big-hammer approach. I'll
try turning that back on for one of the dev servers and seeing if I can
reproduce, when I can, I'll try dropping the queue size to one as you



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to