Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C4F1D23D for ; Fri, 21 Dec 2012 23:51:04 +0000 (UTC) Received: (qmail 94395 invoked by uid 500); 21 Dec 2012 23:51:03 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 94359 invoked by uid 500); 21 Dec 2012 23:51:03 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 94351 invoked by uid 99); 21 Dec 2012 23:51:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Dec 2012 23:51:03 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pranav.saxena@citrix.com designates 203.166.19.134 as permitted sender) Received: from [203.166.19.134] (HELO SMTP.CITRIX.COM.AU) (203.166.19.134) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Dec 2012 23:50:56 +0000 X-IronPort-AV: E=Sophos;i="4.84,332,1355097600"; d="scan'208";a="172056" Received: from banpmailmx02.citrite.net ([10.103.128.74]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5; 21 Dec 2012 23:50:34 +0000 Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Sat, 22 Dec 2012 05:20:33 +0530 From: Pranav Saxena To: "cloudstack-dev@incubator.apache.org" Date: Sat, 22 Dec 2012 05:19:57 +0530 Subject: RE: [DISCUSS]API request throttling Thread-Topic: [DISCUSS]API request throttling Thread-Index: Ac3frgF2Fzjw/+q4S9OeAhO6kAlglwAAXpQgAAl/UvA= Message-ID: <67EF18FDCA335F489B366120481AB6C5F6B38A4121@BANPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org A proper error code is certainly seems to be the standard . Just for an exa= mple , Twitter uses the same for handling their API throttling response err= ors as well (https://dev.twitter.com/docs/rate-limiting ) . The back-off a= lgorithm discussion I was referring to was for handling automatic triggeri= ng of blocked requests but I could not think of a scenario where it might = be useful for cloudstack to have such a functionality . Any ideas /suggest= ions? Regards, Pranav -----Original Message----- From: Alex Huang [mailto:Alex.Huang@citrix.com]=20 Sent: Saturday, December 22, 2012 12:51 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS]API request throttling >=20 > Which brings me to another question: what is the response: is it a=20 > HTTP error code or a normal response that has to be parsed? > The reaction of most users to an error from the cloud is to re-try --=20 > thereby making the problem worse. >=20 A proper error code is the right way to do it. It only makes the problem w= orse if it causes the system to behave poorly so we have to design this fea= ture such that processing it doesn't cause considerable performance/scale p= roblem in the system. One possibility is a backoff algorithm (saw some dis= cussion about it but wasn't sure if it was for this), where we hold off the= response if it continues to send requests, in effect choking the client. --Alex