Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Fri, 21 Dec 2012 11:04:28 -0800
Subject: Re: [DISCUSS]API request throttling
Thread-Topic: [DISCUSS]API request throttling
Thread-Index: Ac3frgF2Fzjw/+q4S9OeAhO6kAlglw==
Message-ID: <CCF9F0DA.3CE8D%chiradeep.vittal@citrix.com>
In-Reply-To: <CCF8943B.3E7A%min.chen@citrix.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

The other usecase for throttling is during system instability and recovery
operations. E.g. Let's say there is maintenance going on in a part of the
cloud and so the operator knows that API requests are going to fail on the
backend / or create further pressure on the physical resources that they
cannot manage. In this case it is better to throttle the API requests
upfront. Requiring the admin to change a global setting via the DB does
not make sense: it has to be an admin API that can throttle everybody.

Which brings me to another question: what is the response: is it a 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 --
thereby making the problem worse.


On 12/20/12 10:10 AM, "Min Chen" <min.chen@citrix.com> wrote:

>That is a good thought. Currently we haven't thought of automatically
>trigger those blocked requests, and still expect users to manually trigger
>it.=20
>
>Thanks
>-min
>
>On 12/20/12 7:52 AM, "Pranav Saxena" <pranav.saxena@citrix.com> wrote:
>
>>Amazon uses API throttling but from what I know they leverage the leaky
>>bucket algorithm and have some kind off  a "back-off" algorithm for few
>>of their tasks in which the API requests which were throttles are
>>automatically triggered depending upon what the use case is . Hence I
>>thought that perhaps , we might also encounter a similar scenario in
>>cloudstack as well . Can anyone think off a certain use case pertaining
>>to Cloudstack which might require such a functionality ?
>>
>>Regards,
>>Pranav
>>
>>-----Original Message-----
>>From: John Kinsella [mailto:jlk@stratosec.co]
>>Sent: Thursday, December 20, 2012 9:05 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: Re: [DISCUSS]API request throttling
>>
>>
>>On Dec 20, 2012, at 2:20 AM, Pranav Saxena <pranav.saxena@citrix.com>
>> wrote:
>>> Also  are we planning to build the code in such a way that when we take
>>>into consideration the "throttling time "  , do we have some kind off a
>>>back-off algorithm to trigger the request again  automatically ( may be
>>>in some scenarios , not sure though ) , when we're being throttled (like
>>>come back after a "restore rate" period, specific to the type of API
>>>request one is making )  or the user has to make the request again
>>>manually every time once he is throttled.  This might sound vague but I
>>>am just curious to know if such a scenario can exist or not .
>>
>>Good point.
>>
>>
>