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. 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. > > 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
