When to use OSGi EventAdmin, and when not?

I have a general question about using the OSGi EventAdmin service. I am currently using it in settings where potentially thousands of events can be generated per second. I am afraid the EventAdmin service might become a bottleneck. The initial results that I get from my profiler seem to support this. I have the following questions:

  • Is there a general rule when to use the EventAdmin service?
  • How do sendEvent and postEvent methods differ in terms of performance?
  • Is there a specific OSGi container that is known to have a low implementation of EventAdmin?

Thanks in advance for your support!

Cheers, Georg

+6
source share
1 answer

Do you have more information about the bottleneck you see?

We have an update for the Event Admin specification (see RFC 157 in [1]) to address some performance issues. But it is not completed yet.

Send an event is a synchronous send, so the calling thread is blocked until all listeners are notified. Most implementations use a caller stream. The message does not block the caller. It pauses for another thread to deliver the event. The current event manager specification requires ordering for asynchronous events, so this can lead to delays if an order is not required. RFC 157 provides the option to not require this order.

I have no data on whether one implementation was better or worse than another.

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

+6
source

Source: https://habr.com/ru/post/894770/


All Articles