Hi Sumedha, Ah ok, lets get this done for next round.
--Srinath On Wed, Jul 24, 2013 at 3:54 PM, Sumedha Rubasinghe <[email protected]>wrote: > > > 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. >> > > Srinath, > We have only added another level of throttling capability for APIs. This > is still utilizing existing WSO2 Throttling component capabilities. > Once we have Siddhi based throttling component, we can switch. > > But right now Siddhi based throttling is not a stable option for immediate > release 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</thr >>>>>>>> ottle:MaximumCount> >>>>>>>> <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 >> >> > > > -- > /sumedha > b : bit.ly/sumedha > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- ============================ Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
