Mailing-List: contact kafka-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kafka-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jjkoshy.w@gmail.com
 designates 209.85.210.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOeJiJjrENbH3NZbZYJ34qurwMyVOLxkZRgdcQyQGEiFxo88ww@mail.gmail.com>
References: 
 <CAOeJiJjrENbH3NZbZYJ34qurwMyVOLxkZRgdcQyQGEiFxo88ww@mail.gmail.com>
Date: Wed, 12 Sep 2012 09:40:22 -0700
Message-ID: 
 <CAAOfhrDBbm1WF2kVt2_W9VtyLRf8XYwkMCKWNzPpxrj8Xzvohw@mail.gmail.com>
Subject: Re: PartitionData
From: Joel Koshy <jjkoshy.w@gmail.com>
To: kafka-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f3bb005d176e404c983d873

--e89a8f3bb005d176e404c983d873
Content-Type: text/plain; charset=ISO-8859-1

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 <jay.kreps@gmail.com> 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
>

--e89a8f3bb005d176e404c983d873--