4

I'm new to Siddhi, and I got several questions:

  1. Is SiddhiManager thread safe? Is it a good practice one shared instance per JVM?

  2. How to define stream and add query at runtime? It seems it only has siddhiManager.createExecutionPlanRuntime(plan) which will create a new ExecutionPlanRuntime instance. And how to redefine stream and query?

  3. What's inEvents and removeEvents in QueryCallback?

    
 executionPlanRuntime.addCallback("query1", new QueryCallback() {
        @Override
        public void receive(long timeStamp, Event[] inEvents, Event[] removeEvents) {
            EventPrinter.print(timeStamp, inEvents, removeEvents);
        }
    });
  4. How would Siddhi scale, if I have lots of stream and queries?

Thanks!

gembin
  • 136
  • 1
  • 6

1 Answers1

4
  1. Yes. SiddhiManager is Thread safe and it is a good practice to have one shared instance per JVM. In-fact that is how Siddhi Manager is used in WSO2 CEP.
  2. In Siddhi stream definition + query combination is considered as an Execution Plan. There is no dedicated way to edit an execution plan at Siddhi level other than re-deploying that using createExecutionPlan method. Please note that you will get a new ExecutionPlanRuntime object by this. Hence can not reuse old input handler references.
  3. inEvents array represents current-events emitted by Siddhi and removeEvents represent expired-events emitted by Siddhi
  4. Siddhi will scale quite well if you have lot of queries in single execution plan. But when scaling out with multiple execution plans Siddhi will hit the resource threshold quickly since resource utilization is little high per execution plan which will result in performance degredation. Recently we made an improvement to address this limitation as explained in this[1] mail. Improvement is available in master branch.

[1] http://wso2-oxygen-tank.10903.n7.nabble.com/Siddhi-Making-Disruptor-configurable-td136499.html

Tishan
  • 890
  • 6
  • 11
  • Thanks a lot, it's really helpful! Any plan to support edit an execution plan at runtime? Or you think this is useless perhaps? – gembin Jun 14 '16 at 08:49
  • Feature to hot deploy is indeed useful, but we have compromised it for the sake of performance. If we are to support hot query swapping there should be a mechanism to prevent loosing events which received during swapping process. This will add a layer of code to the critical path of execution. If we think about the probability of someone hot swapping execution plans at runtime in a production system, it is very minimal. Perhaps zero even. So we are basically trading off. That is the reason behind not pursuing a hot deploy solution. – Tishan Jun 15 '16 at 12:30