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