On Wed, Jul 24, 2013 at 3:06 PM, Srinath Perera <srin...@wso2.com> 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 <sam...@wso2.com>wrote:
>
>>
>>
>> On Thu, Jul 18, 2013 at 9:36 AM, Sanjeewa Malalgoda <sanje...@wso2.com>wrote:
>>
>>> Hi Samisa,
>>>
>>> On Thu, Jul 18, 2013 at 6:02 AM, Samisa Abeysinghe <sam...@wso2.com>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 
>>>> <sanje...@wso2.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 17, 2013 at 5:52 PM, Samisa Abeysinghe <sam...@wso2.com>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 <sume...@wso2.com
>>>>>> > wrote:
>>>>>>
>>>>>>> On Wed, Jul 17, 2013 at 5:23 PM, Samisa Abeysinghe 
>>>>>>> <sam...@wso2.com>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 <
>>>>>>>> sanje...@wso2.com> 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
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> 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
>>>>>>>> Architecture@wso2.org
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> /sumedha
>>>>>>> b :  bit.ly/sumedha
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> 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
>>>>>> Architecture@wso2.org
>>>>>> 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
>>>>> Architecture@wso2.org
>>>>> 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
>>>> Architecture@wso2.org
>>>> 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
>>> Architecture@wso2.org
>>> 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
>> Architecture@wso2.org
>> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
/sumedha
b :  bit.ly/sumedha
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to