[Zope-ZEO] ZEO-0.2

[Jim Fulton]

Greg Ward wrote:
> 
> On 10 May 2000, Jim Fulton said:
> > Here's a tar ball for ZEO 0.2.
> >
> > After extracting it, see ZEO-0.2/ZEO/README
> > and ZEO-0.2/ZEO/CHANGES.txt.
> 
> OK, I've got it working if working means "the server is running".
> 
> A couple problems so far.  First, two minor annoyances that I didn't
> bother to complain about with ZEO 0.1, but are still present:

Obviously, you can't expect me to have fixed something you didn't
complain about. :)

>   * no "stop" script -- if it's as simple as
>     putting the Python equivalent of "kill `cat var/ZEO_SERVER.pid`" in

Yes.

>     "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.
 
>   * 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.
 
> New problems:
>   * keyword arg "datadir" in ClientStorage constructor changed to "var",
>     which means I had to hack in a dependency on
>     ClientStorage.__version__ where we call this.  Yucky, but this is
>     only at one spot in the code, and it'll go away when we don't care
>     about ZEO 0.1 anymore.  I suppose API upheaval is to be expected
>     with version numbers < 1.0, but I'll grumble all the same!

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.
 
>   * and now one that looks like a real bug: I run one of my test client
>     scripts, and it dies almost immediately with this (elided)
>     traceback:
>       [...]
>       File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 163, in _initialize_zeo
>         self._initialize_zodb( extra_info, storage = client_storage)
>       File "/home/gward/lib/python/mxtoy/virtual_fab.py", line 149, in _initialize_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 149, in connect
>         self.aq_parent.notifyConnected(s)
>       File "/www/zope/Zope-2.2cvs/lib/python/ZEO/ClientStorage.py", line 159, in notifyConnected
>         self._call.finishConnect(s)
>       File "/www/zope/Zope-2.2cvs/lib/python/ZEO/zrpc.py", line 153, in finishConnect
>         SizedMessageAsyncConnection.__init__(self, s, {})
>       File "/www/zope/Zope-2.2cvs/lib/python/ZEO/smac.py", line 100, in __init__
>         SizedMessageAsyncConnection.inheritedAttribute(
>     TypeError: too many arguments; expected 2, got 3
> 
>     (Sorry for the wide lines, but that's life with tracebacks.)
> 
>     Anyways, to my ignorant eye it looks as though the traceback tells
>     the truth: the SizedMessageAsyncConnection constructor starts off
>     like this (line 100-101 of ZEO/smac.py):
>         SizedMessageAsyncConnection.inheritedAttribute(
>             '__init__')(self, sock, map)
> 
>     Based on the superclasses of SizedMessageAsyncConnection, I assume
>     this will call asyncore's constructor.  But asyncore, at least in
>     the Python 1.5.2 and current CVS library, has a constructor like
>     this:
>         def __init__ (self, sock=None):
> 
>     ...ie. no 'map' parameter there!
> 
>     A-ha!  I see -- smac.py does "import asyncore", when it should
>     probably do "from ZServer.medusa import asyncore", since I see
>     an asyncore.py with a 3-argument constructor in ZServer/medusa.
> 
>     Looks like a bunch of other modules in ZEO 0.2 also "import
>     asyncore", which means they will get the standard library version.
>     Jim, is my interpretation correct?  If so, I'll submit a patch
>     straightaway.

This is discussed in the README, although the README file 
left out a step. It should have told non-Zope users to import 
ZServer before importing ZEO.  I've made some changes to asyncore to
accept optional socket map arguments. This change was accepted
by Sam. I don't know if he has sent the change to python.org.

I modified ZEO to use ZServer's asyncore, but then undid the
modification once Sam agreed to the change. Importing ZServer is
a hack to get around this problem for now. When ZServer is imported
it installs it's asyncore in sys.modules.

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.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.