Joe, Thanks for getting this started. See my comments in the jira on maintaining backward compatibility. My preference is to make 0.8 a non-backward compatible release, but provide a tool to continuously mirror data between an 0.7 cluster and an 0.8 cluster for migration.
Regarding the class name for the request. I am ok either way. Thanks, Jun On Tue, Jan 10, 2012 at 7:54 PM, Joe Stein <crypt...@gmail.com> wrote: > I put together my thoughts related to my JIRA comment in Kafka-240 with the > entry point to my thinking in regards to changing ProducerRequest with the > new wire protocol > > https://gist.github.com/1592895 > > Thoughts? Comments? Tomatoes? > > Let me know > > basically from here (besides making sure existing code works correctly) is > to implement the 2 TODO places in my gist down in the layers > > so the underlying would use a new class called api.WiredProducerRequest > which would implement the new protocol from > https://cwiki.apache.org/confluence/display/KAFKA/New+Wire+Format+Proposal > > I could either > > 1) do like in my gist says to use the old api.ProducerRequest for legacy > and new data new class > > or > > 2) only use a new api.WiredProducerRequest and push the old data in like I > did in my gist > > > and the equals would check values based on "version" (assuming version = 0 > means <= 0.7 and we make the first wire for 0.8 version = 1) > > > /* > Joe Stein > http://www.linkedin.com/in/charmalloc > Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> > */ >
