FYI. I have attached a sample clients API change/compatibility report to
KAFKA-1880 <https://issues.apache.org/jira/browse/KAFKA-1880>. The report
shows changes in the public apis between the 0.9 and trunk branches. Some
of them are expected per KIP-45 obviously.

Thanks,
Grant


On Thu, Apr 28, 2016 at 6:33 PM, Jason Gustafson <ja...@confluent.io> wrote:

> 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
> > > > > >
> > > >
> >
>



-- 
Grant Henke
Software Engineer | Cloudera
gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke

Reply via email to