Re: Errors with Python bindings
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. http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute Thanks! Patrick 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); Py_INCREF(ZooKeeperException); + char version_str[]; + sprintf(version_str, %i.%i.%i, ZOO_MAJOR_VERSION, ZOO_MINOR_VERSION, ZOO_PATCH_VERSION); + + PyModule_AddStringConstant(module, __version__, version_str); + ADD_INTCONSTANT(PERM_READ); ADD_INTCONSTANT(PERM_WRITE); ADD_INTCONSTANT(PERM_CREATE); 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 problems? cheers, Henry On 14 July 2010 13:14, Rich Schumacherrich.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 SystemError. Here is the relevant portion of the Python traceback: snip... 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: 0.0.0.0/0.0.0.0:2181:nioservercnxn$fact...@251] - Accepted socket connection from /10.2.128.233:54779 2010-07-13 06:52:46,489 - INFO [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:nioserverc...@742] - Client attempting to renew session 0x429b865a6270003 at /10.2.128.233:54779 2010-07-13 06:52:46,489 - INFO [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:lear...@95] - 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 /10.2.128.233:54779, probably expired 2010-07-13 06:52:46,794 - INFO [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:nioserverc...@1286] - Closed socket connection for client /10.2.128.233:54779 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, Rich -- Henry Robinson Software Engineer Cloudera 415-994-6679
Re: Errors with Python bindings
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); Py_INCREF(ZooKeeperException); + char version_str[]; + sprintf(version_str, %i.%i.%i, ZOO_MAJOR_VERSION, ZOO_MINOR_VERSION, ZOO_PATCH_VERSION); + + PyModule_AddStringConstant(module, __version__, version_str); + ADD_INTCONSTANT(PERM_READ); ADD_INTCONSTANT(PERM_WRITE); ADD_INTCONSTANT(PERM_CREATE); 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 problems? cheers, Henry 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 SystemError. Here is the relevant portion of the Python traceback: snip... 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: 0.0.0.0/0.0.0.0:2181:nioservercnxn$fact...@251] - Accepted socket connection from /10.2.128.233:54779 2010-07-13 06:52:46,489 - INFO [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:nioserverc...@742] - Client attempting to renew session 0x429b865a6270003 at /10.2.128.233:54779 2010-07-13 06:52:46,489 - INFO [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:lear...@95] - 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 /10.2.128.233:54779, probably expired 2010-07-13 06:52:46,794 - INFO [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:nioserverc...@1286] - Closed socket connection for client /10.2.128.233:54779 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, Rich -- Henry Robinson Software Engineer Cloudera 415-994-6679
Errors with Python bindings
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 SystemError. Here is the relevant portion of the Python traceback: snip... 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:0.0.0.0/0.0.0.0:2181:nioservercnxn$fact...@251] - Accepted socket connection from /10.2.128.233:54779 2010-07-13 06:52:46,489 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:nioserverc...@742] - Client attempting to renew session 0x429b865a6270003 at /10.2.128.233:54779 2010-07-13 06:52:46,489 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:lear...@95] - 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 /10.2.128.233:54779, probably expired 2010-07-13 06:52:46,794 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:nioserverc...@1286] - Closed socket connection for client /10.2.128.233:54779 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, Rich
