Re: [Dev] [APIM] Throttling Applicability Levels With New Throttling Implementation
@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+ 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+ 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+ 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+ 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+ UTC" } }
On Mon, May 23, 2016 at 5:20 PM, Isabelle Mauny 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
> 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 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 > > 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 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
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 me
Re: [Dev] [APIM] Throttling Applicability Levels With New Throttling Implementation
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
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 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+ 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+ 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+ 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+ 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+ UTC" } }
>>
>> On Mon, May 23, 2016 at 5:20 PM, Isabelle Mauny
>> 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
>>> 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 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
