hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject ZooKeeper Roadmap - 3.3.0 and beyond.
Date Fri, 10 Jul 2009 17:26:47 GMT
It's that time again, thinking about the next release of ZK. From what 
I'm hearing people seem interested in improving scalability, 
manageability, and continue to improve client support.

In particular I believe we should look at the following going forward. 
Of course ZooKeeper is open to submissions in that aren't on this list. 
If you have any suggestions please feel free to enter a JIRA, submit a 
patch, or comment on this thread.

3.3 (~4 months out)
   Observer support - ZOOKEEPER-368

   Allow dynamic changes to ensemble w/o requiring restart - ZOOKEEPER-107

   Move from direct NIO to framework (grizzly?)
     benefit of built-in ssl support for connections

   optimize session tracking
     no expiration of session if client has no ephemerals
     huge scalability win if we can do this (for a very common use case)

   hide connection loss from client - ZOOKEEPER-22

   optimize server
      profiling for hotspots
      replace String use with binary buffer - elim conversion overhead 
(server only)

   expand system tests
     ensure b/w compat between current and previous version
     move some unit tests into system test framework (esp large quorum 
     integrate performance/benchmark tests
   cleanup the c binding
     logging and general code cleanliness
   review jmx object naming scheme
      error handling, general cruft
   move examples out of docs into contrib/examples (like hadoop core)
     add more examples
   build changes
     ivy? push jars to maven repo?
     split jars? common, server, client, test

   horizontally partitioned zk
   support multiple client protocols/marshalling
     (hadoop rpc?)
     AVRO is in the process of it's first release
   quota support for limiting (rather than just reporting)

4.0 "API/data breakage release" (q1 2010)
   API changes
     move all "counter" fields from int -> long (version numbers for 
       requires migration of snapshots (ie persistence/marshalling will 
     pass enums to callbacks
     remove deprecated cruft
   bookeeper more tightly integrated into zk?

Feel free to respond to this email with any thoughts, suggestions, etc...



View raw message