felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-1746) Eliminate contention on ServiceRegistry.getServiceReferences(String, Filter)
Date Wed, 14 Oct 2009 09:46:31 GMT

    [ https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765491#action_12765491

Karl Pauls commented on FELIX-1746:

Well, I don't think it does two copies on every read. It only does one as the values() method
result is just a wrapper around the map. I agree that it needs to get the same lock twice
but as it is doing that in two calls directly after each other the JIT should lift that into
just one. 

As almost always when taking about concurrency, its not that easy to reason about the best
solution. In this case, the copy-on-write will shift the burden to the registration of services
which might equally impact performance on startup... 

Regarding your statement that Felix goes a bit crazy with synchronization, it is true that
we spend a lot of time to get synchronization and locking correct. I think we are finally
close to a framework that does lock correctly (a lot more correctly than some other frameworks
I know of - thats for sure) which is why I need more time to look into your patch and try
to test it with real live examples to see what its impacts really are. For example, while
it is true that the edge-case change in alt2 is orthogonal and would need to be made to both
patches, it just goes to show that it really hard to ensure we don't introduce bugs for other
scenarios when we make changes like this.

I'm not against introducing a COW map and going with your patch but I need more time to investigate
the impact it might have. 

Question is, should I go ahead and apply my patch (as I wouldn't have a big problem with making
it part of the next 2.0.2 release) and we keep this issue to investigate a more concurrent
COW map based implementation for a future 2.2.0 release (probably that would include looking
into other places where we could benefit from a COW map inside the framework)? Alternatively,
we can just do nothing for now and I will try to find the time to look into your patch some
more first?

> Eliminate contention on ServiceRegistry.getServiceReferences(String, Filter)
> ----------------------------------------------------------------------------
>                 Key: FELIX-1746
>                 URL: https://issues.apache.org/jira/browse/FELIX-1746
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: felix-2.0.0
>            Reporter: Jed Wesley-Smith
>            Assignee: Karl Pauls
>         Attachments: blocked-threads.gif.jpg, FELIX-1746-alt.patch, FELIX-1746-alt2.patch,
> Performance testing has shown that there is significant contention on the ServiceRegistry
object's monitor during startup. This is caused by Spring DM making lots of calls to the synchronized
method ServiceRegistry.getServiceReferences(String, Filter). This method is synchronized in
order to protect the m_serviceRegsMap HashMap, but the method does a lot more work than simply
accessing the map.
> Propose changing the ServiceRegistry to use a thread-safe Map implementation that does
not require external synchronization, in particular a CopyOnWriteMap. I will add a patch that
includes a CopyOnWriteMap implementation.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message