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.c...@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. > >Thanks >-min > >On 12/20/12 7:52 AM, "Pranav Saxena" <pranav.sax...@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:j...@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.sax...@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. >> >> >
