[Sidnei da Silva] > We have a couple custom applications that use of zeo or just zrpc that > would need a different connect strategy than what's provided as default. > > To be more specific, we need a way to try a connection and either connect > or fail immediately with a reasonably short timeout and if possible a > useful error message.
There must be close to 1000 lines of code involved in making & maintaining ZEO connections, and I can't pretend I understand it all, but to the extent that I do I don't believe there's any code supporting what you want (neither failing immediately, nor useful error messages -- although I'm not sure what the latter means). > I have tried to understand the woes involved in establishing a zeo/zrpc > connection and what comes closer to what we want to implement is > providing the 'wait' argument to ClientStorage, The `wait` argument is a true/false flag, controlling whether the constructor returns before cache validation completes. Although the default value is None, None acts like true here. That doesn't sound like it's relevant to what you're after. If you pass a false (except for None(!)) value to 'wait', I'm not sure what it does (I got lost trying to follow all the possible code paths then), but I'd be surprised if it ever gave up. At least ConnectThread.run() loops until connection succeeds (or the thread's .stop() method is called). > but even then it would at least fire off a thread and retry a number > of times (forever?) before giving up the connection attempt. I expect it's forever, although I'm not sure. > Any suggestions about how to best implement this, Maybe just create your own socket, attempt to connect, and if that attempt fails produce the kind of error message you want to see? Of course if it succeeds, there's some chance it will fail if you immediately close the socket and do a "normal" connection attempt. > and would such code be accepted for inclusion in a latter version > of ZEO? I'd be reluctant to complicate this code more. The chances would be higher if you snuck new features into a rewrite that substantially simplified this area (offhand I can't believe the code needs to be this complicated -- which is kind of a chicken-&-egg thing: because it's complicated and "underdocumented" it's hard to say exactly what it does, so also hard to say whether it needs to be so complicated ...). _______________________________________________ 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
