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" <sowmya.krish...@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" <sowmya.krish...@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.c...@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" >><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 >>>>> >>>> >>> >
