Hi Rich, the version string looks useful to have, thanks! Would you mind submitting this via jira? Do a "svn diff" (looks like you did already), create a jira and attach the diff, then click "submit" link on the jira. We'll review and work on getting it into a future release.



On 07/15/2010 05:24 PM, Rich Schumacher wrote:
Hey Henry,

Good to know!  I was under the impression the 3.3.0 release had the updated 
bindings but it seems I was mistaken.  I'll get those built and then see what 
happens.  Just curious, have you ever run into or heard of this?  A quick 
Google search didn't return anything interesting.

As for the version in the Python bindings, how about this trivial patch:

Index: src/c/zookeeper.c
--- src/c/zookeeper.c   (revision 964617)
+++ src/c/zookeeper.c   (working copy)
@@ -1510,6 +1510,11 @@
    PyModule_AddObject(module, "ZooKeeperException", ZooKeeperException);

+  char version_str[];
+  sprintf(version_str, "%i.%i.%i", ZOO_MAJOR_VERSION, ZOO_MINOR_VERSION, 
+  PyModule_AddStringConstant(module, "__version__", version_str);

On Jul 14, 2010, at 2:57 PM, Henry Robinson wrote:

Hi Rich -

No, there's not a very easy way to verify the Python bindings version afaik
- would be a useful feature to have though.

My first suggestion is to move to the bindings shipped with 3.3.1 - we fixed
a lot of problems with the Python bindings which improved their stability a
lot. Could you try that and then let us know if you continue to see


On 14 July 2010 13:14, Rich Schumacher<rich.s...@gmail.com>  wrote:

I'm running a Tornado webserver and using ZooKeeper to store some metadata
and occasionally the ZooKeeper connection will error out irrevocably.  Any
subsequent calls to ZooKeeper from this process will result in a

Here is the relevant portion of the Python traceback:
File "/usr/lib/pymodules/python2.5/zuul/storage/zoo.py", line 69, in call
   return getattr(zookeeper, name)(self.handle, *args)
SystemError: NULL result without error in PyObject_Call

I found this in the ZooKeeper server logs:

2010-07-13 06:52:46,488 - INFO  [NIOServerCxn.Factory:$fact...@251] - Accepted socket
connection from /
2010-07-13 06:52:46,489 - INFO  [NIOServerCxn.Factory:] - Client attempting to renew
session 0x429b865a6270003 at /
2010-07-13 06:52:46,489 - INFO  [NIOServerCxn.Factory:] - Revalidating client: 299973596915630083
2010-07-13 06:52:46,793 - INFO
[QuorumPeer:/0:0:0:0:0:0:0:0:2181:nioserverc...@1424] - Invalid session
0x429b865a6270003 for client /, probably expired
2010-07-13 06:52:46,794 - INFO  [NIOServerCxn.Factory:] - Closed socket connection for
client / which had sessionid 0x429b865a6270003

The ZooKeeper ensemble is healthy; each node responds as expected to the
four letter word commands and a simple restart of the Tornado processes
"fixes" this.

My question is, if this really is due to session expiration why is a
SessionExpiredException not raised?  Another question, is there an easy way
to determine the version of the ZooKeeper Python bindings I'm using?  I
built the 3.3.0 bindings but I just want to be able to verify that.

Thanks for the help,


Henry Robinson
Software Engineer

Reply via email to