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 <[email protected]> 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 <[email protected]> > 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 <[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 >> > > > > -- > Harsha Kumara > Software Engineer, WSO2 Inc. > Mobile: +94775505618 > Blog:harshcreationz.blogspot.com > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
