[
https://issues.apache.org/jira/browse/FELIX-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143195#comment-14143195
]
Bob Paulin commented on FELIX-4638:
-----------------------------------
Attached a new patch adding the timeout check back in to allow the task to run
in the calling thread. Did some testing with approaches that:
a) Run the blacklist handlers first
b) Run some checks to determine if it's worth it to put the task in the pool or
not.
Both approaches seemed to add in additional looping with each event that added
more overhead than benefit. I was thinking perhaps there might be a way to add
an optional priority value to each EventHandler and then sort them once when
they are registered. This would eliminate the looping on a per event basis.
If this is something we might want to look into I think it's probably a
separate JIRA however. Let me know what you think.
> 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)
