Hi all I have sent an email to zodb-dev about this but I thought I'd see if people here could shed some light on the issue as well. This time I will state the issue form a more Zope-client perspective. Basically after an arbitrary amount of time I start getting these errors in the Zope client event logs: 2012-10-24T15:33:38 INFO ZEO.ClientStorage storage_c14_zeostorage Testing connection <ManagedClientConnection ('10.221.0.89', 8101)> ------ 2012-10-24T15:33:48 ERROR ZEO.zrpc (1021) CW: error in testConnection (('10.221.0.89', 8101)) Traceback (most recent call last): File "/opt/informa/buildout-cache/eggs/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZEO/zrpc/client.py", line 595, in test_connection self.preferred = self.client.testConnection(self.conn) File "/opt/informa/buildout-cache/eggs/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZEO/ClientStorage.py", line 565, in testConnection stub = self.StorageServerStubClass(conn) File "/opt/informa/buildout-cache/eggs/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZEO/ServerStub.py", line 386, in stub raise ValueError("Timeout waiting for protocol handshake") ValueError: Timeout waiting for protocol handshake ------ I understand that it is possibly Zeo not providing a timely response but I'm just wondering under what circumstances does the Zope client need to keep testing the connection? It was my understanding that it connects to Zeo and then it's connected? Even when the client reports these errors it is still responding to web requests fine. It has the knock-on effect that the zeoserver starts consuming more file descriptors every time these connection attempts occur. There is a theoretical maximum number of file descriptors that can be used so if the trend continues then eventually Zeo will start failing to respond to queries. This is not ideal as the system should be able to run unattended indefinitely (normal housekeeping operations aside). Any ideas? Tim -- Tim Godfrey Obsidian Consulting Group P: +61 3 9355 7844 F: +61 3 9350 4097 E: tim@obsidian.com.au W: http://www.obsidian.com.au/