何时使用 OSGi EventAdmin，何时不使用？
我有一个关于 OSGi EventAdmin 服务的使用的一般性问题。我目前在每秒可能生成数千个事件的设置中使用它。我担心 EventAdmin 服务可能是一个瓶颈。我从分析器中得到的初步结果似乎支持这一点。我的问题是：
- 何时使用 EventAdmin 服务是否有一般经验法则？
- sendEvent 和 postEvent 方法在性能方面有何不同？
- 是否存在已知具有低性能 EventAdmin 实现的特定 OSGi 容器？
预先感谢您的支持！
干杯， 格奥尔格
I have a general question regarding the usage of the OSGi EventAdmin service. I'm currently using it in a setting where potentially thousands of events can be generated per second. My fear is that the EventAdmin service might be a bottleneck. Initial results I get from my profiler seem to support this. The questions I have are:
- Is there a general rule of thumb when to use the EventAdmin service?
- How do the sendEvent and postEvent methods differ in terms of performance?
- Is there a particular OSGi container which is known to have a low performing EventAdmin implementation?
Thanks in advance for your support!
Cheers,
Georg
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否有关于您所看到的瓶颈的更多信息？
我们即将对事件管理规范进行更新（请参阅 [1] 中的 RFC 157），以解决一些性能问题。但这还没有完成规范工作。
发送事件是同步发送，因此调用线程会阻塞，直到所有侦听器都收到通知。大多数实现都使用调用者线程。发布事件不会阻止调用者。它将工作排队等待另一个线程传递事件。当前的事件管理规范要求对异步事件进行排序，因此如果不需要排序，这可能会导致延迟。 RFC 157 提供了不需要此排序的能力。
我没有关于之前的一种实现是否比另一种实现更好或更差的数据。
[1] http://www.osgi.org/Download/文件?url=/download/osgi-4.3-early-draft2.pdf
Do you have more information about the bottleneck you see?
We have an update coming for the Event Admin spec (see RFC 157 in [1]) to aid some performance issues. But this is not completed spec work yet.
Send event is a synchronous send, so the calling thread blocks until all listeners have been notified. Most implementations use the callers thread. Post event does not block the caller. It queues the work for another thread to deliver the event. The current Event Admin spec requires ordering for async events, so this can cause delays if ordering is not required. RFC 157 provides the ability to not require this ordering.
I have no data on whether one implementation before better or worse than another.
[1] http://www.osgi.org/Download/File?url=/download/osgi-4.3-early-draft2.pdf