On Wed, Jul 24, 2013 at 3:06 PM, Srinath Perera <[email protected]> wrote:
> Hi All, > > I am sorry I missed this thread. Did not we planned to do this via Siddhi? > that will give a very comprehensive solution IMO. > > We too had a thread on this "Using CEP to support Throttling". Suho --Srinath > > > On Thu, Jul 18, 2013 at 6:52 PM, Samisa Abeysinghe <[email protected]>wrote: > >> >> >> On Thu, Jul 18, 2013 at 9:36 AM, Sanjeewa Malalgoda <[email protected]>wrote: >> >>> 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. >>> >> >> I think it is a mistake that we are looking at this problem with the >> limitations of the existing throttling component. >> >> We need to take a step back and look at what API throttling need. Our >> original throttling component may not even have been designed with that in >> mind. >> >> >>> >>> >>>> >>>> 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. >>> >> >> Do we not want to capture BW at some point? Using subset for throttling >> is again not acceptable. Why are we using a subset? >> >> Again, we need to look at this without Axis2 oriented mindset. We need to >> think APIs. What would the users want when they throttle APIs? Moreover, in >> order to make throttling decisions, we need to make use of data that is >> being monitored. Meaning BAM feeds back into throttling. There needs to be >> one to one mapping here. >> >> >> >>> >>> 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 >>> >>> >> >> >> -- >> >> 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 >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *S. Suhothayan * Associate Technical Lead, *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan* * *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
