4

私はシッディが初めてで、いくつか質問があります。

  1. SiddhiManagerはスレッドセーフですか? JVM ごとに 1 つの共有インスタンスを使用することをお勧めしますか?

  2. 実行時にストリームを定義してクエリを追加する方法は? 新しいExecutionPlanRuntimeインスタンスを作成するsiddhiManager.createExecutionPlanRuntime(plan)しかないようです。また、ストリームとクエリを再定義する方法は?

  3. QueryCallbackのinEvents とremoveEventsは何ですか?

    
 executionPlanRuntime.addCallback("query1", new QueryCallback() {
        @Override
        public void receive(long timeStamp, Event[] inEvents, Event[] removeEvents) {
            EventPrinter.print(timeStamp, inEvents, removeEvents);
        }
    });
  4. ストリームとクエリがたくさんある場合、Siddhi はどのようにスケーリングしますか?

ありがとう！

4

1 に答える 1

4
  1. はい。SiddhiManager はスレッド セーフであり、JVM ごとに 1 つの共有インスタンスを持つことをお勧めします。実際、これが WSO2 CEP での Siddhi Manager の使用方法です。
  2. Siddhi では、ストリーム定義 + クエリの組み合わせが実行計画と見なされます。createExecutionPlan メソッドを使用して再デプロイする以外に、Siddhi レベルで実行計画を編集する専用の方法はありません。これにより、新しい ExecutionPlanRuntime オブジェクトが取得されることに注意してください。したがって、古い入力ハンドラ参照を再利用することはできません。
  3. inEvents 配列は、Siddhi によって発行された現在のイベントを表し、removeEvents は、Siddhi によって発行された期限切れのイベントを表します
  4. 単一の実行プランに多くのクエリがある場合、Siddhi は非常にうまくスケーリングします。ただし、複数の実行計画でスケールアウトすると、実行計画ごとのリソース使用率がわずかに高くなり、パフォーマンスが低下するため、Siddhi はすぐにリソースのしきい値に達します。この [1] メールで説明されているように、最近、この制限に対処するための改善を行いました。改善は master ブランチで利用できます。

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

于 2016-05-23T10:24:06.070 に答える