Hi Samisa, On Thu, Jul 18, 2013 at 6:02 AM, Samisa Abeysinghe <[email protected]> wrote:
> So it looks to me that we can only throttle based on requests per second. > Yes as of now we support only within time window. > > This is fine for the first cut implementation. > > However, how extensible is this implementation? How easily can another > type of trotting strategy be added? > We need to implement API throttle handler and implement doThrottle method doThrottle(MessageContext mc) inside above method we can retrieve any information we need(from message context or usage data store). Then we need to define throttle key for this scenario(it can be name, access key). then we have to call canAccess(context, Key, tier). This canAccess is not new implementation and already available in throttle module and we are using it. > > Another question is what is the relationship between what is throttled and > what is monitored (using BAM for e.g.) > When we monitor API usage using usage handler we do capture all information available with message context and use subset of that for throttling purposes. We do not capture message bandwidth for API call. Thanks, Sanjeewa > > > On Wed, Jul 17, 2013 at 6:06 PM, Sanjeewa Malalgoda <[email protected]>wrote: > >> >> >> On Wed, Jul 17, 2013 at 5:52 PM, Samisa Abeysinghe <[email protected]>wrote: >> >>> Well, when it said throttling, I got the impression that we could do >>> things like: >>> - number of calls per second (rate limit) >>> >> We do support this at 3 levels as i mentioned. >> >>> - bits per second (bandwidth limit) >>> >> We don't support this as of now. >> >>> >>> etc. on a time window. >>> >> >> Thanks, >> Sanjeewa >> >>> >>> >>> >>> >>> On Wed, Jul 17, 2013 at 5:44 PM, Sumedha Rubasinghe <[email protected]>wrote: >>> >>>> On Wed, Jul 17, 2013 at 5:23 PM, Samisa Abeysinghe <[email protected]>wrote: >>>> >>>>> Throttling based on which parameters? >>>>> >>>> For now we have only considered Access Token + API sub context + HTTP >>>> Verb >>>> >>>> >>>>> How does that get mapped into tier? >>>>> >>>> >>>> @ the point of API being published, a tier will be associated to each >>>> API sub context + HTTP Verb. >>>> So throttling (if configured @ resource level) will happen against >>>> each access token. >>>> >>>> >>>>> >>>>> >>>>> Does the params change tier to tier or are they same across all tiers? >>>>> >>>> >>>> Yes. They can be. But for now, we have only considered above (which >>>> seems to have supported most of the client cases). >>>> >>>> >>>>> >>>>> How customizable are the params? >>>>> >>>> >>>> Right now, the throttling definition is a XML based on WS-Policy. >>>> eg: >>>> >>>> <wsp:Policy> >>>> <throttle:ID throttle:type="ROLE">Gold</throttle:ID> >>>> <wsp:Policy> >>>> <throttle:Control> >>>> <wsp:Policy> >>>> <throttle:MaximumCount>20</throttle:MaximumCo >>>> unt> >>>> <throttle:UnitTime>60000</throttle:UnitTime> >>>> </wsp:Policy> >>>> </throttle:Control> >>>> </wsp:Policy> >>>> </wsp:Policy> >>>> >>>> >>>> >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 2:01 PM, Sanjeewa Malalgoda <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi All, >>>>>> We are going to add Throttling Support at API Resource Level. Here is >>>>>> a brief description on what we are going to do here. >>>>>> >>>>>> Current functionality: >>>>>> Now we do have throttling support at API level and application level. >>>>>> Consumer can select throttling tier for API when they subscribe to API, >>>>>> also they can define throttling tier when they create >>>>>> application(application is bundle of APIs). >>>>>> >>>>>> New Addition: >>>>>> Support for providing throttling tier support for resource level and >>>>>> HTTP verb level. >>>>>> >>>>>> Throttling tiers per resource and http verb level can be define when >>>>>> we create API like we add throttling tiers per API. So when subscribers >>>>>> going to subscribe to API they will notify throttling limits at resource >>>>>> level. see following sample. >>>>>> >>>>>> >>>>>> API - testAPI (allow subscribers to select gold and unlimited). >>>>>> /testAPI/1.0.0/. Subscribers can select this when they subscribe to >>>>>> API >>>>>> |---Resource - student/ >>>>>> |--get - Bronze (define when we create api and subscribers >>>>>> cannot change this. But they will notify limits). >>>>>> |--put -Silver (define when we create api and subscribers >>>>>> cannot change this.But they will notify limits). >>>>>> |--delete - Bronze(define when we create api and subscribers >>>>>> cannot change this.But they will notify limits). >>>>>> >>>>>> >>>>>> Our plan is to add this resource section of API create UI. >>>>>> >>>>>> So API publishers can select throttling tier when they create API and >>>>>> add resource level permissions to API. >>>>>> >>>>>> Implementation: >>>>>> Throttling key for this scenario will contain access_token + api >>>>>> +resource + http_verb combination. Throttling values once loaded will be >>>>>> cached for performance. Sample UI for this implementation attached. >>>>>> >>>>>> Thanks, >>>>>> Sanjeewa. >>>>>> >>>>>> -- >>>>>> * >>>>>> * >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +94713068779 >>>>>> >>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Samisa... >>>>> >>>>> Samisa Abeysinghe >>>>> VP Engineering >>>>> WSO2 Inc. >>>>> http://wso2.com >>>>> http://wso2.org >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> /sumedha >>>> b : bit.ly/sumedha >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Thanks, >>> Samisa... >>> >>> Samisa Abeysinghe >>> VP Engineering >>> WSO2 Inc. >>> http://wso2.com >>> http://wso2.org >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> * >> * >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- * * *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
