Re: [Dev] [APIM] Issue while using Conditional Group

[Amila De Silva]

Implemented this with the following PRs
1. https://github.com/wso2/carbon-apimgt/pull/2551
2. https://github.com/wso2/carbon-apimgt/pull/2532


On Fri, Jun 17, 2016 at 6:20 AM, Amila De Silva  wrote:

> Hi Uvindra, Harsha,
>
> I don't think it's possible to get CEP do this. If we'd been calling CEP
> and waiting on its decision to let the request through, it would have been
> possible. Then for each request, CEP would evaluate the query and tell
> which conditions are applicable for that incoming request, and if the
> throttling quota defined by that policy has exceeded.
>
> With the current approach, what CEP does is, determining which counters
> should be incremented based on the published message and sending a message
> when any of the conditions have been throttled out. Gateway only have a
> bunch of throttled out keys, so it should have  a means of finding which
> keys are to be checked with each request.
>
> Rather than evaluating all the conditions for each request, we can
> optimise it (like first checking if any throttled out records are present
> for that API and then only evaluate the conditions), but the check needed
> to be done at the GW seems to be inevitable.
>
> On Thu, Jun 16, 2016 at 10:46 PM, Harsha Kumara  wrote:
>
>> Hi Amila,
>>
>> Are we going to evaluate the condition from the GW side? We will need to
>> check the possibility of doing this in CEP.  Otherwise it will performance
>> may degrade drastically. Again I'm doubt whether we can do it from the CEP
>> side as we publish set of data and take decisions based on the data coming
>> on the stream. It's independent of the request. Unless we have specific key
>> combination or identification pattern we won't be able to do it in the CEP
>> side as well.
>>
>> We will need to have a way to identify which condition group triggered
>> based on the data coming. Asynchronous behavior of data processing make it
>> harder to identify it from the CEP and transfer it to the gateway.
>>
>> Thanks,
>> Harsha
>>
>> On Sun, Jun 12, 2016 at 9:13 PM, Uvindra Dias Jayasinha > > wrote:
>>
>>> Hi Amila,
>>>
>>> I think it defeats the purpose if we need to evaluate conditions again
>>> on the GW side(GW starts to do part of the decision manager role), is it
>>> possible to fix this by asking CEP to provide the aggregate result of all
>>> the available conditions?
>>>
>>>
>>>
>>> On 11 June 2016 at 12:12, Amila De Silva  wrote:
>>>
 Hi All,

 This is related to the discussion had with Harsha on a particular
 behaviour observed when having Conditional Groups.

 Suppose we have a throttling policy like below;

 *default* - 1000 req/min

 *Condition* - 50 req/min if IP is 10.100.0.5


 The expected behaviour is, if requests are coming from 10.100.0.5, only
 to allow 50 req/min, but if coming from a different destination, allow 
 1000.

 But we observed that, when requests coming from 10.100.0.5 have been
 throttled out after utilising it’s full quota (50 req/min) , GW won’t
 accept any requests even from a different destination.


 While investigating the issue found that it was due to the way we
 enforce throttling at the GW.

 If we consider creating the above condition, then;

 1. Two Condition elements gets created (one for the default and the
 other for the actual condition) and get saved in the DB.

 2. Two execution plans are created to handle the conditions and are
 deployed in the CEP.


 As APIs are invoked

 1. CEP runs the queries and correctly evaluates which condition has
 been fulfilled .Say that we are invoking with the specified IP, then CEP
 will keep incrementing the counter related to IP based condition.

 2. Once the limit has reached, CEP publishes the condition which has
 been throttled out.

 3. When GW start to enforce throttling, it simply gets all the
 throttling conditions attached with the resource. So now the resource has
 two conditions attached - the default one and the ip based one.

 4. GW doesn’t determine which condition should be checked (If a request
 is made from a different destination GW should look at the default
 condition, but with the current implementation it doesn’t) . It simply
 checks if any of the conditions attached with the resource have been
 throttled out.


 Due to this, if one of the conditions engaged with the request gets
 throttled out, no additional request can make through the GW, until time
 duration elapses.


 This is a bug and we have to fix this, but we also have to be aware of
 the downsides of fixing this;

 If we are to correctly fix this,

 1. First at the GW, we have to determine which condition is applicable
 for the incoming request.

 2. To do this, 

Re: [Dev] [APIM] Issue while using Conditional Group

[Vanjikumaran Sivajothy]

The decision should be made at CEP level however, AFAIU GW has the some
kind filter before reaching to target destination. So isnt that the place
correctly match and evaluate ?

On Thu, Jun 16, 2016 at 5:50 PM, Amila De Silva  wrote:

> Hi Uvindra, Harsha,
>
> I don't think it's possible to get CEP do this. If we'd been calling CEP
> and waiting on its decision to let the request through, it would have been
> possible. Then for each request, CEP would evaluate the query and tell
> which conditions are applicable for that incoming request, and if the
> throttling quota defined by that policy has exceeded.
>
> With the current approach, what CEP does is, determining which counters
> should be incremented based on the published message and sending a message
> when any of the conditions have been throttled out. Gateway only have a
> bunch of throttled out keys, so it should have  a means of finding which
> keys are to be checked with each request.
>
> Rather than evaluating all the conditions for each request, we can
> optimise it (like first checking if any throttled out records are present
> for that API and then only evaluate the conditions), but the check needed
> to be done at the GW seems to be inevitable.
>
> On Thu, Jun 16, 2016 at 10:46 PM, Harsha Kumara  wrote:
>
>> Hi Amila,
>>
>> Are we going to evaluate the condition from the GW side? We will need to
>> check the possibility of doing this in CEP.  Otherwise it will performance
>> may degrade drastically. Again I'm doubt whether we can do it from the CEP
>> side as we publish set of data and take decisions based on the data coming
>> on the stream. It's independent of the request. Unless we have specific key
>> combination or identification pattern we won't be able to do it in the CEP
>> side as well.
>>
>> We will need to have a way to identify which condition group triggered
>> based on the data coming. Asynchronous behavior of data processing make it
>> harder to identify it from the CEP and transfer it to the gateway.
>>
>> Thanks,
>> Harsha
>>
>> On Sun, Jun 12, 2016 at 9:13 PM, Uvindra Dias Jayasinha > > wrote:
>>
>>> Hi Amila,
>>>
>>> I think it defeats the purpose if we need to evaluate conditions again
>>> on the GW side(GW starts to do part of the decision manager role), is it
>>> possible to fix this by asking CEP to provide the aggregate result of all
>>> the available conditions?
>>>
>>>
>>>
>>> On 11 June 2016 at 12:12, Amila De Silva  wrote:
>>>
 Hi All,

 This is related to the discussion had with Harsha on a particular
 behaviour observed when having Conditional Groups.

 Suppose we have a throttling policy like below;

 *default* - 1000 req/min

 *Condition* - 50 req/min if IP is 10.100.0.5


 The expected behaviour is, if requests are coming from 10.100.0.5, only
 to allow 50 req/min, but if coming from a different destination, allow 
 1000.

 But we observed that, when requests coming from 10.100.0.5 have been
 throttled out after utilising it’s full quota (50 req/min) , GW won’t
 accept any requests even from a different destination.


 While investigating the issue found that it was due to the way we
 enforce throttling at the GW.

 If we consider creating the above condition, then;

 1. Two Condition elements gets created (one for the default and the
 other for the actual condition) and get saved in the DB.

 2. Two execution plans are created to handle the conditions and are
 deployed in the CEP.


 As APIs are invoked

 1. CEP runs the queries and correctly evaluates which condition has
 been fulfilled .Say that we are invoking with the specified IP, then CEP
 will keep incrementing the counter related to IP based condition.

 2. Once the limit has reached, CEP publishes the condition which has
 been throttled out.

 3. When GW start to enforce throttling, it simply gets all the
 throttling conditions attached with the resource. So now the resource has
 two conditions attached - the default one and the ip based one.

 4. GW doesn’t determine which condition should be checked (If a request
 is made from a different destination GW should look at the default
 condition, but with the current implementation it doesn’t) . It simply
 checks if any of the conditions attached with the resource have been
 throttled out.


 Due to this, if one of the conditions engaged with the request gets
 throttled out, no additional request can make through the GW, until time
 duration elapses.


 This is a bug and we have to fix this, but we also have to be aware of
 the downsides of fixing this;

 If we are to correctly fix this,

 1. First at the GW, we have to determine which condition is applicable
 for the incoming 

Re: [Dev] [APIM] Issue while using Conditional Group

[Amila De Silva]

Hi Uvindra, Harsha,

I don't think it's possible to get CEP do this. If we'd been calling CEP
and waiting on its decision to let the request through, it would have been
possible. Then for each request, CEP would evaluate the query and tell
which conditions are applicable for that incoming request, and if the
throttling quota defined by that policy has exceeded.

With the current approach, what CEP does is, determining which counters
should be incremented based on the published message and sending a message
when any of the conditions have been throttled out. Gateway only have a
bunch of throttled out keys, so it should have  a means of finding which
keys are to be checked with each request.

Rather than evaluating all the conditions for each request, we can optimise
it (like first checking if any throttled out records are present for that
API and then only evaluate the conditions), but the check needed to be done
at the GW seems to be inevitable.

On Thu, Jun 16, 2016 at 10:46 PM, Harsha Kumara  wrote:

> Hi Amila,
>
> Are we going to evaluate the condition from the GW side? We will need to
> check the possibility of doing this in CEP.  Otherwise it will performance
> may degrade drastically. Again I'm doubt whether we can do it from the CEP
> side as we publish set of data and take decisions based on the data coming
> on the stream. It's independent of the request. Unless we have specific key
> combination or identification pattern we won't be able to do it in the CEP
> side as well.
>
> We will need to have a way to identify which condition group triggered
> based on the data coming. Asynchronous behavior of data processing make it
> harder to identify it from the CEP and transfer it to the gateway.
>
> Thanks,
> Harsha
>
> On Sun, Jun 12, 2016 at 9:13 PM, Uvindra Dias Jayasinha 
> wrote:
>
>> Hi Amila,
>>
>> I think it defeats the purpose if we need to evaluate conditions again on
>> the GW side(GW starts to do part of the decision manager role), is it
>> possible to fix this by asking CEP to provide the aggregate result of all
>> the available conditions?
>>
>>
>>
>> On 11 June 2016 at 12:12, Amila De Silva  wrote:
>>
>>> Hi All,
>>>
>>> This is related to the discussion had with Harsha on a particular
>>> behaviour observed when having Conditional Groups.
>>>
>>> Suppose we have a throttling policy like below;
>>>
>>> *default* - 1000 req/min
>>>
>>> *Condition* - 50 req/min if IP is 10.100.0.5
>>>
>>>
>>> The expected behaviour is, if requests are coming from 10.100.0.5, only
>>> to allow 50 req/min, but if coming from a different destination, allow 1000.
>>>
>>> But we observed that, when requests coming from 10.100.0.5 have been
>>> throttled out after utilising it’s full quota (50 req/min) , GW won’t
>>> accept any requests even from a different destination.
>>>
>>>
>>> While investigating the issue found that it was due to the way we
>>> enforce throttling at the GW.
>>>
>>> If we consider creating the above condition, then;
>>>
>>> 1. Two Condition elements gets created (one for the default and the
>>> other for the actual condition) and get saved in the DB.
>>>
>>> 2. Two execution plans are created to handle the conditions and are
>>> deployed in the CEP.
>>>
>>>
>>> As APIs are invoked
>>>
>>> 1. CEP runs the queries and correctly evaluates which condition has been
>>> fulfilled .Say that we are invoking with the specified IP, then CEP will
>>> keep incrementing the counter related to IP based condition.
>>>
>>> 2. Once the limit has reached, CEP publishes the condition which has
>>> been throttled out.
>>>
>>> 3. When GW start to enforce throttling, it simply gets all the
>>> throttling conditions attached with the resource. So now the resource has
>>> two conditions attached - the default one and the ip based one.
>>>
>>> 4. GW doesn’t determine which condition should be checked (If a request
>>> is made from a different destination GW should look at the default
>>> condition, but with the current implementation it doesn’t) . It simply
>>> checks if any of the conditions attached with the resource have been
>>> throttled out.
>>>
>>>
>>> Due to this, if one of the conditions engaged with the request gets
>>> throttled out, no additional request can make through the GW, until time
>>> duration elapses.
>>>
>>>
>>> This is a bug and we have to fix this, but we also have to be aware of
>>> the downsides of fixing this;
>>>
>>> If we are to correctly fix this,
>>>
>>> 1. First at the GW, we have to determine which condition is applicable
>>> for the incoming request.
>>>
>>> 2. To do this, some additional data has to be sent from KM side.
>>> Currently only condition name is sent, but we'll need the entire definition
>>> of the condition.
>>>
>>> 3. Since the current Admin Dashboard also allows, specifying JWT claims
>>> as conditions, while checking certain conditions we’d have to go to the
>>> extent of decoding the JWT and iterate through 

Re: [Dev] [APIM] Issue while using Conditional Group

[Harsha Kumara]

Hi Amila,

Are we going to evaluate the condition from the GW side? We will need to
check the possibility of doing this in CEP.  Otherwise it will performance
may degrade drastically. Again I'm doubt whether we can do it from the CEP
side as we publish set of data and take decisions based on the data coming
on the stream. It's independent of the request. Unless we have specific key
combination or identification pattern we won't be able to do it in the CEP
side as well.

We will need to have a way to identify which condition group triggered
based on the data coming. Asynchronous behavior of data processing make it
harder to identify it from the CEP and transfer it to the gateway.

Thanks,
Harsha

On Sun, Jun 12, 2016 at 9:13 PM, Uvindra Dias Jayasinha 
wrote:

> Hi Amila,
>
> I think it defeats the purpose if we need to evaluate conditions again on
> the GW side(GW starts to do part of the decision manager role), is it
> possible to fix this by asking CEP to provide the aggregate result of all
> the available conditions?
>
>
>
> On 11 June 2016 at 12:12, Amila De Silva  wrote:
>
>> Hi All,
>>
>> This is related to the discussion had with Harsha on a particular
>> behaviour observed when having Conditional Groups.
>>
>> Suppose we have a throttling policy like below;
>>
>> *default* - 1000 req/min
>>
>> *Condition* - 50 req/min if IP is 10.100.0.5
>>
>>
>> The expected behaviour is, if requests are coming from 10.100.0.5, only
>> to allow 50 req/min, but if coming from a different destination, allow 1000.
>>
>> But we observed that, when requests coming from 10.100.0.5 have been
>> throttled out after utilising it’s full quota (50 req/min) , GW won’t
>> accept any requests even from a different destination.
>>
>>
>> While investigating the issue found that it was due to the way we enforce
>> throttling at the GW.
>>
>> If we consider creating the above condition, then;
>>
>> 1. Two Condition elements gets created (one for the default and the other
>> for the actual condition) and get saved in the DB.
>>
>> 2. Two execution plans are created to handle the conditions and are
>> deployed in the CEP.
>>
>>
>> As APIs are invoked
>>
>> 1. CEP runs the queries and correctly evaluates which condition has been
>> fulfilled .Say that we are invoking with the specified IP, then CEP will
>> keep incrementing the counter related to IP based condition.
>>
>> 2. Once the limit has reached, CEP publishes the condition which has been
>> throttled out.
>>
>> 3. When GW start to enforce throttling, it simply gets all the throttling
>> conditions attached with the resource. So now the resource has two
>> conditions attached - the default one and the ip based one.
>>
>> 4. GW doesn’t determine which condition should be checked (If a request
>> is made from a different destination GW should look at the default
>> condition, but with the current implementation it doesn’t) . It simply
>> checks if any of the conditions attached with the resource have been
>> throttled out.
>>
>>
>> Due to this, if one of the conditions engaged with the request gets
>> throttled out, no additional request can make through the GW, until time
>> duration elapses.
>>
>>
>> This is a bug and we have to fix this, but we also have to be aware of
>> the downsides of fixing this;
>>
>> If we are to correctly fix this,
>>
>> 1. First at the GW, we have to determine which condition is applicable
>> for the incoming request.
>>
>> 2. To do this, some additional data has to be sent from KM side.
>> Currently only condition name is sent, but we'll need the entire definition
>> of the condition.
>>
>> 3. Since the current Admin Dashboard also allows, specifying JWT claims
>> as conditions, while checking certain conditions we’d have to go to the
>> extent of decoding the JWT and iterate through claims.
>>
>> Due to these checks, when conditional groups are used, users would have
>> to expect a performance drop.
>>
>> --
>> *Amila De Silva*
>>
>> WSO2 Inc.
>> mobile :(+94) 775119302
>>
>>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



-- 
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

Re: [Dev] [APIM] Issue while using Conditional Group

[Uvindra Dias Jayasinha]

Hi Amila,

I think it defeats the purpose if we need to evaluate conditions again on
the GW side(GW starts to do part of the decision manager role), is it
possible to fix this by asking CEP to provide the aggregate result of all
the available conditions?



On 11 June 2016 at 12:12, Amila De Silva  wrote:

> Hi All,
>
> This is related to the discussion had with Harsha on a particular
> behaviour observed when having Conditional Groups.
>
> Suppose we have a throttling policy like below;
>
> *default* - 1000 req/min
>
> *Condition* - 50 req/min if IP is 10.100.0.5
>
>
> The expected behaviour is, if requests are coming from 10.100.0.5, only to
> allow 50 req/min, but if coming from a different destination, allow 1000.
>
> But we observed that, when requests coming from 10.100.0.5 have been
> throttled out after utilising it’s full quota (50 req/min) , GW won’t
> accept any requests even from a different destination.
>
>
> While investigating the issue found that it was due to the way we enforce
> throttling at the GW.
>
> If we consider creating the above condition, then;
>
> 1. Two Condition elements gets created (one for the default and the other
> for the actual condition) and get saved in the DB.
>
> 2. Two execution plans are created to handle the conditions and are
> deployed in the CEP.
>
>
> As APIs are invoked
>
> 1. CEP runs the queries and correctly evaluates which condition has been
> fulfilled .Say that we are invoking with the specified IP, then CEP will
> keep incrementing the counter related to IP based condition.
>
> 2. Once the limit has reached, CEP publishes the condition which has been
> throttled out.
>
> 3. When GW start to enforce throttling, it simply gets all the throttling
> conditions attached with the resource. So now the resource has two
> conditions attached - the default one and the ip based one.
>
> 4. GW doesn’t determine which condition should be checked (If a request is
> made from a different destination GW should look at the default condition,
> but with the current implementation it doesn’t) . It simply checks if any
> of the conditions attached with the resource have been throttled out.
>
>
> Due to this, if one of the conditions engaged with the request gets
> throttled out, no additional request can make through the GW, until time
> duration elapses.
>
>
> This is a bug and we have to fix this, but we also have to be aware of the
> downsides of fixing this;
>
> If we are to correctly fix this,
>
> 1. First at the GW, we have to determine which condition is applicable for
> the incoming request.
>
> 2. To do this, some additional data has to be sent from KM side. Currently
> only condition name is sent, but we'll need the entire definition of the
> condition.
>
> 3. Since the current Admin Dashboard also allows, specifying JWT claims as
> conditions, while checking certain conditions we’d have to go to the extent
> of decoding the JWT and iterate through claims.
>
> Due to these checks, when conditional groups are used, users would have to
> expect a performance drop.
>
> --
> *Amila De Silva*
>
> WSO2 Inc.
> mobile :(+94) 775119302
>
>


-- 
Regards,
Uvindra

Mobile: 33962
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [APIM] Issue while using Conditional Group

[Amila De Silva]

Hi All,

This is related to the discussion had with Harsha on a particular behaviour
observed when having Conditional Groups.

Suppose we have a throttling policy like below;

*default* - 1000 req/min

*Condition* - 50 req/min if IP is 10.100.0.5


The expected behaviour is, if requests are coming from 10.100.0.5, only to
allow 50 req/min, but if coming from a different destination, allow 1000.

But we observed that, when requests coming from 10.100.0.5 have been
throttled out after utilising it’s full quota (50 req/min) , GW won’t
accept any requests even from a different destination.


While investigating the issue found that it was due to the way we enforce
throttling at the GW.

If we consider creating the above condition, then;

1. Two Condition elements gets created (one for the default and the other
for the actual condition) and get saved in the DB.

2. Two execution plans are created to handle the conditions and are
deployed in the CEP.


As APIs are invoked

1. CEP runs the queries and correctly evaluates which condition has been
fulfilled .Say that we are invoking with the specified IP, then CEP will
keep incrementing the counter related to IP based condition.

2. Once the limit has reached, CEP publishes the condition which has been
throttled out.

3. When GW start to enforce throttling, it simply gets all the throttling
conditions attached with the resource. So now the resource has two
conditions attached - the default one and the ip based one.

4. GW doesn’t determine which condition should be checked (If a request is
made from a different destination GW should look at the default condition,
but with the current implementation it doesn’t) . It simply checks if any
of the conditions attached with the resource have been throttled out.


Due to this, if one of the conditions engaged with the request gets
throttled out, no additional request can make through the GW, until time
duration elapses.


This is a bug and we have to fix this, but we also have to be aware of the
downsides of fixing this;

If we are to correctly fix this,

1. First at the GW, we have to determine which condition is applicable for
the incoming request.

2. To do this, some additional data has to be sent from KM side. Currently
only condition name is sent, but we'll need the entire definition of the
condition.

3. Since the current Admin Dashboard also allows, specifying JWT claims as
conditions, while checking certain conditions we’d have to go to the extent
of decoding the JWT and iterate through claims.

Due to these checks, when conditional groups are used, users would have to
expect a performance drop.

-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev