Какие гарантии заказа предоставляются на вызовы ServiceListener и ServiceTracker? - PullRequest
5 голосов
/ 06 февраля 2010

Я пытаюсь понять, какие гарантии предоставляются для сервисных мероприятий.

Спецификация OSGi говорит, что ServiceEvents являются синхронными, я принял это к сведению, что ServiceListener не будет получать вызов serviceChanged () с UNREGISTERING ServiceEvent до тех пор, пока не завершится вызов serviceChanged () с ЗАРЕГИСТРИРОВАННЫМ ServiceEvent. Это правильно?

Я также посмотрел на источник для ServiceTracker. Кажется, он пытается справиться с ситуацией, когда эти два вызова serviceChanged () перекрываются. Возможно ли это?

Существуют ли аналогичные гарантии для звонков на ServiceTrackerCustomizer?

1 Ответ

1 голос
/ 06 февраля 2010

Это очень сложная проблема. Когда служба зарегистрирована в OSGi, событие обрабатывается, и все заинтересованные стороны уведомляются (прослушиватели службы, средства отслеживания служб и декларативное время выполнения службы). У каждой заинтересованной стороны есть возможность провести мероприятие. Обработка события может включать в себя регистрацию или отмену регистрации дополнительных услуг. Из-за синхронного поведения уведомления ServiceEvent эти события затем отправляются заинтересованным сторонам. В длинной цепочке зависимостей вы получаете дерево уведомлений, в котором вы регистрируете один сервис, и это приводит к тому, что целая куча новых парней регистрируется. Я знаю это, потому что это может сделать настройку производительности при запуске OSGi очень сложной задачей, поскольку ваш простой вызов службы регистрации был оплачен за активацию неизвестного числа служб.

Чтобы конкретно ответить на ваш вопрос, это не многопоточная забота о событиях, а повторная. То есть парень, который обрабатывает ваше событие в реестре, может обратиться к вам с другим уведомлением о событии до того, как будет обработано полное дерево. Это одна из причин, по которой они настоятельно рекомендуют вам никогда не регистрировать и не отменять регистрацию служб, удерживая блокировки, иначе вы можете заблокировать поток диспетчера событий. Другим хорошим способом обеспечения безопасности является наличие дерева зависимостей, а не графика. Круговые зависимости между пакетами, даже если классы компилируются, могут вызвать реальные проблемы.

Надеюсь, это поможет. Если вы хотите узнать больше о подобных вещах, выходит новая книга по OSGi и Equinox. Теперь он доступен для черновой резки и должен скоро появиться в печати. http://my.safaribooksonline.com/9780321561510

...