You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chiradeep Vittal <Ch...@citrix.com> on 2013/02/01 00:13:46 UTC
Re: [DISCUSS]API request throttling
I think she's talking about the CloudStack UI
On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>Hi Sowmya,
>
> I still could not understand your statement below about queryAsyncJob
>api. By searching the codebase, I didn't see anywhere in our code where CS
>itself triggers this command internally. For example, in deployVMCmd api,
>which will create an async job and return the job id to user, but CS
>itself internally will not automatically poll the job result on behalf of
>the user, so our current implementation will still count this api as 1.
>Did I miss anything here?
>
> Thanks
> -min
>
>On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>
>>>[Min] Since the intention of this feature is to avoid malicious attacks
>>>to CS server, we cannot filter out some APIs in throttling control.
>>>Otherwise, Malicious hackers can issue those filtered apis to cause CS
>>>server down. Also, I don't understand your comment on
>>>queryAsyncJobResultCmd, why a user cannot really control that? That is a
>>>user API.
>>
>>You're right queryAsyncJob can be fired independently by user. But I was
>>wondering in cases where aysnc jobs are issued by users, it results in
>>multiple queryAsyncJob requests fired (not by the user) that polls for
>>the job result, and yet, these get counted too although it was not
>>directly triggered by the user. I would imagine for now, the solution is
>>to have a sufficiently high api limit so that a user doesn't encounter
>>the limit too early due to multiple aysnc jobs fired in a short duration.
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Wednesday, January 30, 2013 11:41 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: Re: [DISCUSS]API request throttling
>>
>>Hi Sowmya,
>>
>> Thanks for the feedback. See my answers inline.
>>
>> -min
>>
>>On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>>
>>>Min, have few questions on this feature while I was coming up with test
>>>plan -
>>>
>>>1. Do we allow specifying multiple limits based on different intervals
>>>- for ex: 10 requests for interval = 5 sec, and 100 for interval = 60
>>>sec.
>>>Essentially multiple time slices for better granularity and control. If
>>>yes, how do I set up this?
>>[Min] No, currently we only support specifying one time limit with your
>>specified interval through components.xml. For the purpose of avoid
>>malicious attacks to CS server, I don't see the point of specifying
>>multiple limits for different time slices.
>>
>>>
>>>2. What is the purpose of resetApiLimitCmd being provided to the User?
>>>Can a user not keep invoking this API and reset his counter every time
>>>it's exceeding his limit? This should be available only to the admin
>>>isn't it?
>>[Min] That is the good point, we should only provide reset API to admin
>>user. I will fix FS to reflect that.
>>
>>>3. Can we have a "negative list" (or a better name) which shouldn't be
>>>accounted for throttling? For example, queryAsyncJob could be one
>>>candidate since a user cannot really control that.
>>[Min] Since the intention of this feature is to avoid malicious attacks
>>to CS server, we cannot filter out some APIs in throttling control.
>>Otherwise, Malicious hackers can issue those filtered apis to cause CS
>>server down. Also, I don't understand your comment on
>>queryAsyncJobResultCmd, why a user cannot really control that? That is a
>>user API.
>>
>>>
>>>4. FS states the back-off algorithm is TBD. I am assuming it's manual
>>>for now, at least for 4.1 release?
>>
>>[Min] Yes, that is manual for now.
>>>
>>>Thanks,
>>>Sowmya
>>>
>>>
>>>-----Original Message-----
>>>From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>Sent: Saturday, December 22, 2012 5:20 AM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: [DISCUSS]API request throttling
>>>
>>>A proper error code is certainly seems to be the standard . Just for an
>>>example , Twitter uses the same for handling their API throttling
>>>response errors as well (https://dev.twitter.com/docs/rate-limiting ) .
>>>The back-off algorithm discussion I was referring to was for handling
>>>automatic triggering 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 /suggestions?
>>>
>>>Regards,
>>>Pranav
>>>
>>>-----Original Message-----
>>>From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>Sent: Saturday, December 22, 2012 12:51 AM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: [DISCUSS]API request throttling
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>A proper error code is the right way to do it. It only makes the
>>>problem worse if it causes the system to behave poorly so we have to
>>>design this feature such that processing it doesn't cause considerable
>>>performance/scale problem in the system. One possibility is a backoff
>>>algorithm (saw some discussion 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
>>
>
Re: [DISCUSS]API request throttling
Posted by Min Chen <mi...@citrix.com>.
Before Spring injection, componentContext.xml is the place to
enable/disable a plugin. After spring inject with Javelin merge, we switch
to use applicationContext.xml.
Thanks
-min
On 2/12/13 2:37 AM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>Thanks very much for the review Min.
>
>As per the change in FS, I've added couple of more test cases relating to
>ListCapabilitiesCmd too. Uploaded the updated one.
>
>One question though: you've mentioned in the comments that for disabling
>throttling, I need to comment out bean definition for
>ApiRateLimitServiceImpl in applicationContext.xml. But this definition is
>actually present in componentContext.xml. Which is the correct one to use?
>
>Thanks,
>Sowmya
>
>
>-----Original Message-----
>From: Min Chen
>Sent: Tuesday, February 12, 2013 11:33 AM
>To: Sowmya Krishnan; cloudstack-dev@incubator.apache.org
>Subject: Re: [DISCUSS]API request throttling
>
>Hi Sowmya,
>
> I have reviewed your test plan, looks good to me. I have uploaded a new
>version of spreadsheet with my comments updated there, please click your
>test plan to see my comments. FS is also updated to date to reflect
>plugin implementation.
>
> Thanks
> -min
>
>On 2/5/13 9:48 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>
>>I've uploaded an initial draft of the test cases here:
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Thro
>>ttl
>>ing+Test+Cases
>>
>>Please let me know if any comments or if any new cases could be added.
>>Some of the verification steps related to the UI cases may be a bit hazy.
>>Feel free to comment.
>>
>>Thanks,
>>Sowmya
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Friday, February 01, 2013 10:15 AM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: Re: [DISCUSS]API request throttling
>>
>>If UI is firing queryAsynJobResult on behalf of the user, then it will
>>be counted. With recent event framework merge, can UI be notified with
>>job status change instead of constantly polling?
>>
>>-min
>>
>>Sent from my iPhone
>>
>>On Jan 31, 2013, at 8:24 PM, "Sowmya Krishnan"
>><so...@citrix.com> wrote:
>>
>>> Sorry...I should've been more clear. My question here is, from the
>>>UI, when a user fires an async job, do the queryAsyncJobResult APIs
>>>also get counted?
>>>
>>> -----Original Message-----
>>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
>>> Sent: Friday, February 01, 2013 4:44 AM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS]API request throttling
>>>
>>> I think she's talking about the CloudStack UI
>>>
>>> On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>>>
>>>> Hi Sowmya,
>>>>
>>>> I still could not understand your statement below about
>>>>queryAsyncJob api. By searching the codebase, I didn't see anywhere
>>>>in our code where CS itself triggers this command internally. For
>>>>example, in deployVMCmd api, which will create an async job and
>>>>return the job id to user, but CS itself internally will not
>>>>automatically poll the job result on behalf of the user, so our
>>>>current implementation will still count this api as 1.
>>>> Did I miss anything here?
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>> On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com>
>>>>wrote:
>>>>
>>>>>> [Min] Since the intention of this feature is to avoid malicious
>>>>>>attacks to CS server, we cannot filter out some APIs in throttling
>>>>>>control.
>>>>>> Otherwise, Malicious hackers can issue those filtered apis to
>>>>>>cause CS server down. Also, I don't understand your comment on
>>>>>>queryAsyncJobResultCmd, why a user cannot really control that? That
>>>>>>is a user API.
>>>>>
>>>>> You're right queryAsyncJob can be fired independently by user. But
>>>>>I was wondering in cases where aysnc jobs are issued by users, it
>>>>>results in multiple queryAsyncJob requests fired (not by the user)
>>>>>that polls for the job result, and yet, these get counted too
>>>>>although it was not directly triggered by the user. I would imagine
>>>>>for now, the solution is to have a sufficiently high api limit so
>>>>>that a user doesn't encounter the limit too early due to multiple
>>>>>aysnc jobs fired in a short duration.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Min Chen [mailto:min.chen@citrix.com]
>>>>> Sent: Wednesday, January 30, 2013 11:41 PM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: Re: [DISCUSS]API request throttling
>>>>>
>>>>> Hi Sowmya,
>>>>>
>>>>> Thanks for the feedback. See my answers inline.
>>>>>
>>>>> -min
>>>>>
>>>>> On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com>
>>>>>wrote:
>>>>>
>>>>>> Min, have few questions on this feature while I was coming up with
>>>>>> test plan -
>>>>>>
>>>>>> 1. Do we allow specifying multiple limits based on different
>>>>>> intervals
>>>>>> - for ex: 10 requests for interval = 5 sec, and 100 for interval =
>>>>>> 60 sec.
>>>>>> Essentially multiple time slices for better granularity and control.
>>>>>> If yes, how do I set up this?
>>>>> [Min] No, currently we only support specifying one time limit with
>>>>> your specified interval through components.xml. For the purpose of
>>>>> avoid malicious attacks to CS server, I don't see the point of
>>>>> specifying multiple limits for different time slices.
>>>>>
>>>>>>
>>>>>> 2. What is the purpose of resetApiLimitCmd being provided to the
>>>>>>User?
>>>>>> Can a user not keep invoking this API and reset his counter every
>>>>>>time it's exceeding his limit? This should be available only to the
>>>>>>admin isn't it?
>>>>> [Min] That is the good point, we should only provide reset API to
>>>>> admin user. I will fix FS to reflect that.
>>>>>
>>>>>> 3. Can we have a "negative list" (or a better name) which
>>>>>> shouldn't be accounted for throttling? For example, queryAsyncJob
>>>>>> could be one candidate since a user cannot really control that.
>>>>> [Min] Since the intention of this feature is to avoid malicious
>>>>>attacks to CS server, we cannot filter out some APIs in throttling
>>>>>control.
>>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>>>CS server down. Also, I don't understand your comment on
>>>>>queryAsyncJobResultCmd, why a user cannot really control that? That
>>>>>is a user API.
>>>>>
>>>>>>
>>>>>> 4. FS states the back-off algorithm is TBD. I am assuming it's
>>>>>> manual for now, at least for 4.1 release?
>>>>>
>>>>> [Min] Yes, that is manual for now.
>>>>>>
>>>>>> Thanks,
>>>>>> Sowmya
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>>>> Sent: Saturday, December 22, 2012 5:20 AM
>>>>>> To: cloudstack-dev@incubator.apache.org
>>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>>
>>>>>> A proper error code is certainly seems to be the standard . Just
>>>>>>for an example , Twitter uses the same for handling their API
>>>>>>throttling response errors as well
>>>>>>(https://dev.twitter.com/docs/rate-limiting ) .
>>>>>> The back-off algorithm discussion I was referring to was for
>>>>>>handling automatic triggering 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 /suggestions?
>>>>>>
>>>>>> Regards,
>>>>>> Pranav
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>>>> Sent: Saturday, December 22, 2012 12:51 AM
>>>>>> To: cloudstack-dev@incubator.apache.org
>>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> A proper error code is the right way to do it. It only makes the
>>>>>> problem worse if it causes the system to behave poorly so we have
>>>>>> to design this feature such that processing it doesn't cause
>>>>>> considerable performance/scale problem in the system. One
>>>>>> possibility is a backoff algorithm (saw some discussion 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
>>>>>
>>>>
>>>
>
RE: [DISCUSS]API request throttling
Posted by Sowmya Krishnan <so...@citrix.com>.
Thanks very much for the review Min.
As per the change in FS, I've added couple of more test cases relating to ListCapabilitiesCmd too. Uploaded the updated one.
One question though: you've mentioned in the comments that for disabling throttling, I need to comment out bean definition for ApiRateLimitServiceImpl in applicationContext.xml. But this definition is actually present in componentContext.xml. Which is the correct one to use?
Thanks,
Sowmya
-----Original Message-----
From: Min Chen
Sent: Tuesday, February 12, 2013 11:33 AM
To: Sowmya Krishnan; cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]API request throttling
Hi Sowmya,
I have reviewed your test plan, looks good to me. I have uploaded a new version of spreadsheet with my comments updated there, please click your test plan to see my comments. FS is also updated to date to reflect plugin implementation.
Thanks
-min
On 2/5/13 9:48 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>I've uploaded an initial draft of the test cases here:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Thro
>ttl
>ing+Test+Cases
>
>Please let me know if any comments or if any new cases could be added.
>Some of the verification steps related to the UI cases may be a bit hazy.
>Feel free to comment.
>
>Thanks,
>Sowmya
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Friday, February 01, 2013 10:15 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: [DISCUSS]API request throttling
>
>If UI is firing queryAsynJobResult on behalf of the user, then it will
>be counted. With recent event framework merge, can UI be notified with
>job status change instead of constantly polling?
>
>-min
>
>Sent from my iPhone
>
>On Jan 31, 2013, at 8:24 PM, "Sowmya Krishnan"
><so...@citrix.com> wrote:
>
>> Sorry...I should've been more clear. My question here is, from the
>>UI, when a user fires an async job, do the queryAsyncJobResult APIs
>>also get counted?
>>
>> -----Original Message-----
>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
>> Sent: Friday, February 01, 2013 4:44 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS]API request throttling
>>
>> I think she's talking about the CloudStack UI
>>
>> On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>>
>>> Hi Sowmya,
>>>
>>> I still could not understand your statement below about
>>>queryAsyncJob api. By searching the codebase, I didn't see anywhere
>>>in our code where CS itself triggers this command internally. For
>>>example, in deployVMCmd api, which will create an async job and
>>>return the job id to user, but CS itself internally will not
>>>automatically poll the job result on behalf of the user, so our
>>>current implementation will still count this api as 1.
>>> Did I miss anything here?
>>>
>>> Thanks
>>> -min
>>>
>>> On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com>
>>>wrote:
>>>
>>>>> [Min] Since the intention of this feature is to avoid malicious
>>>>>attacks to CS server, we cannot filter out some APIs in throttling
>>>>>control.
>>>>> Otherwise, Malicious hackers can issue those filtered apis to
>>>>>cause CS server down. Also, I don't understand your comment on
>>>>>queryAsyncJobResultCmd, why a user cannot really control that? That
>>>>>is a user API.
>>>>
>>>> You're right queryAsyncJob can be fired independently by user. But
>>>>I was wondering in cases where aysnc jobs are issued by users, it
>>>>results in multiple queryAsyncJob requests fired (not by the user)
>>>>that polls for the job result, and yet, these get counted too
>>>>although it was not directly triggered by the user. I would imagine
>>>>for now, the solution is to have a sufficiently high api limit so
>>>>that a user doesn't encounter the limit too early due to multiple
>>>>aysnc jobs fired in a short duration.
>>>>
>>>> -----Original Message-----
>>>> From: Min Chen [mailto:min.chen@citrix.com]
>>>> Sent: Wednesday, January 30, 2013 11:41 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS]API request throttling
>>>>
>>>> Hi Sowmya,
>>>>
>>>> Thanks for the feedback. See my answers inline.
>>>>
>>>> -min
>>>>
>>>> On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com>
>>>>wrote:
>>>>
>>>>> Min, have few questions on this feature while I was coming up with
>>>>> test plan -
>>>>>
>>>>> 1. Do we allow specifying multiple limits based on different
>>>>> intervals
>>>>> - for ex: 10 requests for interval = 5 sec, and 100 for interval =
>>>>> 60 sec.
>>>>> Essentially multiple time slices for better granularity and control.
>>>>> If yes, how do I set up this?
>>>> [Min] No, currently we only support specifying one time limit with
>>>> your specified interval through components.xml. For the purpose of
>>>> avoid malicious attacks to CS server, I don't see the point of
>>>> specifying multiple limits for different time slices.
>>>>
>>>>>
>>>>> 2. What is the purpose of resetApiLimitCmd being provided to the
>>>>>User?
>>>>> Can a user not keep invoking this API and reset his counter every
>>>>>time it's exceeding his limit? This should be available only to the
>>>>>admin isn't it?
>>>> [Min] That is the good point, we should only provide reset API to
>>>> admin user. I will fix FS to reflect that.
>>>>
>>>>> 3. Can we have a "negative list" (or a better name) which
>>>>> shouldn't be accounted for throttling? For example, queryAsyncJob
>>>>> could be one candidate since a user cannot really control that.
>>>> [Min] Since the intention of this feature is to avoid malicious
>>>>attacks to CS server, we cannot filter out some APIs in throttling
>>>>control.
>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>>CS server down. Also, I don't understand your comment on
>>>>queryAsyncJobResultCmd, why a user cannot really control that? That
>>>>is a user API.
>>>>
>>>>>
>>>>> 4. FS states the back-off algorithm is TBD. I am assuming it's
>>>>> manual for now, at least for 4.1 release?
>>>>
>>>> [Min] Yes, that is manual for now.
>>>>>
>>>>> Thanks,
>>>>> Sowmya
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>>> Sent: Saturday, December 22, 2012 5:20 AM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>
>>>>> A proper error code is certainly seems to be the standard . Just
>>>>>for an example , Twitter uses the same for handling their API
>>>>>throttling response errors as well
>>>>>(https://dev.twitter.com/docs/rate-limiting ) .
>>>>> The back-off algorithm discussion I was referring to was for
>>>>>handling automatic triggering 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 /suggestions?
>>>>>
>>>>> Regards,
>>>>> Pranav
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>>> Sent: Saturday, December 22, 2012 12:51 AM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> A proper error code is the right way to do it. It only makes the
>>>>> problem worse if it causes the system to behave poorly so we have
>>>>> to design this feature such that processing it doesn't cause
>>>>> considerable performance/scale problem in the system. One
>>>>> possibility is a backoff algorithm (saw some discussion 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
>>>>
>>>
>>
Re: [DISCUSS]API request throttling
Posted by Min Chen <mi...@citrix.com>.
Hi Sowmya,
I have reviewed your test plan, looks good to me. I have uploaded a new
version of spreadsheet with my comments updated there, please click your
test plan to see my comments. FS is also updated to date to reflect plugin
implementation.
Thanks
-min
On 2/5/13 9:48 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>I've uploaded an initial draft of the test cases here:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Throttl
>ing+Test+Cases
>
>Please let me know if any comments or if any new cases could be added.
>Some of the verification steps related to the UI cases may be a bit hazy.
>Feel free to comment.
>
>Thanks,
>Sowmya
>
>-----Original Message-----
>From: Min Chen [mailto:min.chen@citrix.com]
>Sent: Friday, February 01, 2013 10:15 AM
>To: cloudstack-dev@incubator.apache.org
>Subject: Re: [DISCUSS]API request throttling
>
>If UI is firing queryAsynJobResult on behalf of the user, then it will be
>counted. With recent event framework merge, can UI be notified with job
>status change instead of constantly polling?
>
>-min
>
>Sent from my iPhone
>
>On Jan 31, 2013, at 8:24 PM, "Sowmya Krishnan"
><so...@citrix.com> wrote:
>
>> Sorry...I should've been more clear. My question here is, from the UI,
>>when a user fires an async job, do the queryAsyncJobResult APIs also get
>>counted?
>>
>> -----Original Message-----
>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
>> Sent: Friday, February 01, 2013 4:44 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS]API request throttling
>>
>> I think she's talking about the CloudStack UI
>>
>> On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>>
>>> Hi Sowmya,
>>>
>>> I still could not understand your statement below about
>>> queryAsyncJob api. By searching the codebase, I didn't see anywhere
>>> in our code where CS itself triggers this command internally. For
>>> example, in deployVMCmd api, which will create an async job and
>>> return the job id to user, but CS itself internally will not
>>> automatically poll the job result on behalf of the user, so our
>>>current implementation will still count this api as 1.
>>> Did I miss anything here?
>>>
>>> Thanks
>>> -min
>>>
>>> On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com>
>>>wrote:
>>>
>>>>> [Min] Since the intention of this feature is to avoid malicious
>>>>> attacks to CS server, we cannot filter out some APIs in throttling
>>>>>control.
>>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>>> CS server down. Also, I don't understand your comment on
>>>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>>>> is a user API.
>>>>
>>>> You're right queryAsyncJob can be fired independently by user. But I
>>>> was wondering in cases where aysnc jobs are issued by users, it
>>>> results in multiple queryAsyncJob requests fired (not by the user)
>>>> that polls for the job result, and yet, these get counted too
>>>> although it was not directly triggered by the user. I would imagine
>>>> for now, the solution is to have a sufficiently high api limit so
>>>> that a user doesn't encounter the limit too early due to multiple
>>>>aysnc jobs fired in a short duration.
>>>>
>>>> -----Original Message-----
>>>> From: Min Chen [mailto:min.chen@citrix.com]
>>>> Sent: Wednesday, January 30, 2013 11:41 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS]API request throttling
>>>>
>>>> Hi Sowmya,
>>>>
>>>> Thanks for the feedback. See my answers inline.
>>>>
>>>> -min
>>>>
>>>> On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com>
>>>>wrote:
>>>>
>>>>> Min, have few questions on this feature while I was coming up with
>>>>> test plan -
>>>>>
>>>>> 1. Do we allow specifying multiple limits based on different
>>>>> intervals
>>>>> - for ex: 10 requests for interval = 5 sec, and 100 for interval =
>>>>> 60 sec.
>>>>> Essentially multiple time slices for better granularity and control.
>>>>> If yes, how do I set up this?
>>>> [Min] No, currently we only support specifying one time limit with
>>>> your specified interval through components.xml. For the purpose of
>>>> avoid malicious attacks to CS server, I don't see the point of
>>>> specifying multiple limits for different time slices.
>>>>
>>>>>
>>>>> 2. What is the purpose of resetApiLimitCmd being provided to the
>>>>>User?
>>>>> Can a user not keep invoking this API and reset his counter every
>>>>> time it's exceeding his limit? This should be available only to the
>>>>> admin isn't it?
>>>> [Min] That is the good point, we should only provide reset API to
>>>> admin user. I will fix FS to reflect that.
>>>>
>>>>> 3. Can we have a "negative list" (or a better name) which shouldn't
>>>>> be accounted for throttling? For example, queryAsyncJob could be
>>>>> one candidate since a user cannot really control that.
>>>> [Min] Since the intention of this feature is to avoid malicious
>>>> attacks to CS server, we cannot filter out some APIs in throttling
>>>>control.
>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>> CS server down. Also, I don't understand your comment on
>>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>>> is a user API.
>>>>
>>>>>
>>>>> 4. FS states the back-off algorithm is TBD. I am assuming it's
>>>>> manual for now, at least for 4.1 release?
>>>>
>>>> [Min] Yes, that is manual for now.
>>>>>
>>>>> Thanks,
>>>>> Sowmya
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>>> Sent: Saturday, December 22, 2012 5:20 AM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>
>>>>> A proper error code is certainly seems to be the standard . Just
>>>>> for an example , Twitter uses the same for handling their API
>>>>> throttling response errors as well
>>>>>(https://dev.twitter.com/docs/rate-limiting ) .
>>>>> The back-off algorithm discussion I was referring to was for
>>>>> handling automatic triggering 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 /suggestions?
>>>>>
>>>>> Regards,
>>>>> Pranav
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>>> Sent: Saturday, December 22, 2012 12:51 AM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: RE: [DISCUSS]API request throttling
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> A proper error code is the right way to do it. It only makes the
>>>>> problem worse if it causes the system to behave poorly so we have
>>>>> to design this feature such that processing it doesn't cause
>>>>> considerable performance/scale problem in the system. One
>>>>> possibility is a backoff algorithm (saw some discussion 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
>>>>
>>>
>>
RE: [DISCUSS]API request throttling
Posted by Sowmya Krishnan <so...@citrix.com>.
I've uploaded an initial draft of the test cases here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Throttling+Test+Cases
Please let me know if any comments or if any new cases could be added. Some of the verification steps related to the UI cases may be a bit hazy. Feel free to comment.
Thanks,
Sowmya
-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com]
Sent: Friday, February 01, 2013 10:15 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]API request throttling
If UI is firing queryAsynJobResult on behalf of the user, then it will be counted. With recent event framework merge, can UI be notified with job status change instead of constantly polling?
-min
Sent from my iPhone
On Jan 31, 2013, at 8:24 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
> Sorry...I should've been more clear. My question here is, from the UI, when a user fires an async job, do the queryAsyncJobResult APIs also get counted?
>
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Friday, February 01, 2013 4:44 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS]API request throttling
>
> I think she's talking about the CloudStack UI
>
> On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>
>> Hi Sowmya,
>>
>> I still could not understand your statement below about
>> queryAsyncJob api. By searching the codebase, I didn't see anywhere
>> in our code where CS itself triggers this command internally. For
>> example, in deployVMCmd api, which will create an async job and
>> return the job id to user, but CS itself internally will not
>> automatically poll the job result on behalf of the user, so our current implementation will still count this api as 1.
>> Did I miss anything here?
>>
>> Thanks
>> -min
>>
>> On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>>
>>>> [Min] Since the intention of this feature is to avoid malicious
>>>> attacks to CS server, we cannot filter out some APIs in throttling control.
>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>> CS server down. Also, I don't understand your comment on
>>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>>> is a user API.
>>>
>>> You're right queryAsyncJob can be fired independently by user. But I
>>> was wondering in cases where aysnc jobs are issued by users, it
>>> results in multiple queryAsyncJob requests fired (not by the user)
>>> that polls for the job result, and yet, these get counted too
>>> although it was not directly triggered by the user. I would imagine
>>> for now, the solution is to have a sufficiently high api limit so
>>> that a user doesn't encounter the limit too early due to multiple aysnc jobs fired in a short duration.
>>>
>>> -----Original Message-----
>>> From: Min Chen [mailto:min.chen@citrix.com]
>>> Sent: Wednesday, January 30, 2013 11:41 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS]API request throttling
>>>
>>> Hi Sowmya,
>>>
>>> Thanks for the feedback. See my answers inline.
>>>
>>> -min
>>>
>>> On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>>>
>>>> Min, have few questions on this feature while I was coming up with
>>>> test plan -
>>>>
>>>> 1. Do we allow specifying multiple limits based on different
>>>> intervals
>>>> - for ex: 10 requests for interval = 5 sec, and 100 for interval =
>>>> 60 sec.
>>>> Essentially multiple time slices for better granularity and control.
>>>> If yes, how do I set up this?
>>> [Min] No, currently we only support specifying one time limit with
>>> your specified interval through components.xml. For the purpose of
>>> avoid malicious attacks to CS server, I don't see the point of
>>> specifying multiple limits for different time slices.
>>>
>>>>
>>>> 2. What is the purpose of resetApiLimitCmd being provided to the User?
>>>> Can a user not keep invoking this API and reset his counter every
>>>> time it's exceeding his limit? This should be available only to the
>>>> admin isn't it?
>>> [Min] That is the good point, we should only provide reset API to
>>> admin user. I will fix FS to reflect that.
>>>
>>>> 3. Can we have a "negative list" (or a better name) which shouldn't
>>>> be accounted for throttling? For example, queryAsyncJob could be
>>>> one candidate since a user cannot really control that.
>>> [Min] Since the intention of this feature is to avoid malicious
>>> attacks to CS server, we cannot filter out some APIs in throttling control.
>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>> CS server down. Also, I don't understand your comment on
>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>> is a user API.
>>>
>>>>
>>>> 4. FS states the back-off algorithm is TBD. I am assuming it's
>>>> manual for now, at least for 4.1 release?
>>>
>>> [Min] Yes, that is manual for now.
>>>>
>>>> Thanks,
>>>> Sowmya
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>> Sent: Saturday, December 22, 2012 5:20 AM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: RE: [DISCUSS]API request throttling
>>>>
>>>> A proper error code is certainly seems to be the standard . Just
>>>> for an example , Twitter uses the same for handling their API
>>>> throttling response errors as well (https://dev.twitter.com/docs/rate-limiting ) .
>>>> The back-off algorithm discussion I was referring to was for
>>>> handling automatic triggering 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 /suggestions?
>>>>
>>>> Regards,
>>>> Pranav
>>>>
>>>> -----Original Message-----
>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>> Sent: Saturday, December 22, 2012 12:51 AM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: RE: [DISCUSS]API request throttling
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> A proper error code is the right way to do it. It only makes the
>>>> problem worse if it causes the system to behave poorly so we have
>>>> to design this feature such that processing it doesn't cause
>>>> considerable performance/scale problem in the system. One
>>>> possibility is a backoff algorithm (saw some discussion 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
>>>
>>
>
Re: [DISCUSS]API request throttling
Posted by Min Chen <mi...@citrix.com>.
If UI is firing queryAsynJobResult on behalf of the user, then it will be counted. With recent event framework merge, can UI be notified with job status change instead of constantly polling?
-min
Sent from my iPhone
On Jan 31, 2013, at 8:24 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
> Sorry...I should've been more clear. My question here is, from the UI, when a user fires an async job, do the queryAsyncJobResult APIs also get counted?
>
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Friday, February 01, 2013 4:44 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS]API request throttling
>
> I think she's talking about the CloudStack UI
>
> On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>
>> Hi Sowmya,
>>
>> I still could not understand your statement below about queryAsyncJob
>> api. By searching the codebase, I didn't see anywhere in our code where
>> CS itself triggers this command internally. For example, in deployVMCmd
>> api, which will create an async job and return the job id to user, but
>> CS itself internally will not automatically poll the job result on
>> behalf of the user, so our current implementation will still count this api as 1.
>> Did I miss anything here?
>>
>> Thanks
>> -min
>>
>> On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>>
>>>> [Min] Since the intention of this feature is to avoid malicious
>>>> attacks to CS server, we cannot filter out some APIs in throttling control.
>>>> Otherwise, Malicious hackers can issue those filtered apis to cause
>>>> CS server down. Also, I don't understand your comment on
>>>> queryAsyncJobResultCmd, why a user cannot really control that? That
>>>> is a user API.
>>>
>>> You're right queryAsyncJob can be fired independently by user. But I
>>> was wondering in cases where aysnc jobs are issued by users, it
>>> results in multiple queryAsyncJob requests fired (not by the user)
>>> that polls for the job result, and yet, these get counted too although
>>> it was not directly triggered by the user. I would imagine for now,
>>> the solution is to have a sufficiently high api limit so that a user
>>> doesn't encounter the limit too early due to multiple aysnc jobs fired in a short duration.
>>>
>>> -----Original Message-----
>>> From: Min Chen [mailto:min.chen@citrix.com]
>>> Sent: Wednesday, January 30, 2013 11:41 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS]API request throttling
>>>
>>> Hi Sowmya,
>>>
>>> Thanks for the feedback. See my answers inline.
>>>
>>> -min
>>>
>>> On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>>>
>>>> Min, have few questions on this feature while I was coming up with
>>>> test plan -
>>>>
>>>> 1. Do we allow specifying multiple limits based on different
>>>> intervals
>>>> - for ex: 10 requests for interval = 5 sec, and 100 for interval = 60
>>>> sec.
>>>> Essentially multiple time slices for better granularity and control.
>>>> If yes, how do I set up this?
>>> [Min] No, currently we only support specifying one time limit with
>>> your specified interval through components.xml. For the purpose of
>>> avoid malicious attacks to CS server, I don't see the point of
>>> specifying multiple limits for different time slices.
>>>
>>>>
>>>> 2. What is the purpose of resetApiLimitCmd being provided to the User?
>>>> Can a user not keep invoking this API and reset his counter every
>>>> time it's exceeding his limit? This should be available only to the
>>>> admin isn't it?
>>> [Min] That is the good point, we should only provide reset API to
>>> admin user. I will fix FS to reflect that.
>>>
>>>> 3. Can we have a "negative list" (or a better name) which shouldn't
>>>> be accounted for throttling? For example, queryAsyncJob could be one
>>>> candidate since a user cannot really control that.
>>> [Min] Since the intention of this feature is to avoid malicious
>>> attacks to CS server, we cannot filter out some APIs in throttling control.
>>> Otherwise, Malicious hackers can issue those filtered apis to cause CS
>>> server down. Also, I don't understand your comment on
>>> queryAsyncJobResultCmd, why a user cannot really control that? That is
>>> a user API.
>>>
>>>>
>>>> 4. FS states the back-off algorithm is TBD. I am assuming it's manual
>>>> for now, at least for 4.1 release?
>>>
>>> [Min] Yes, that is manual for now.
>>>>
>>>> Thanks,
>>>> Sowmya
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>> Sent: Saturday, December 22, 2012 5:20 AM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: RE: [DISCUSS]API request throttling
>>>>
>>>> A proper error code is certainly seems to be the standard . Just for
>>>> an example , Twitter uses the same for handling their API throttling
>>>> response errors as well (https://dev.twitter.com/docs/rate-limiting ) .
>>>> The back-off algorithm discussion I was referring to was for handling
>>>> automatic triggering 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 /suggestions?
>>>>
>>>> Regards,
>>>> Pranav
>>>>
>>>> -----Original Message-----
>>>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>> Sent: Saturday, December 22, 2012 12:51 AM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: RE: [DISCUSS]API request throttling
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> A proper error code is the right way to do it. It only makes the
>>>> problem worse if it causes the system to behave poorly so we have to
>>>> design this feature such that processing it doesn't cause
>>>> considerable performance/scale problem in the system. One
>>>> possibility is a backoff algorithm (saw some discussion 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
>>>
>>
>
RE: [DISCUSS]API request throttling
Posted by Sowmya Krishnan <so...@citrix.com>.
Sorry...I should've been more clear. My question here is, from the UI, when a user fires an async job, do the queryAsyncJobResult APIs also get counted?
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, February 01, 2013 4:44 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]API request throttling
I think she's talking about the CloudStack UI
On 1/31/13 2:03 PM, "Min Chen" <mi...@citrix.com> wrote:
>Hi Sowmya,
>
> I still could not understand your statement below about queryAsyncJob
>api. By searching the codebase, I didn't see anywhere in our code where
>CS itself triggers this command internally. For example, in deployVMCmd
>api, which will create an async job and return the job id to user, but
>CS itself internally will not automatically poll the job result on
>behalf of the user, so our current implementation will still count this api as 1.
>Did I miss anything here?
>
> Thanks
> -min
>
>On 1/30/13 9:39 PM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>
>>>[Min] Since the intention of this feature is to avoid malicious
>>>attacks to CS server, we cannot filter out some APIs in throttling control.
>>>Otherwise, Malicious hackers can issue those filtered apis to cause
>>>CS server down. Also, I don't understand your comment on
>>>queryAsyncJobResultCmd, why a user cannot really control that? That
>>>is a user API.
>>
>>You're right queryAsyncJob can be fired independently by user. But I
>>was wondering in cases where aysnc jobs are issued by users, it
>>results in multiple queryAsyncJob requests fired (not by the user)
>>that polls for the job result, and yet, these get counted too although
>>it was not directly triggered by the user. I would imagine for now,
>>the solution is to have a sufficiently high api limit so that a user
>>doesn't encounter the limit too early due to multiple aysnc jobs fired in a short duration.
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Wednesday, January 30, 2013 11:41 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: Re: [DISCUSS]API request throttling
>>
>>Hi Sowmya,
>>
>> Thanks for the feedback. See my answers inline.
>>
>> -min
>>
>>On 1/30/13 3:17 AM, "Sowmya Krishnan" <so...@citrix.com> wrote:
>>
>>>Min, have few questions on this feature while I was coming up with
>>>test plan -
>>>
>>>1. Do we allow specifying multiple limits based on different
>>>intervals
>>>- for ex: 10 requests for interval = 5 sec, and 100 for interval = 60
>>>sec.
>>>Essentially multiple time slices for better granularity and control.
>>>If yes, how do I set up this?
>>[Min] No, currently we only support specifying one time limit with
>>your specified interval through components.xml. For the purpose of
>>avoid malicious attacks to CS server, I don't see the point of
>>specifying multiple limits for different time slices.
>>
>>>
>>>2. What is the purpose of resetApiLimitCmd being provided to the User?
>>>Can a user not keep invoking this API and reset his counter every
>>>time it's exceeding his limit? This should be available only to the
>>>admin isn't it?
>>[Min] That is the good point, we should only provide reset API to
>>admin user. I will fix FS to reflect that.
>>
>>>3. Can we have a "negative list" (or a better name) which shouldn't
>>>be accounted for throttling? For example, queryAsyncJob could be one
>>>candidate since a user cannot really control that.
>>[Min] Since the intention of this feature is to avoid malicious
>>attacks to CS server, we cannot filter out some APIs in throttling control.
>>Otherwise, Malicious hackers can issue those filtered apis to cause CS
>>server down. Also, I don't understand your comment on
>>queryAsyncJobResultCmd, why a user cannot really control that? That is
>>a user API.
>>
>>>
>>>4. FS states the back-off algorithm is TBD. I am assuming it's manual
>>>for now, at least for 4.1 release?
>>
>>[Min] Yes, that is manual for now.
>>>
>>>Thanks,
>>>Sowmya
>>>
>>>
>>>-----Original Message-----
>>>From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>Sent: Saturday, December 22, 2012 5:20 AM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: [DISCUSS]API request throttling
>>>
>>>A proper error code is certainly seems to be the standard . Just for
>>>an example , Twitter uses the same for handling their API throttling
>>>response errors as well (https://dev.twitter.com/docs/rate-limiting ) .
>>>The back-off algorithm discussion I was referring to was for handling
>>>automatic triggering 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 /suggestions?
>>>
>>>Regards,
>>>Pranav
>>>
>>>-----Original Message-----
>>>From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>Sent: Saturday, December 22, 2012 12:51 AM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: [DISCUSS]API request throttling
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>A proper error code is the right way to do it. It only makes the
>>>problem worse if it causes the system to behave poorly so we have to
>>>design this feature such that processing it doesn't cause
>>>considerable performance/scale problem in the system. One
>>>possibility is a backoff algorithm (saw some discussion 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
>>
>