All, With all those throttling limits with the same name, it's getting very confusing to understand what is going to happen in the end. We should introduce a few more default ones , with more significant names -
Also, how are we checking that the limits we are setting at different levels make sense, for example: if publisher sets a Silver limit on GET for an API (a limit which can't be changed) , the consumer can't subscribe to API at Gold level (he will never get that SLA) - Also, in the UI, if the list of available Tiers contains say Silver and Bronze for the overall API , Unlimited and Gold can't be available for API level throttling. Isabelle. __________________________________________________ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 24, 2013, at 11:14 PM, Samisa Abeysinghe <[email protected]> wrote: > So, on the UI, how can I say 10 for Gold and 5 for Silver? > > > On Thu, Jul 25, 2013 at 11:31 AM, Sanjeewa Malalgoda <[email protected]> > wrote: > Attaching UI components screen shots. > > Thanks, > Sanjeewa. > > > 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</throttle: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 > > blog :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 > > blog :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 > > blog :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 > > > > > -- > > Sanjeewa Malalgoda > WSO2 Inc. > Mobile : +94713068779 > > blog :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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
