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 <ami...@wso2.com> 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 <hars...@wso2.com> 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 <uvin...@wso2.com >> > 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 <ami...@wso2.com> 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 > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
