Hey Harsha, We're just trying to understand the problem first. I think what you're saying is that the KafkaSpout has been compiled against the 0.9 client, but it may need to be to run against 0.10 (if the user depends on that version instead). Is that correct? In general, are you expecting that KafkaSpout will work with any kafka-clients greater than 0.9? Another question that comes to mind is whether we would also need to revert to the old versions of subscribe() and assign(). The argument type was changed from List to Collection, which is not binary compatible, right?
Thanks, Jason On Thu, Apr 28, 2016 at 1:41 PM, Harsha <ka...@harsha.io> wrote: > Hi Ismael, > This will solve both binary and source compatibility. > Storm has new KafkaSpout that used 0.9.x new KafkaSpout > API. As part of that spout we used > KafkaConsumer.seekToBeginning and other methods. Since the > method signature changed as part of KIP-45. If we update > the version to 0.10 we are breaking the KafkaConsumer > calls in our Storm spout. In storm's case we ask users to > create uber jar with all the required dependencies and > users can free to use which version of kafka they can to > be part of uber jar. If they use storm 1.0 release version > of storm-kafka with kafka 0.10 than it will create issues > without the patch. > I am still not getting clear answer here. Whats exactly the > issue in having these methods with deprecated tag? we keep > the interface as it is. > > Thanks, > Harsha > > On Thu, Apr 28, 2016, at 01:27 PM, Ismael Juma wrote: > > Hi Harsha, > > > > What is the aim of the PR, is it to fix binary compatibility, source > > compatibility or both? I think it only fixes source compatibility, so I > > am > > interested in what testing has been done to ensure that this fix solves > > the > > Storm issue. > > > > Thanks, > > Ismael > > > > On Thu, Apr 28, 2016 at 12:58 PM, Harsha <ka...@harsha.io> wrote: > > > > > Hi, > > > We missed this vote earlier and realized thats its breaking the > > > 0.9.x client api compatibility. I opened a JIRA here > > > https://issues.apache.org/jira/browse/KAFKA-3633 . Can we keep > > > the old methods with deprecated tag in 0.10 release. > > > > > > Thanks, > > > Harsha > > > > > > On Fri, Mar 18, 2016, at 01:51 PM, Jason Gustafson wrote: > > > > Looks like the KIP has passed. The finally tally is +5 among > committers > > > > and > > > > +9 overall. > > > > > > > > Thanks to Pierre-Yves Ritschard for all of the hard work and > persistence > > > > with this! > > > > > > > > -Jason > > > > > > > > On Wed, Mar 16, 2016 at 9:01 PM, Ewen Cheslack-Postava > > > > <e...@confluent.io> > > > > wrote: > > > > > > > > > +1. > > > > > > > > > > Normally I'd be more of a stickler for compatibility, but this is > new, > > > I > > > > > think it's worth emphasizing that unstable actually means unstable > & > > > might > > > > > require recompile (and maybe even adapting code when we think the > > > change > > > > > warrants it), and I think the impact is relatively low since those > > > adopting > > > > > the new consumer know that it's very new. Agreed with Guozhang that > > > better > > > > > documenting the annotations will help (and personally apologize for > > > that > > > > > since we hastily introduced the annotations to give ourselves > wiggle > > > room > > > > > on Connect). > > > > > > > > > > -Ewen > > > > > > > > > > On Wed, Mar 16, 2016 at 5:17 PM, Joel Koshy <jjkosh...@gmail.com> > > > wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > On Tue, Mar 15, 2016 at 2:18 PM, Jason Gustafson < > ja...@confluent.io > > > > > > > > > > wrote: > > > > > > > > > > > > > I'd like to open the vote for KIP-45. We've discussed several > > > > > > alternatives > > > > > > > on the mailing list and in the KIP call, but this vote is only > on > > > the > > > > > > > documented KIP: > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61337336. > > > > > > > This > > > > > > > change will not be compatible with 0.9, but it will provide a > > > cleaner > > > > > API > > > > > > > long term for users to work with. This is really the last > chance to > > > > > make > > > > > > an > > > > > > > incompatible change like this with 0.10 shortly on the way, but > > > > > > compatible > > > > > > > options (such as method overloading) could be brought up again > in > > > the > > > > > > > future if we find it's needed. > > > > > > > > > > > > > > Thanks, > > > > > > > Jason > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Thanks, > > > > > Ewen > > > > > > > > >
