Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
MIME-Version: 1.0
In-Reply-To: <1507227800.3565385.1129221736.0A6C8C7F@webmail.messagingengine.com>
References: <1507227800.3565385.1129221736.0A6C8C7F@webmail.messagingengine.com>
From: Tom Bentley <t.j.bentley@gmail.com>
Date: Thu, 5 Oct 2017 20:06:43 +0100
Message-ID: <CAMd5Ysw_S6WHkh24rZe4_aQoC50pGv4NK_46kVdqmr1pPa8tNw@mail.gmail.com>
Subject: Re: [DISCUSS] KIP-207: Offsets returned by ListOffsetsResponse should
 be monotonically increasing even during a partition leader change
To: dev@kafka.apache.org
Content-Type: multipart/alternative; boundary="94eb2c0c38aeda1a70055ad16c54"
archived-at: Thu, 05 Oct 2017 19:06:49 -0000

--94eb2c0c38aeda1a70055ad16c54
Content-Type: text/plain; charset="UTF-8"

Hi Colin,

Is it really true that "the period when the offset is unavailable should be
brief"? I'm thinking about a producer with acks=1, so the old leader
returns the ProduceResponse immediately and then is replaced before it can
sent a FetchResponse to any followers. The new leader is then waiting for
more messages from producers in order for its high watermark to increase
(because it's log doesn't have the original messages in, so its HW can't
catch up with this). This wait could be be arbitrarily long.

I rather suspect this isn't a problem really and that I misunderstand the
precise details of the protocol, but it would be beneficial to me to
discover my misconceptions.

Thanks,

Tom


On 5 October 2017 at 19:23, Colin McCabe <cmccabe@apache.org> wrote:

> Hi all,
>
> I created a KIP for discussion about fixing a corner case in
> ListOffsetsResponse.  Check it out at:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> monotonically+increasing+even+during+a+partition+leader+change
>
> cheers,
> Colin
>

--94eb2c0c38aeda1a70055ad16c54--