2016-05-17 3 views
2

Я новичок в сиддх, и я получил несколько вопросов:Сиддхов КЭП 3.x новичок вопросы

  1. Is 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. Как бы сиддхи масштабировался, если у меня много потоков и запросов?

Спасибо!

ответ

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

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

+0

Спасибо большое, это очень полезно! Любой план поддержки редактирования плана выполнения во время выполнения? Или вы думаете, что это бесполезно? – gembin

+0

Функция для быстрого развертывания действительно полезна, но мы скомпрометировали ее ради производительности. Если мы хотим поддерживать горячую замену запросов, должен быть механизм для предотвращения потери событий, которые были получены во время процесса замены. Это добавит слой кода к критическому пути выполнения. Если мы думаем о вероятности того, что кто-то планирует «горячую замену» планов исполнения во время выполнения в производственной системе, это очень минимально. Возможно, ноль даже. Таким образом, мы в основном торгуем. Именно по этой причине не следует использовать решение для быстрого развертывания. – Tishan

Смежные вопросы