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 <[email protected]> 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: 777733962
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
