felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Event Admin: Sync Event Blacklist timing
Date Tue, 16 Sep 2014 15:30:42 GMT
Hi Bob,

yes, I agree using a CountDownLatch seems to be the better option. I'm not
sure about the JMX timings though.
However, with your patch in place, there is a difference in blacklisting.
Right now, a handler is blacklisted immediately if the timeout is reached,
this avoids sending new events to that handler, while the current event is
still processed by other handlers. With your patch, the handler is only
blacklisted once it's finished (at least I think this is the case)


2014-09-15 16:02 GMT+02:00 Bob Paulin <bob@bobpaulin.com>:

> The locking that is done for the blacklist timing seems to degrade
> performance significantly Felix is under stress with multiple firing
> handler callbacks for each event.  I'd like to discuss an alternative
> approach with less locking that still  guarantees proper event ordering per
> the OSGi spec.  Basically instead of using the CyclicBarriers (Rendezvous)
> on a per handler basis we could use a count down latch to only await after
> all handlers are complete. Then instead of using a stopwatch based timer
> the JMX Current Thread Cpu Time which counts CPU time for the application
> code and any IO performed on it's behalf filtering out time context
> switching between threads to provide proper blacklisting.  I've created
> FELIX-4638 with a patch.
> Here are my test results.
> Baseline(Event Admin 1.4.2):
> 15 Threads
> 100000 Async Events per Thread
> 7 Active Handlers per Event
> For a total of 10500000 Handler Events Executed in 40000 - 45000ms
> With the same parameters above but a CountDownLatch I see the execution
> time drop to around 25000ms.   The improvement is noticeable because the
> stress test includes 7 active handlers per event.  The improvement is less
> noticeable with applications that only register one or 2 handlers for an
> active event such as in the PerformanceTestIT.  Thoughts on changing how
> this locking occurs? Concerns with using the JMX timings?
> - Bob

Carsten Ziegeler
Adobe Research Switzerland

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message