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" <sowmya.krish...@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.vit...@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" <min.c...@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" <sowmya.krish...@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.c...@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" <sowmya.krish...@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.sax...@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.hu...@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 >>> >> >
