read_only_fallback option of ClientStorage.

Unfortunately, this still doesn't work completely; as shown by some
disabled tests that I'll check in shortly, the reconnect feature is
still broken.  But it's weekend time, and I need a checkpoint to keep
my own sanity.

"ClientStorage <pid>", use "ClientStorage:<pid>".

Also log a message when a ClientStorage instance is created, showing
the pid, the read_only and read_only_fallback parameters, and the
storage name.

Also log some more things: the retry of the register() call with
read_only=1, the notifyConnected call,

Also clean up a few comments and docstrings, removing one XXX that
seems out of date.

Also change the _tpc_cond.wait() method call into a wait(30).  That
way it is interruptable.

StorageServer class, instead of "ZEO Server:<pid>", use
"StorageServer:<pid>".  In the ZEOServer class, instead of "ZEO
Server:<pid>:<name>", use "ZEOStorage:<pid>:<name>".

Also log a message when a StorageServer instance is created, showing
the pid, the read_only parameter, the storage names, and for each
storage whether it is RO (read-only) or RW (read-write).

Also clean up a few comments, removing one XXX that seems out of
date, and use %r instead of %s in some log messages.

name, cache size, and current filename (could be None).

"ZEO Server", use "ZEO/start.py".  There was one (PANIC) log message
that used "z2"; changed that one to "ZEO/start.py" as well.

repr module.

service asyncore events intended for a ClientStorage created in the
parent.  That can't be intended.  The best way I can see to avoid this
is simply to clear asyncore's socket_map after the fork.

never imported log or zLOG.

changed and the hotshot invocation wasn't changed along.  Untested.

Add a send_call() method that computes a new msgid and hands the
message off to the smac layer.  Uses __msgid_lock()

call() still uses __call_lock, but callAsync() does not.  callAsync()
does not use any lock beyond what send_call() does.

each time round the loop (with a 30 sec. timeout).

should fix the problem that messages from different processes or
threads could be intermingled.  The code was rewritten to build up the
lines of the error message in a list which is joined by "\n"
characters at the end.

values that connect_ex() may return when we're connected).  This seems
to resolve the last hangs observed on Win2K.  There are still
(unrelated) hangs on Win98 though.

read-write connection is not available.  This refactors
ClientStorage.notifyConnected() into two functions, testConnection()
and notifyConnected().  testConnection creates the RPC stub and calls
the register() method; it returns the stub plus a flag indicating
whether this connection was preferred or sub-optimal.  If the
register() method raises ReadOnlyError, and the new option
read_only_fallback was true on the ClientStorage constructor, it is
retried with its read_only argument set to 1, and the stub is returned
with the sub-optimal flag.  notifyConnected() now receives the stub
returned by testConnection(), and starts the verification as before.

XXX The read_only_fallback  feature is not yet tested.

XXX More work is needed; when a suboptimal connection is used, the
ConnectThread must stay around trying to get a preferred connection,
and then it must switch connections on the ClientStorage (how???).

different classes that both define a register() method, with different
signatures.  Rename StorageServer.register() to
register_connection().  Also rename its newConnection() method to
new_connection(), for naming consistency.

more understandable.

Got rid of the Connected() exception -- connect(), now renamed to
try_connect(), returns a 1/0 result instead of raising Connected() to
indicate success.

in reST.  I'm not going to figure out how to turn this into a reST
table.

the client.

Also, simplify the test for exceptions received by the client.  If the
class is a subclass of Exception, there's no need to ask if the
instance is of type ClassType.

Increase the timeout from 10 to 30 seconds and add a message to the
failIf() call.

lock.  The lock is now never held for a long time, only while
self.thread is being assigned or inspected, and while a thread is
being created, started or stopped.  Waiting for an event or joining a
thread is now done without holding the lock.  There is no longer a
fear of AttributeError.

When a thread join doesn't succeed within 30 seconds, a message is
logged, and depending on the situation, the join is retried.

The old code would avoid hosing the system when the first jar failed
during its finish.  The logic is that the failure means that
transaction did not commit, so it was safe for all the other jars to
abort.  There are counter-examples to this assumption.  For example,
ZEO could fail after commiting the transaction on the server but
before communicating that success to the client.  It would lead to
inconsistency if the other jars aborted after the first committed.

The solution is to reduce the special case yet further:  If a
single-jar transaction fails during the finish, assume the transaction
is aborted and avoid hosage.  If the jar actually committed, it's
possible to get back to a consistent state since only one jar was
involved.