Siddhi CEP 3.x вопросы для новичков

Я новичок в Сиддхи, и у меня есть несколько вопросов:

  1. Является ли SiddhiManager потокобезопасным? Является ли хорошей практикой один общий экземпляр на каждую JVM?

  2. Как определить поток и добавить запрос во время выполнения? Похоже, у него есть только siddhiManager.createExecutionPlanRuntime (plan), который создаст новый экземпляр ExecutionPlanRuntime. А как переопределить поток и запрос?

  3. Что такое inEvents и removeEvents в QueryCallback?

    
 executionPlanRuntime.addCallback("query1", new QueryCallback() {
        @Override
        public void receive(long timeStamp, Event[] inEvents, Event[] removeEvents) {
            EventPrinter.print(timeStamp, inEvents, removeEvents);
        }
    });
  4. Как будет масштабироваться Сиддхи, если у меня много потоков и запросов?

Спасибо!


siddhi
person gembin    schedule 17.05.2016    source источник

Ответы (1)


arrow_upward
4
arrow_downward

  1. да. SiddhiManager является потокобезопасным, и рекомендуется иметь один общий экземпляр на каждую JVM. Фактически, именно так Siddhi Manager используется в WSO2 CEP.
  2. В Сиддхи комбинация «определение потока + запрос» рассматривается как план выполнения. Не существует специального способа редактирования плана выполнения на уровне Сиддхи, кроме повторного развертывания с использованием метода createExecutionPlan. Обратите внимание, что при этом вы получите новый объект ExecutionPlanRuntime. Следовательно, нельзя повторно использовать старые ссылки на обработчик ввода.
  3. Массив inEvents представляет текущие события, генерируемые Siddhi, а removeEvents - события с истекшим сроком, генерируемые Siddhi.
  4. Сиддхи будет хорошо масштабироваться, если у вас много запросов в одном плане выполнения. Но при горизонтальном масштабировании с несколькими планами выполнения Siddhi быстро достигнет порогового значения ресурсов, поскольку использование ресурсов для каждого плана выполнения является небольшим, что приведет к снижению производительности. Недавно мы улучшили это ограничение, как описано в этом письме [1]. Улучшение доступно в основной ветке.

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

person Tishan    schedule 23.05.2016
comment
Большое спасибо, это действительно помогло! Есть ли план поддержки редактирования плана выполнения во время выполнения? Или вы думаете, что это бесполезно? - person gembin; 14.06.2016
comment
Функция горячего развертывания действительно полезна, но мы скомпрометировали ее ради производительности. Если мы хотим поддерживать замену горячих запросов, должен быть механизм, предотвращающий потерю событий, полученных во время процесса замены. Это добавит уровень кода к критическому пути выполнения. Если мы подумаем о вероятности горячей замены планов выполнения во время выполнения в производственной системе, она очень минимальна. Возможно, даже ноль. Так что мы в основном торгуем. Это причина отказа от решения для горячего развертывания. - person Tishan; 15.06.2016