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? 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? 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? 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? 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? 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. Thanks, Leo _______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
