[Zope-ZEO] ZEO-0.2

[Greg Ward]

On 10 May 2000, Jim Fulton said:
> >     "stop.py" then I'd be happy to contribute that
> 
> We have this and will include it in future revs.
> 
> I might have spent more time on this, but you were pretty
> anxious to get the code.

Yes, we were -- you chose right.  Getting the stop script in the next
version will be fine.

> >   * if a client dies while its connection is open, the server spews
> >     a lengthy error message to its stderr, even though it has
> >     supposedly "gone daemonic" (I have not set the logging environment
> >     variable, so I assume this is a "feature")
> 
> Are you running start.py with -D? I don't see any spew to standard
> error when I don't use the -D switch. If I do use -D, I don't
> get daemon behavior either.

Oops -- my mistake.  The ZEO 0.1 server behaved this way, but I can't
reproduce it in 0.2.  The 0.2 server appears to be quite unperturbed by
clients dying horribly (ie. when I hit Ctrl-C on them): whether run
daemonically or with -D, I get not a peep out of the server when a
client crashes, which seems OK to me.  (A "connection lost" message in
the log might be useful, though.)

I have seen some weird, non-reproducible behaviour in crashing clients,
though.  ("Crash" means hit by an unexpected Python exception, always
KeyboardInterrupt in this case.)  Occasionally -- well, only once so far
-- hitting Ctrl-C has resulted in a very confusing death.  Here's a
notable example, directly cut 'n pasted from my xterm (I believe the ^C
is put there by the kernel terminal driver, right before it signals the
user process, which in turn becomes a KeyboardInterrupt exception):

  Committing...^CUnhandled exception in thread:
  Traceback (innermost last):
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 150, in connect
      self.aq_parent.notifyConnected(s)
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 166, in notifyConnected
      self._info.update(self._call('get_info'))
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 188, in __call__
      c=r[:1]
  TypeError: unsliceable object
  Unhandled exception in thread:
  Traceback (innermost last):
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 150, in connect
      self.aq_parent.notifyConnected(s)
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 166, in notifyConnected
      self._info.update(self._call('get_info'))
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 191, in __call__
      return loads(r[1:])
  SystemError: Failed to import class append from module __main__
  Unhandled exception in thread:
  Traceback (innermost last):

That's the whole thing, and yes, it really does end with the "Traceback
(innermost last):" line.  Very odd.

Another strange client crash: immediately after the above crash, where
Ctrl-C resulted in a very confusing not-quite-traceback, I re-ran the client
script in question.  I am pretty sure that I didn't have a chance to hit
Ctrl-C; certainly "^C" does not appear in my xterm -- rather, the
client-side initialization code crashed very strangely; here's the
entire traceback:

  Traceback (innermost last):
    File "./populate_users.py", line 18, in ?
      from mxtoy import virtual_fab, util
    File "/home/gward/lib/python/mxtoy/__init__.py", line 59, in ?
      virtual_fab.init ()
    File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 279, in init
      _virtual_fab = apply (_VirtualFab, (database,), extra_info)
    File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 90, in __init__
      self._init_zeo (extra_info)
    File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 174, in _init_zeo
      self._init_zodb(extra_info)
    File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 150, in _init_zodb
      self.db = DB (storage)
    File "/export/www/zope/Zope-2.2cvs/lib/python/ZODB/DB.py", line 125, in __init__
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 224, in registerDB
      self._startup()
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 145, in _startup
      if not self._call.connect():
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 150, in connect
      self.aq_parent.notifyConnected(s)
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 166, in notifyConnected
      self._info.update(self._call('get_info'))
    File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 191, in __call__
      return loads(r[1:])
  SystemError: Failed to import class append from module __main__

That strikes me as a damned strange error message to get out of Python.

Both of these bizarre client-side crashes are non-reproducible;
when I ran the client script a third time, it worked fine.  Now it runs
to completion, or dies appropriately with a KeyboardInterrupt traceback
if I hit Ctrl-C.  Odd.

> The datadir arg was your addition. I added a feature that I thought
> you wanted. I didn't remember (and forgot to check) the name that 
> you has used.

Oops. I'll go beat Andrew up about that.  Or live with it.


> This is discussed in the README, although the README file 
> left out a step.

Yep, I made the symlink...

> It should have told non-Zope users to import 
> ZServer before importing ZEO.

...but of course I didn't know about this.

> Actually, for now, I think it would be a reasonable compromise to
> have ZEO's __init__.py try to import ZServer.  I'll make it so for 
> the next release and I suggest you do this in your copy as well.

That sounds like a good solution.  I'll roll back my patch and do this
instead.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367