Magnus,
Thanks for the feedback. Commented on the wiki.
Jun
On Thu, Sep 13, 2012 at 12:47 AM, Magnus Edenhill wrote:
> 2012/9/12 Jay Kreps
>
> > Hey Guys,
> >
> > The request format in 0.8 has drifted a bit from the proposal (
> >
> https://cwiki.apache.org/confluence/display/KAFKA/New+Wire+Fo
2012/9/12 Jay Kreps
> 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.
>
I followed this link and d
Decoupling the PartitionData btw producer and fetch may not be a bad idea,
especially the way PartitionData is sent to socket is kind of different
(for fetch, the sendfile api is used).
Thanks,
Jun
On Wed, Sep 12, 2012 at 9:32 AM, Jay Kreps wrote:
> Hey Guys,
>
> The request format i
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 wrote:
> do want to create a ProducerRequestData and FetchResponseData?
>
> i'll open a ticket
>
> On
do want to create a ProducerRequestData and FetchResponseData?
i'll open a ticket
On Wed, Sep 12, 2012 at 12:40 PM, Joel Koshy 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
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
mak
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 produ