Yeah that information we can't currently get from the handler and CEP side.
Basically we need some kind of tracing capability in our throttling
implementation. We can have CEP extension to generate more resourceful
event(i.e event including throttled out tier, user, throttling level, token
and etc) when the throttled out happen. So we can go through those data and
trace what was happen to particular request to be throttled out. Also when
user customize the throttle out message, end user won't get this error code
sometimes. If that case we won't have much information. This is a area
which we will need to improve.
On Mon, May 23, 2016 at 6:08 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
wrote:
> Im not so much interested in the response that is returned to the invoker,
> what I meant is can APIM/CEP tell us effectively that this is what caused
> the throttling to take place for the given API when it was invoked by
> access token X for example?
>
> What will happen is the user will get throttled out and they will come and
> ask why was I throttled out. With a so many combinations of policies
> available we need to be able to say this was your usage(Or some one else
> used up the shared quota available to you) and this tripped off the
> following policy. Can we do that?
>
> We cant turn on tracing/debug logs after this has taken place because then
> its too late. This needs to work like auditing, its always available to
> refer to if required.
>
> On 23 May 2016 at 17:47, Harsha Kumara <hars...@wso2.com> wrote:
>
>> @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
>>
>
>
>
> --
> 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
