any reason to reraise this.  all we really care about is that we were
able to connect. This was causing spurious errors during tear down.

(Thanks to Patrick Strawderman for spotting a name error here.)

(Thanks to Patrick Strawderman for pointing these out and providing
initial fixes.)

(Thanks to Patrick Strawderman for pointing this out and providing an
initial fix.)

whenever the cache is stale. This is generated before dropping a cache
and starting cold so that an application can take more drastic
measures. The stale-cache event also now has a storage attribute with
the storage that has a stale cache.

cache or the client storage in a valid state.

Also, changed the drop-cache feature to:

- Log a critical message and to
- Publish an event.  Some applications might want to captre the event
  and exit the process or take some drastic action when the cahe needs
  to be dropped.

all but the standard file descriptors.  This fixed a really hard to
debug test failure. (A server started after a client storage was
started had the client storage's cache loc file open, preventing the
client storage from being reopened.)

For starting servers, the storage config not defaults to a simple
file-storage configuration.

Use a simple log file configuration for the storage server rather than
trying to somehow copy the useless test log configuration. This makes
it far more likely that there will be a sever log available when
debugging test failures.

- Include the storage name in all log messages

- Use the standard logging APIs directly, rather than going through an
  intermediate function.

(The storage is also available as "_storage" for backward
compatibility, mainly for test code.)

cleaned up on disconnect.

Also avoid unnecessary iterator_gc calls to the server when there are
no iterators to be cleaned up.

doctests and for wating for a client to disconnect or connect.

when there is just one storage.

running layers in separate parallel processes.

runner doesn't call layer teardown when a layer is run as a
subprocess.  This seems insane, ...

requires passing a test object.

With this, it appears that I can run tests in parallel without getting
extra spurious errors.

Maybe this will reduce the chance if spurious test failures due to
addresses already in use.  Unfortunately, there's still a race that
may make running tests in parallel impractical until it's addressed.

ability to run layers in parallel.  This reduces test run time my more
than 75% for me.

leaving a thread behind.

an allocated block so that the first free block is right after the
last allocated block so that, on restart, we always continue writing
after the last written block.

size of an existing cache file.)

This means that cache files created by ZODB 3.8 can be read.

using ZEO Client Storages.  Just call ZEO.DB with the same arguments
you would otherwise pass to ZEO.ClientStorage.ClientStorage::

import ZEO
  db = ZEO.DB(('some_host', 8200))

to avoid unnecessary calls to the persistent_id hook for objects that
we know can't be persistent.