[
https://issues.apache.org/jira/browse/FELIX-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed FELIX-4638.
-----------------------------------
> Event Admin - Less locking on event handler timing
> --------------------------------------------------
>
> Key: FELIX-4638
> URL: https://issues.apache.org/jira/browse/FELIX-4638
> Project: Felix
> Issue Type: Improvement
> Components: Event Admin
> Reporter: Bob Paulin
> Assignee: Carsten Ziegeler
> Priority: Minor
> Fix For: eventadmin-1.4.4
>
> Attachments: FELIX-4638.patch, FELIX-4638b.patch, FELIX-4638c.patch
>
>
> 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.
> 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?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
