On Fri, Jun 7, 2013 at 12:49 PM, Nuwan Dias <[email protected]> wrote: > On Fri, Jun 7, 2013 at 12:28 PM, Sriskandarajah Suhothayan > <[email protected]>wrote: > >> >> >> >> 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. >> > > How about the latency concerns? We will need to call CEP on every > invocation and this can add to the latency. Latency can be minimized by > using Thrift as the transport but we have faced issues in the past when > running a Thrift server behind an LB (ELB) and so on. So we will need to > take these into consideration as well and come up with a proper solution. >
IMHO thrift will be the best option here as we have tested for its performance and it also have its own load balancing solution, hence I don't think we need to use an ELB between the APIM and CEP and we can use the same approach used for connecting APIM with BAM Thanks Suho Thanks, NuwanD. > > 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 > > > > > -- > Nuwan Dias > > Senior Software Engineer - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > > _______________________________________________ > 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
