On Fri, Jun 7, 2013 at 8:12 AM, Supun Malinga <[email protected]> wrote:
> > > > On Thu, Jun 6, 2013 at 11:37 PM, Sanjeewa Malalgoda <[email protected]>wrote: > >> >> >> On Thu, Jun 6, 2013 at 3:28 PM, Sriskandarajah Suhothayan >> <[email protected]>wrote: >> >>> >>> >>> >>> On Thu, Jun 6, 2013 at 3:10 PM, Vijayaratha Vijayasingam < >>> [email protected]> wrote: >>> >>>> Hi; >>>> APIM team has different kind of throttling+rate limiting requirements >>>> (eg:ip/timer/geo based)..As Srinath pointed we believe that CEP would be >>>> the right solution, since we cannot have all these different >>>> scenarios/requirements to be implemented in our throttling module.. >>>> Is there any possibility integrate CEP engine with our throttling >>>> module ? >>>> >>> >>> Yes this is possible >>> Currently you can use Siddhi directly to achieve this. In this case you >>> have to pass all the events the trigger throttling directly to Siddhi and, >>> when a matching throttling condition reached CEP will fire an output back >>> to APIM so that it can take action based on the CEP's response. >>> >> +1 >> AFAIU there are 2 options. We need CEP running out of API manager and AM >> or any other server and it sends request stats to CEP. Then CEP will notify >> throttle handler after some incident happens. Then throttle handler will >> throttle out requests. Or we can install necessary features in AM and let >> it handle inside AM. When we have multiple nodes requests hits to all >> servers should take into account while doing throttling calculations. >> >> If we consider approach 1 mentioned we might need >> 01. Data publisher to CEP >> 02. Event listener at AM to listen CEP alert >> 03. Need to update throttle component to work according to CEP alerts. >> Also we need to replicate throttle data across all nodes when we have >> clustered setup. >> >> Next approach would be running siddhi based throttle module in each node. >> In that case each server need to aware about the status of other nodes in >> the cluster and do throttle calculation by considering status of all nodes. >> I think CEP can handle this situation now. >> > > Also in clustered mode we currently have lack of support on the throttling > on the cluster wide. This means when we ad a throttling rule it will be > applied to individual node, but the throttled request data is not synced in > the cluster nodes. So all nodes will end up allowing the specified > bandwidth and the resultant throttling bandwidth will be initial amount > into the number of nodes in the cluster. So we need to address that here at > initial stages. That's a very useful requirement for the whole platform IMO. > > As Sanjeewam mentioned we have two ways to solve this, either by embedded Siddhi or with external CEP I believe we should have both the implementations, We should have a proper interface for throttling engine and we can have two throttling engine implementations 1. embedded Siddhi 2. external CEP in the standalone mode and for simple setups we can run with mode 1, and for clustered scenarios we can run on mode 2 +1 to start with the external CEP as it solves clustering issues Thanks Suho thanks, > > >> >> Thanks, >> Sanjeewa. >> >>> >>> With CEP 3.0.0 we are writing an Event Processor component( as of mail >>> thread "CEP 3.0 towards a Complete eventing solution to the platform"), >>> when that is done you will also be able to provide a proper UI for the >>> users to edit Siddhi throttling queries >>> >>> >>> So, all products can still use throttling module, which can handle all >>>> the complex rate/thorrtling policies.. >>>> >>> >>> +1 >>> >>> >>> Suho >>> >>> >>> >>>> Thanks >>>> >>>> >>>> On 5 June 2013 15:13, Sriskandarajah Suhothayan <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jun 5, 2013 at 1:27 AM, Srinath Perera <[email protected]>wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Currently we have a java based throttling solution. But we need that >>>>>> to extended (e.g. support throughput based throttling), and support more >>>>>> complicated condition that currently parameterized. >>>>>> >>>>>> IMO, best way to do this is to support this by integrating CEP >>>>>> (Siddhi) engine directly at java level. It is very light weight . We can >>>>>> let users provide CEP queries which will control throttling. Basically, >>>>>> there will be inbuilt event stream definitions, and Siddhi listener that >>>>>> monitors a given event stream and adjust event acceptance. Users provide >>>>>> CEP queries. >>>>>> >>>>>> I think it is too heavy publish events via thrift API if we try to >>>>>> send it via the network. >>>>>> >>>>>> WDYT? >>>>>> >>>>> +1 >>>>> CEP team can provide the necessary support >>>>> if any of the product teams (eg: ELB, BPS, AF or AM) is willing to >>>>> replace their current or have an alternate throttling module >>>>> >>>>> Suho >>>>> >>>>>> >>>>>> --Srinath >>>>>> >>>>>> -- >>>>>> ============================ >>>>>> Srinath Perera, Ph.D. >>>>>> Director, Research, WSO2 Inc. >>>>>> Visiting Faculty, University of Moratuwa >>>>>> Member, Apache Software Foundation >>>>>> Research Scientist, Lanka Software Foundation >>>>>> Blog: http://srinathsview.blogspot.com/ >>>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>>> Phone: 0772360902 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *S. Suhothayan >>>>> * >>>>> Software Engineer, >>>>> Management Committee Member, Data Technologies Team, >>>>> *WSO2 Inc. *http://wso2.com * >>>>> <http://wso2.com/>* >>>>> lean . enterprise . middleware >>>>> >>>>> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >>>>> twitter: http://twitter.com/suhothayan | linked-in: >>>>> http://lk.linkedin.com/in/suhothayan* >>>>> * >>>>> * >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> -Ratha >>>> mobile: (+94)755906608 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *S. Suhothayan >>> * >>> Associate Technical Lead, >>> >>> Management Committee Member, Data Technologies Team, >>> *WSO2 Inc. *http://wso2.com * >>> <http://wso2.com/>* >>> lean . enterprise . middleware >>> >>> >>> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >>> twitter: http://twitter.com/suhothayan | linked-in: >>> http://lk.linkedin.com/in/suhothayan* >>> * >>> * >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> * >> * >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Supun Malinga, > > Senior Software Engineer, > WSO2 Inc. > http://wso2.com > http://wso2.org > email - [email protected] <[email protected]> > mobile - 071 56 91 321 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *S. Suhothayan * Associate Technical Lead, Management Committee Member, Data Technologies Team, *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan* * *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
