Hi Ismael,
55 MB seems reasonable. I'll change it to that.
best,
Colin
On Tue, Oct 22, 2019, at 07:22, Ismael Juma wrote:
> Hi Colin,
>
> Thanks for the KIP. This is definitely needed. Have we considered having a
> lower max limit by default? 75 MB is pretty high. Did we consider something
>
On Tue, Oct 22, 2019, at 01:10, Stanislav Kozlovski wrote:
> Thanks for the KIP, Colin! This is a good idea, I think it makes total
> sense.
>
> We also have the max-size tunables on the producer-side (max.request.size).
> Do we have a broker equivalent denoting the maximum size of a produce
> req
Hi Colin,
Thanks for the KIP. This is definitely needed. Have we considered having a
lower max limit by default? 75 MB is pretty high. Did we consider something
like 55 MB, which is 10% above the default for consumers?
Ismael
On Mon, Oct 21, 2019 at 2:57 PM Colin McCabe wrote:
> Hi all,
>
> I
Thanks for the KIP, Colin! This is a good idea, I think it makes total
sense.
We also have the max-size tunables on the producer-side (max.request.size).
Do we have a broker equivalent denoting the maximum size of a produce
request? Is socket.request.max.bytes expected to act as that and if not, i
Thanks Collin.
I read this statement " Fetch request from replicas will also be affected
by the *fetch.max.bytes* limit."
Which made me think whether this was referring to replica fetcher byte
size. But thanks for clarifying.
Regards,
On Tue, 22 Oct 2019 at 00:26, Colin McCabe wrote:
> On Mon
On Mon, Oct 21, 2019, at 15:52, M. Manna wrote:
> Hello Colin,
>
> The KIP looks concise. My comments are below.
>
> replica.fetch.max.bytes is relevant when there is replication involved, so
> I am trying to understand how fetch.max.bytes for a broker will play a role
> here. Apologies for any l
Hello Colin,
The KIP looks concise. My comments are below.
replica.fetch.max.bytes is relevant when there is replication involved, so
I am trying to understand how fetch.max.bytes for a broker will play a role
here. Apologies for any limited assumptions (always trying to catchup with
Kafka :).
A