Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 26891 invoked from network); 28 Aug 2010 21:35:32 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Aug 2010 21:35:32 -0000 Received: (qmail 26794 invoked by uid 500); 28 Aug 2010 21:35:31 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 26751 invoked by uid 500); 28 Aug 2010 21:35:30 -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 26743 invoked by uid 99); 28 Aug 2010 21:35:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Aug 2010 21:35:30 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Aug 2010 21:35:22 +0000 Received: by wyi11 with SMTP id 11so5475914wyi.31 for ; Sat, 28 Aug 2010 14:35:01 -0700 (PDT) Received: by 10.216.144.22 with SMTP id m22mr2730471wej.0.1283031301197; Sat, 28 Aug 2010 14:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.3.129 with HTTP; Sat, 28 Aug 2010 14:34:41 -0700 (PDT) In-Reply-To: <4C79550E.1080907@gmail.com> References: <4C794746.8040708@gmail.com> <4C79550E.1080907@gmail.com> From: Benjamin Black Date: Sat, 28 Aug 2010 14:34:41 -0700 Message-ID: Subject: Re: Cassandra & HAProxy To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Because you create a bottleneck at the HAProxy and because the presence of the proxy precludes clients properly backing off from nodes returning errors. The proper approach is to have clients maintain connection pools with connections to multiple nodes in the cluster, and then to spread requests across those connections. Should a node begin returning errors (for example, because it is overloaded), clients can remove it from rotation. On Sat, Aug 28, 2010 at 11:27 AM, Mark wrote: > =A0On 8/28/10 11:20 AM, Benjamin Black wrote: >> >> no and no. >> >> On Sat, Aug 28, 2010 at 10:28 AM, Mark =A0wro= te: >>> >>> =A0I will be loadbalancing between nodes using HAProxy. Is this >>> recommended? >>> >>> Also is there a some sort of ping/health check uri available? >>> >>> Thanks >>> > any reason on why loadbalancing client connections using HAProxy isnt > recommended? >