Hi All, these questions and answers are very educating. Shall we add them to our doc FAQs?
Thanks, Samisa... Samisa Abeysinghe Vice President Developer Evangelism WSO2 Inc. http://wso2.com On Mon, Mar 10, 2014 at 1:14 PM, Srinath Perera <[email protected]> wrote: > Hi Leo, > > Let me add couple of words as well > > > On Mon, Mar 10, 2014 at 9:16 AM, Sriskandarajah Suhothayan > <[email protected]>wrote: > >> Thanks for you interest in WSO2 CEP & Siddhi >> >> Sorry for the late reply, I some how missed the mail >> >> >> On Fri, Mar 7, 2014 at 4:48 AM, Leo Romanoff <[email protected]> wrote: >> >>> Hi, >>> >>> I've started playing with WSO2 CEP recently and after some experiments >>> with it I collected a few questions, which I cannot answer by reading the >>> docs. Hopefully I'll have them answered by posting them on this list. >>> >>> First of all, some background information. I have some previous >>> experience with Esper and Drools. Currently, I'm mostly interested in using >>> Siddhi in embedded mode, i.e. as a library. I could built a few small test >>> projects using it without any serious problems. But now I'm trying to >>> understand some more complex things about it. >>> >>> So, here are my questions: >>> >>> 1) How many rules/queries can be defined in one engine. How does it >>> affect performance? >>> >>> For example, can I define (tens of) thousands of queries using the >>> same (or multiple) instance of SiddhiManager? Would it make processing much >>> slower? Or is the speed not proportional to the number of queries? E.g. >>> when a new event arrives, does Siddhi test it in a linear fashion against >>> each query or does Siddhi keep an internal state machine that tries to >>> match an event against all rules at once? >>> >> >> SiddhiManager can have many queries, and if you chain the queries in a >> liner fashion then all those queries will be executed one after the other >> and you might see some performance degradation, but if you have have then >> parallel then there wont be any issues. >> >> >>> >>> 2) Is it possible to easily disable/enable some queries? >>> >>> In my use-cases I have a lot of queries. Actually, I have a lot of >>> tenants and each tenant may have something like 10-100 queries. Rather >>> often (e.g. few times a day), tenants would like to disable/enable some of >>> their queries. What is a proper way to do it? Is it a costly operation, >>> i.e. does Siddhi need to perform a lot of processing to disable or enabled >>> a query? >>> Is it better to keep a dedicated SiddhiManager instance per tenant or is >>> it OK to have one SiddhiManager instance which handles all those tenants >>> with all their queries? >>> >>> The general norm is, you have to use a SiddhiManager per scenario, where >> each scenario might contain one or more queries, with this modal its easy >> if any tenant want to add a remove a scenario and it will not affect other >> queries and tenants. >> >> 3) What is the semantics of distributed execution? I have found that >>> Siddhi supports it by means of Hazelcast. But what does distributed >>> execution means? E.g. what happens when I feed in an event at one of the >>> instances? How can this distributed execution be controlled besides >>> enabling/disabling it? >>> >>> Currently Siddhi share its states among its different nodes via >> Hazelcast. We are currently working on alternative ways to improve its >> distribution capability. >> > > We found hazelcast is too slow for distributed processing. We are working > on a storm based model, see "WSO2 CEP/Siddhi Storm Integration" thread > some time back. This should come out Q2/Q3. > >> >> 4) What is the semantics of async processing? I have found >>> "setAsyncProcessing" method, but what would be the effect of enabling this >>> kind of processing as compared to the usual way of operation? What are the >>> benefits and what are the drawbacks? When should it be used? >>> >> >> By default Siddhi uses the request thread to do the event processing, but >> if you want to handover the data to another thread process then you can >> enable async processing. Its useful if you are doing very complex time >> consuming process using Siddhi. >> > > If you do this, event are processed by placing them in a queues between > any two queries and assigning threads to queries. However, we found often > single thread (async model is faster). > >> >>> 5) I figured out that Siddhi can persist its state and later on restore >>> it. This is a cool feature, but I'd like to understand better what kind of >>> information is being persisted. Is it only events whose processing is not >>> finished yet? Does it include a set of queries currently defined in a >>> given SiddhiManager? Does it include all of SiddhiManager's settings? What >>> kind of information is restored and what kind of information should be >>> provided again in addition to restored one? What is a typical situation >>> when Siddhi persistence could/should be used? >>> >>> >>> It only stores the state information of the processing, E.g the current >> running Avg of the average calculation. This will be used when server >> recovers from a failure. >> >> >>> I hope that most of my questions are pretty simple to answer for those, >>> who are familiar with Siddhi's architecture and its inner workings. >>> >>> >> Hope these information is very useful. >> >> >> Regards, >> Suho >> >> Thanks, >>> Leo >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> >> -- >> >> *S. Suhothayan * >> Associate Technical Lead, >> *WSO2 Inc. *http://wso2.com >> * <http://wso2.com/>* >> lean . enterprise . middleware >> >> >> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter: >> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
