Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> PartitionData


Copy link to this message
-
Re: PartitionData
Yes - something along those lines. We can either do it in a separate jira
or as part of KAFKA-391 since I'm already touching that code.

Thanks,

Joel

On Wed, Sep 12, 2012 at 9:59 AM, Joe Stein <[EMAIL PROTECTED]> wrote:

> do want to create a ProducerRequestData and FetchResponseData?
>
> i'll open a ticket
>
> On Wed, Sep 12, 2012 at 12:40 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:
>
> > That's a good point. I did notice that while working on KAFKA-391. The
> idea
> > behind it must have been that both producer and fetch requests deal with
> > actual partition data. However, the hw and error code don't make sense on
> > the request side. I can include this change as part of KAFKA-391 if that
> > makes sense.
> >
> > Joel
> >
> > On Wed, Sep 12, 2012 at 9:32 AM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> >
> > > Hey Guys,
> > >
> > > The request format in 0.8 has drifted a bit from the proposal (
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/New+Wire+Format+Proposal
> > > ).
> > > A lot of this was new fields that were needed. But some oddities have
> > > slipped in.
> > >
> > > For example we are reusing PartitionData.scala in both the produce
> > request
> > > and the fetch response. This seems like clever code reuse, but in
> reality
> > > it changes the protocol to add a bunch of non-sensical fields into the
> > > request format. For example in a request one now has to specify a error
> > > code, and initial offset, and a high water mark!
> > >
> > > Is this intentional? I recommend we change this before the release.
> > > Thoughts?
> > >
> > > -Jay
> > >
> >
>
>
>
> --
>
> /*
> Joe Stein
> http://www.linkedin.com/in/charmalloc
> Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop>
> */
>