[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

Reply via email to