Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EE3D0100F8 for ; Wed, 5 Feb 2014 14:14:57 +0000 (UTC) Received: (qmail 77040 invoked by uid 500); 5 Feb 2014 14:14:55 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 76744 invoked by uid 500); 5 Feb 2014 14:14:52 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 76730 invoked by uid 99); 5 Feb 2014 14:14:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Feb 2014 14:14:51 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of 0x6e6562@gmail.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vb0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Feb 2014 14:14:44 +0000 Received: by mail-vb0-f43.google.com with SMTP id p5so318228vbn.16 for ; Wed, 05 Feb 2014 06:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oRP9P3ajKqeO7Jj0bN11I7kQBvO29UHenHd6xAjCQ5g=; b=HQJHwyyZ22RVUFspY5GwFxVuX/IwqPckb4GbiCZ999xMA5zJr+vv99a3q2GAukw6QO uSYvzIHPu+8B4a+OkH9a/hIAMHYAUW4NvOVUmRWP3ZRRNL0hImKPk8oHnc/2rqt+/sjK w9uzefsUi3G665YCrzx8O6phZHxrvOHoMITVsNbk2t/VkWo/FZ77p7F6x7SzQ5wjpnqS PeyhXe7iuYabM1GbWU+a5vzhpxh+ViZoeWI7L4hIb9sW65HruXe6qgT8u2krS6yHU24s I/B8tAY3ezJB7zKySCo8uW38JU+A4IcPK/Gzay9JidX/srGCJUixFwv4iJt8lseFI04H GStw== MIME-Version: 1.0 X-Received: by 10.220.252.71 with SMTP id mv7mr29308vcb.68.1391609663201; Wed, 05 Feb 2014 06:14:23 -0800 (PST) Received: by 10.58.109.33 with HTTP; Wed, 5 Feb 2014 06:14:23 -0800 (PST) Date: Wed, 5 Feb 2014 14:14:23 +0000 Message-ID: Subject: CQL flow control From: Ben Hood <0x6e6562@gmail.com> To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi, A discussion has arisen in the gocql team about how to handle saturation when CQL clients are sending in packets at a faster rate than the Cassandra cluster can sustain. What is the general approach to this from a server perspective? Is there any flow control that the server can apply to back pressure onto the sending driver? If this were the case, you could code the driver to propagate this back pressure onto the sending app. If not, how do other driver implementors view this situation? Do you try to maintain some kind of flow control at the driver level so that you can push back onto the app, or you just let the effects of IO saturation just bubble up to the app? Cheers, Ben