@Isabelle, @Uvindra You can identify which level you will be throttle out
from the code that returned in the response. So no need of debug logs to
identify which level particular request has throttled out. With the code
you can customized the throttled out message according to your
requirements. If you need more information, you can enable debug logs.
Also CEP has message tracing capabilities which we can use to identify what
happen in CEP side. @Mohan should be able to give more information on CEP
side.
*Api Level Throttled Out Response*
{ "fault": { "code": 900800, "message": "Message throttled out", "
description": "You have exceeded your quota", "nextAccessTime": "2016-May-21
15:41:00+0000 UTC" } }
*Hard Limit Throttled Out Response*
{ "fault": { "code": 900801, "message": "API Limit Reached",
"description": "API
not accepting requests" } }
*Resource Level** Throttled Out Response*
{
"fault": { "code": 900802, "message": "Message throttled out", "description":
"You have exceeded your quota", "nextAccessTime": "2016-May-21
15:05:00+0000 UTC" } }
*Application Level Throttled Out Response*
{ "fault": { "code": 900803, "message": "Message throttled out", "
description": "You have exceeded your quota", "nextAccessTime": "2016-May-21
15:36:00+0000 UTC" } }
*Subscription Level Throttled Out Response*
{
"fault": { "code": 900804, "message": "Message throttled out", "description":
"You have exceeded your quota", "nextAccessTime": "2016-May-21
15:36:00+0000 UTC" } }
*Blocked Response*
{
"fault": { "code": 900805, "message": "Message blocked", "description": "You
have been blocked from accessing the resource" } }
*Throttle Out by Custom Policy Response*
{ "fault": { "code": 900806, "message": "Message throttled out", "
description": "You have exceeded your quota", "nextAccessTime": "2016-May-21
17:05:10+0000 UTC" } }
On Mon, May 23, 2016 at 5:20 PM, Isabelle Mauny <isabe...@wso2.com> wrote:
> +1 !! No debug logs allowed here. All the tracking of what’s happening
> must be easily available - Using don’t have to debug this, they need to
> understand that is happening based on the information they have set ( and
> no that does not mean debugging CEP either, which just happens to be the
> engine we are relying on)
>
> Isabelle.
> __________________________________________________
>
> Isabelle Mauny
> VP, Product Management; WSO2, Inc.; http://wso2.com/
>
>
> On May 23, 2016, at 1:45 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
> Debug logging might not always be a feasible option for this. CEP engine
> should be able to tell what events triggered a given rule right(for
> auditing purposes)?
>
> On 23 May 2016 at 15:09, Harsha Kumara <hars...@wso2.com> wrote:
>
>> Yes, we are returning different codes for each level of throttle. Also
>> enabling debug logs should give more information as well. So you can
>> identify which level you have been throttle out from codes. I agree with
>> you that we need to clearly mentioned the use of each level of throttling.
>> Users will need throttle on few levels depend on their requirements. Since
>> we are providing the flexibility to apply throttling at different levels,
>> with proper details they can apply required throttling levels based on what
>> they really need for the protect their APIs. I have mentioned all the
>> responses return by APIM for each level of throttling in[1] mail thread.
>>
>> [1] - CEP Based Throttling Implementation - Changes in Quota calculations
>>
>>
>> On Mon, May 23, 2016 at 3:00 PM, Uvindra Dias Jayasinha <uvin...@wso2.com
>> > wrote:
>>
>>> Thanks for clearing that up Harsha, with all these different
>>> combinations its going to be tricky to know what a users or applications
>>> effective quota is going to be. Its going to be just as hard to debug
>>> throttling related scenarios. Do we have a way of diagnosing(getting some
>>> feedback) regarding the effective quota that is being enforced? This is
>>> extremely important or we wont be able to explain why throttling is
>>> happening in a certain way.
>>>
>>> On 23 May 2016 at 14:24, Harsha Kumara <hars...@wso2.com> wrote:
>>>
>>>> I also missed one more types of throttle policy. We have added
>>>> capability define custom policies for super tenant. Those policies will be
>>>> applied across all APIs globally. With custom policies, user can write a
>>>> siddhi query with stream data and define a throtttleKey based on their
>>>> requirement and it will deploy to CEP. Then those custom policies will
>>>> apply for all the APIs.
>>>>
>>>>
>>>>
>>>> On Mon, May 23, 2016 at 2:20 PM, Harsha Kumara <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, May 23, 2016 at 10:57 AM, Uvindra Dias Jayasinha <
>>>>> uvin...@wso2.com> wrote:
>>>>>
>>>>>> Can we simplify the definition a bit more? Seems that the main thing
>>>>>> we have done here is having a differentiation between individual user/app
>>>>>> quotas and shared quotas across all users/apps. I think we need to change
>>>>>> the names that we have used to define these policies because they don't
>>>>>> communicate the meaning of what they stand for. Its very important that
>>>>>> we
>>>>>> get this right or this will be a source of confusion to users.
>>>>>>
>>>>>> Adding Harsha's reply below and my comments in line, again please
>>>>>> correct me if I'm wrong and let me know what you think.
>>>>>>
>>>>>> On Fri, May 20, 2016 at 5:53 PM, Uvindra Dias Jayasinha <
>>>>>> uvin...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Harsha,
>>>>>>>
>>>>>>> So if we define it simply, correct me if Im wrong,
>>>>>>>
>>>>>>>
>>>>>>> *Application level throttling limit* - The total number of
>>>>>>> invocations a given Application can make to its underlying APIs
>>>>>>>
>>>>>> If the Application level throttling tier has defined let's say 1000
>>>>>> req/min. Then the single application user will get maximum 1000 req/min
>>>>>> for
>>>>>> all of the APIs that subscribe to that application.
>>>>>>
>>>>>> So this is the quota of *each* application user
>>>>>>
>>>>> Yes
>>>>>
>>>>>>
>>>>>>
>>>>>>> *Subscription level throttling limit* - The total number of
>>>>>>> invocations a given Subscribers Application can make to its underlying
>>>>>>> APIs
>>>>>>>
>>>>>> Yes, if Application 1 subscribe to quota of 50000 req/min tier, then
>>>>>> all underline users can use that particular API maximum of 50000 req/min.
>>>>>> If there are 100 application users, that will be the maximum limit that
>>>>>> they will get for that API.
>>>>>>
>>>>>> So this is the *shared* quota for all users of a given application
>>>>>>
>>>>> Yes
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Can you elaborate more on the two API level throttling types and how
>>>>>>> it relates to the above two? Its not clear to me. Based on what you have
>>>>>>> said it seems that you have the option of using either API Level or API
>>>>>>> User Level throttling(Cant specify both for the same API instance)
>>>>>>>
>>>>>>> The throttling policy that can have either API level or User Level
>>>>>> type can be only apply at resource level or API Level. If you apply API
>>>>>> Level policy then you won't be able to select resource level tiers. If
>>>>>> user assigned this kind of policy(50000 req/min) for GET resource of
>>>>>> /user/{id}. Then if that policy is API Level type any request comes to
>>>>>> that
>>>>>> resource with any application will have the limit of that tier(50000
>>>>>> req/min). If that policy is user level type, then single user of from any
>>>>>> application will get limit of that tier(50000 req/min).
>>>>>>
>>>>>> So this is again similar to the previous policies except that this
>>>>>> type of policies can be applied for the entire API *OR* at
>>>>>> individual API resource level.
>>>>>>
>>>>>> Now the two types of policies available to us are named as API Level
>>>>>> and User Level(Being careful not mix this up with the fact that they can
>>>>>> be
>>>>>> either applied across the whole API or an API resource)
>>>>>>
>>>>> Yes, if someone selects API Level policy then selecting resource level
>>>>> policy will be disabled.
>>>>>
>>>>>>
>>>>>> For API level policy, it is the *shared* quota of all applications
>>>>>> that invoke the API.
>>>>>>
>>>>> Yes
>>>>>
>>>>>>
>>>>>> For User level policy, it is the quota assigned to *each*
>>>>>> application that will invoke the API.
>>>>>>
>>>>> Actually it's the quota for single user who can access the particular
>>>>> API from multiple applications. Simply when it's user level, throttle key
>>>>> will be associate with username.
>>>>>
>>>>>>
>>>>>> You can have mix of policies with API Level type and User Level type
>>>>>> which can be assigned either resource level or API Level. We are think of
>>>>>> listing only one type of policies to avoid confusion. These are the
>>>>>> policies that can have custom conditions such as throttle by IPs, JWT
>>>>>> Claim, Query Params and Headers.
>>>>>>
>>>>>>
>>>>>> On 20 May 2016 at 17:53, Uvindra Dias Jayasinha <uvin...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Harsha,
>>>>>>>
>>>>>>> So if we define it simply, correct me if Im wrong,
>>>>>>>
>>>>>>>
>>>>>>> *Application level throttling limit* - The total number of
>>>>>>> invocations a given Application can make to its underlying APIs
>>>>>>>
>>>>>>> *Subscription level throttling limit* - The total number of
>>>>>>> invocations a given Subscribers Application can make to its underlying
>>>>>>> APIs
>>>>>>>
>>>>>>>
>>>>>>> Can you elaborate more on the two API level throttling types and how
>>>>>>> it relates to the above two? Its not clear to me. Based on what you have
>>>>>>> said it seems that you have the option of using either API Level or API
>>>>>>> User Level throttling(Cant specify both for the same API instance)
>>>>>>>
>>>>>>>
>>>>>>> On 20 May 2016 at 16:30, Harsha Kumara <hars...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> With new throttling implementation we have introduced couple of new
>>>>>>>> throttling levels.
>>>>>>>>
>>>>>>>> Old throttling Levels
>>>>>>>>
>>>>>>>> - Application Level Throttling
>>>>>>>> - Subscription Level Throttling
>>>>>>>> - Resource Level Throttling
>>>>>>>> - Hard Throttling
>>>>>>>>
>>>>>>>> New throttling levels and changes
>>>>>>>>
>>>>>>>> With the new throttling implementation we have changed the
>>>>>>>> subscription policy applicability. When application is subscribe to a
>>>>>>>> API,
>>>>>>>> the subscription level quota will be the limit that particular
>>>>>>>> application
>>>>>>>> can access that API. If application uses by 100 uses and subscribe to a
>>>>>>>> 20000 Req/Min tier, then all 100 users can maximum of 20000 Request per
>>>>>>>> minute. Previously any application user can access limit of 20000
>>>>>>>> Req/Min.
>>>>>>>> We also introduce rate limiting fro subscription tiers where it
>>>>>>>> specifies
>>>>>>>> TPS value. This will be the maximum TPS which any user can access the
>>>>>>>> particular API.
>>>>>>>>
>>>>>>>> Application developers can apply application throttling tier. If
>>>>>>>> someone applied application throttling tier, it will be the maximum
>>>>>>>> limit
>>>>>>>> that one user can access the APIs of that application. Eg if
>>>>>>>> application
>>>>>>>> tier 300 Req/Min applied, then any user can access the APIs that
>>>>>>>> subscribed
>>>>>>>> by the application with maximum 300 Req/Min
>>>>>>>>
>>>>>>>> - Rate limiting
>>>>>>>> - Blocking
>>>>>>>> - With new implementation user can blocked access to API by
>>>>>>>> IP, appId, user and by API
>>>>>>>> - API Level Throttling(User Level and API Level)
>>>>>>>> - API Level throttling is new level that we have introduce.
>>>>>>>> Compared to previous implementation there is no option to
>>>>>>>> control access to
>>>>>>>> API by whole API or by API user. Depend on the policy selection
>>>>>>>> and the
>>>>>>>> policy type either User Level or API Level, it will decide
>>>>>>>> accessibility of
>>>>>>>> the API.
>>>>>>>>
>>>>>>>> Below shows overall throttling policy applied levels with some
>>>>>>>> sample values. It will be gives better idea on where the each level of
>>>>>>>> throttling has applied.
>>>>>>>>
>>>>>>>> <tthrottle (1).jpg>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Harsha
>>>>>>>>
>>>>>>>> --
>>>>>>>> Harsha Kumara
>>>>>>>> Software Engineer, WSO2 Inc.
>>>>>>>> Mobile: +94775505618
>>>>>>>> Blog:harshcreationz.blogspot.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Uvindra
>>>>>>>
>>>>>>> Mobile: 777733962
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Uvindra
>>>>>>
>>>>>> Mobile: 777733962
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Harsha Kumara
>>>>> Software Engineer, WSO2 Inc.
>>>>> Mobile: +94775505618
>>>>> Blog:harshcreationz.blogspot.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Harsha Kumara
>>>> Software Engineer, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Blog:harshcreationz.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 777733962
>>>
>>
>>
>>
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 777733962
>
>
>
--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
