Когда использовать OSGi EventAdmin, а когда нет? - PullRequest
7 голосов
/ 11 августа 2011

У меня есть общий вопрос об использовании службы OSGi EventAdmin. В настоящее время я использую его в настройках, где потенциально тысячи событий могут быть созданы в секунду. Я боюсь, что сервис EventAdmin может стать узким местом. Начальные результаты, которые я получаю от своего профилировщика, кажется, подтверждают это. У меня есть следующие вопросы:

  1. Существует ли общее правило использования службы EventAdmin?
  2. Чем отличаются методы sendEvent и postEvent с точки зрения производительности?
  3. Существует ли конкретный контейнер OSGi, который, как известно, имеет низкоэффективную реализацию EventAdmin?

Заранее спасибо за вашу поддержку!

Cheers, Georg

1 Ответ

6 голосов
/ 11 августа 2011

У вас есть больше информации о узком месте, которое вы видите?

У нас есть обновление для спецификации администратора событий (см. RFC 157 в [1]), чтобы помочь решить некоторые проблемы с производительностью. Но это еще не законченная спецификация.

Событие отправки является синхронной отправкой, поэтому вызывающий поток блокируется до тех пор, пока все слушатели не будут уведомлены. В большинстве реализаций используется поток вызывающих. Сообщение события не блокирует звонящего. Он ставит в очередь работу для другого потока, чтобы доставить событие. Текущая спецификация Event Admin требует упорядочения для асинхронных событий, поэтому это может вызвать задержки, если упорядочивание не требуется. RFC 157 предоставляет возможность не требовать этого заказа.

У меня нет данных о том, является ли одна реализация раньше лучшей или хуже другой.

[1] http://www.osgi.org/Download/File?url=/download/osgi-4.3-early-draft2.pdf

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...