2016-05-17 15 views
2

Ich bin neu in Siddhi, und ich habe einige Fragen:Siddhi CEP 3.x newbie Fragen

  1. Ist SiddhiManager Thread-sicher? Ist es eine bewährte Methode, eine gemeinsame Instanz pro JVM zu verwenden?
  2. Wie definiert man einen Stream und fügt eine Abfrage zur Laufzeit hinzu? Es scheint nur siddhiManager.createExecutionPlanRuntime (Plan), die eine neue ExecutionPlanRuntime Instanz erstellen wird. Und wie Stream und Abfrage neu zu definieren?

  3. Was ist inEvents und removeEvents in QueryCallback?

     
    
    executionPlanRuntime.addCallback("query1", new QueryCallback() { 
         @Override 
         public void receive(long timeStamp, Event[] inEvents, Event[] removeEvents) { 
          EventPrinter.print(timeStamp, inEvents, removeEvents); 
         } 
        }); 
    
  4. Wie würde Siddhi skalieren, wenn ich viele Streams und Abfragen habe?

Vielen Dank!

Antwort

2
  1. Ja. SiddhiManager ist Thread sicher und es ist eine gute Praxis, eine gemeinsame Instanz pro JVM zu haben. In der Tat wird Siddhi Manager in WSO2 CEP verwendet.
  2. In Siddhi Stream Definition + Abfrage Kombination wird als Execution Plan betrachtet. Es gibt keine dedizierte Möglichkeit, einen Ausführungsplan auf der Siddhi-Ebene zu bearbeiten, außer das mit der createExecutionPlan-Methode erneut zu implementieren. Bitte beachten Sie, dass Sie dadurch ein neues ExecutionPlanRuntime-Objekt erhalten. Daher können alte Eingabe- Handler-Referenzen nicht wiederverwendet werden.
  3. inEvents Array stellt Strom-Ereignisse, die von Siddhi emittiert und removeEvents repräsentieren abgelaufen-Ereignisse, die von Siddhi emittiert
  4. Siddhi recht gut skalieren, wenn Sie viele Anfragen in Einzel Ausführungsplan haben. Aber beim Skalieren mit mehreren Ausführungsplänen wird Siddhi den Ressourcenschwellenwert schnell erreichen, da die Ressourcenauslastung pro Ausführungsplan wenig hoch ist, was zu einer Leistungsverschlechterung führt. Vor kurzem haben wir eine Verbesserung vorgenommen, um diese Einschränkung zu beheben, wie in dieser [1] Mail erläutert. Die Verbesserung ist in der Verzweigung des Masters verfügbar.

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

+0

Vielen Dank, es ist wirklich hilfreich! Möchten Sie einen Ausführungsplan zur Laufzeit bearbeiten? Oder denkst du, das ist vielleicht nutzlos? – gembin

+0

Feature zu Hot Deploy ist in der Tat nützlich, aber wir haben es aus Gründen der Leistung kompromittiert. Wenn wir den Austausch von Hot Query unterstützen wollen, sollte es einen Mechanismus geben, der verhindert, dass Ereignisse verloren gehen, die während des Swapping-Prozesses empfangen wurden. Dadurch wird dem kritischen Ausführungspfad eine Codeebene hinzugefügt. Wenn wir über die Wahrscheinlichkeit nachdenken, dass jemand Ausführungspläne zur Laufzeit in einem Produktionssystem austauschen kann, ist das sehr gering. Vielleicht sogar null. Also handeln wir im Prinzip miteinander. Dies ist der Grund dafür, dass keine Hot-Deployment-Lösung verfolgt wird. – Tishan