Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D8E3B200D54 for ; Fri, 8 Dec 2017 12:17:18 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id D77FF160C0D; Fri, 8 Dec 2017 11:17:18 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2A659160BF2 for ; Fri, 8 Dec 2017 12:17:18 +0100 (CET) Received: (qmail 6582 invoked by uid 500); 8 Dec 2017 11:17:17 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 6570 invoked by uid 99); 8 Dec 2017 11:17:16 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Dec 2017 11:17:16 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 52328C10A9 for ; Fri, 8 Dec 2017 11:17:16 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=trivago.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id L1GLXDmOAJjO for ; Fri, 8 Dec 2017 11:17:14 +0000 (UTC) Received: from mail0.trivago.net (mail0.trivago.net [217.79.217.220]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 7CD965F3D1 for ; Fri, 8 Dec 2017 11:17:14 +0000 (UTC) Received: from mail0.trivago.net (localhost [127.0.0.1]) by mail0.trivago.net (Postfix) with ESMTP id 1034E1F6F8 for ; Fri, 8 Dec 2017 11:15:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=trivago.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail0; bh=QznzN/OZ3Xf nmWofF2SbwyFDc1A=; b=lUaGXxLKmpxCtTmpJGlHQp58lNlS77s7J0f/bbQxZkE LH8h/TCBF3eiPPapQ6ArypLqDrc/MdD9mz5NkQE41Cl8xd2EOriRHJTIp0/svTpb Uy70SM40FPELghDm4vv9hnZ1617GKVBgWbV229cwBzaMDbo6U5yL0q2ZNQ8ohD2g = Message-ID: <5A2A746A.2070207@trivago.com> Date: Fri, 8 Dec 2017 12:15:54 +0100 From: Jan Filipiak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Subject: Re: [DISCUSS] KIP-227: Introduce Incremental FetchRequests to Increase Partition Scalability References: <1511298156.455181.1180266296.193D3A00@webmail.messagingengine.com> <5A1D027C.7020206@trivago.com> <1511887086.3498918.1186985376.7F1DEDD6@webmail.messagingengine.com> <1511986396.621620.1188577080.5C0A7DEC@webmail.messagingengine.com> <1512063435.1832330.1189640136.2D1EEEC1@webmail.messagingengine.com> <1512254273.250506.1191933912.13817ECC@webmail.messagingengine.com> <1512334541.920899.1192564144.1A4C5D62@webmail.messagingengine.com> <5A25231B.8050703@trivago.com> <1512457563.3859529.1194299248.56AB43CE@webmail.messagingengine.com> <5A270BF3.8070701@trivago.com> <1512512081.3862143.1195227528.1E8C4CEB@webmail.messagingengine.com> <5A2A5867.7060704@trivago.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: exchange06-fe.Trivago.local (192.168.15.26) To exchange06-fe.Trivago.local (192.168.15.26) archived-at: Fri, 08 Dec 2017 11:17:19 -0000 On 08.12.2017 10:43, Ismael Juma wrote: > One correction below. > > On Fri, Dec 8, 2017 at 11:16 AM, Jan Filipiak > wrote: > >> We only check max.message.bytes to late to guard against consumer stalling. >> we dont have a notion of max.networkpacket.size before we allocate the >> bytebuffer to read it into. > > We do: socket.request.max.bytes. > > Ismael > perfect, didn't knew we have this in the meantime. :) good that we have it. Its a very good safeguard. and a nice fail fast for dodgy clients or network interfaces.