Not very helpful error when no DSToolkits are reachable

..... e.g. when all the Zope instances are blocked for http connections
from the Zeo server by an overzealous firewall (grrr)...  it would be
really
nice if snapshot-using scripts gave a more informative message than this:

 Traceback (most recent call last):
   File "snapshot.py", line 260, in ?
     main()
   File "snapshot.py", line 61, in main
     s.acquire()
   File "snapshot.py", line 108, in acquire
     lock_file(f)
   File "/zope/Zope-2.7.7-SoftwareHome/lib/python/ZODB/lock_file.py", line
42, in lock_file
     fcntl.flock(file.fileno(), _flags)
 IOError: [Errno 11] Resource temporarily unavailable

As it is, I spent quite a while chasing down list archives and looking
at various things we've discussed before that cause this error, none of
which were the culprit.  It wasn't until, on a hunch, I tried making
http connections to the clients using wget that I discovered the real
problem.

I've only briefly looked at the code, but as far as I can tell,
the problem lies in acquire() and process_config_file().
The comment in acquire() says:

        # At this point we are in one of four states:
        # 1. We have forced the storage into snapshot mode, closer is not
None
        #    and we can therefore certainly lock the directory
        # 2. closer is None because Zope is not running. If the storage
shutdown
        #    cleanly then we can lock the directory anyway.
        # 3. closer is None because the storage crashed. Locking will
succeed, but
        #    we will not be in a snapshot
        # 4. Something else is using the directory. Locking will fail.


I would add one more case:

        # 5. closer is None even though the storage is running,
        #    because there was some problem connecting to all
        #    of the DirectoryStorageToolkit(s) specified in
        #    config/snapshot.conf, so we were unable to put the storage
        #    into snapshot mode.
        #    Locking will fail.


But that doesn't solve the problem: if locking fails,
you have to find this comment in the source code just to guess why,
and you have no clue from the traceback whether it's case 5, case 4,
or maybe even case 2 if the storage didn't "exit cleanly".

The problem is that I don't see any way that the code can discover
which is the case.  Maybe at least part of that comment should be
rewritten as an error message with some hints on what to look at,
which could be dumped to stderr. At the very least we know that
we're not in scenario 1 or 3.

Maybe some more blather from process_config_file() would help too,
when the connection errors are caught (and currently ignored).

fyi, I'm running Zope 2.7.7, ZEO, and DirectorySTorage 1.1.9.
I had a look at current CVS but as far as I can tell it would behave
much the same way.

-PW




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf