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
suggest...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
