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.
--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
