Re: zkPython version compatibility
On 11 June 2010 13:44, Lei Zhang wrote: > We've been using zkpython with python2.4 for a couple of weeks, banged our > stability test suite on it in 8-node cluster setting. So far so good. > > However, I wouldn't say zkpython 3.3.1 is "much" improved. The SIGABRT, > segfault, hang issues we used to run into with 3.2.1 now show up as > exit(1). > Sorry to hear that - can you open JIRAs with reproducible test cases? We'll be glad to try and fix the problems you're having. Henry -- Henry Robinson Software Engineer Cloudera 415-994-6679
Re: zkPython version compatibility
We've been using zkpython with python2.4 for a couple of weeks, banged our stability test suite on it in 8-node cluster setting. So far so good. However, I wouldn't say zkpython 3.3.1 is "much" improved. The SIGABRT, segfault, hang issues we used to run into with 3.2.1 now show up as exit(1).
Re: zkPython version compatibility
Hi Daniel - It's more of the latter, if I recall correctly. Digging turned up this: https://issues.apache.org/jira/browse/ZOOKEEPER-579where one of the tests fails in an python < 2.6 (but fails due to a testing framework incompatibility I think!), and the README was, perhaps conservatively, updated to say that only 2.6 is tested. I haven't personally tested a recent zkpython against <2.6, but I am hopeful that 2.5 will work correctly. I'd encourage you to try it! The zkpython in 3.3.1 is much improved over earlier versions, so it's worth the upgrade. cheers, Henry On 11 June 2010 12:07, Daniel Thumim wrote: > Hello, > > While upgrading to the 3.3.1 release, I noticed that zkPython > now has a stated dependency on python 2.6. I have been using > it with python 2.5 until now and expected to continue that for > at least a few more months. Is the 2.6 dependency for real, > or is it just that the maintainer isn't testing older versions > any more and thus is unsure? > > Thanks, > > -- |)aniel Thumim > > -- Henry Robinson Software Engineer Cloudera 415-994-6679
zkPython version compatibility
Hello, While upgrading to the 3.3.1 release, I noticed that zkPython now has a stated dependency on python 2.6. I have been using it with python 2.5 until now and expected to continue that for at least a few more months. Is the 2.6 dependency for real, or is it just that the maintainer isn't testing older versions any more and thus is unsure? Thanks, -- |)aniel Thumim
Re: Debugging help for SessionExpiredException
Session expiration is due to the server not hearing heartbeats from the client. So either the client is partitioned from the server, or the client is not sending heartbeats for some reason, typically this is due to the client JVM gc'ing or swapping. Patrick On 06/10/2010 04:14 PM, Ted Dunning wrote: Uh the options I was recommending were for your CLIENT. You should have similar settings on ZK, but it is your client that is likely to be pausing. On Thu, Jun 10, 2010 at 4:08 PM, Jordan Zimmerman wrote: The thing is, this is a test instance (on AWS/EC2) that isn't getting a lot of traffic. i.e. 1 zookeeper instance that we're testing with. On Jun 10, 2010, at 4:06 PM, Ted Dunning wrote: Possibly. I have seen GC times of> 4 minutes on some large processes. Better to set the GC parameters so you don't get long pauses. On http://wiki.apache.org/hadoop/ZooKeeper/Troubleshooting it mentions using the "-XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC" options. I recommend adding -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+DisableExplicitGC You may want to tune the actual parameters of the GC itself. These should not be used in general, but might be helpful for certain kinds of servers: -XX:MaxTenuringThreshold=6 -XX:SurvivorRatio=6 -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly Finally, you should always add options for lots of GC diagnostics: -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution On Thu, Jun 10, 2010 at 3:49 PM, Jordan Zimmerman< jzimmer...@proofpoint.com wrote: If I set my session timeout very high (1 minute) this shouldn't happen, right?
