[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765561#action_12765561
]
Karl Pauls commented on FELIX-1746:
-----------------------------------
Ok. Great. I will commit my patch, resolve this issue, and create a new one
which will reference this solution.
btw., I'm not convinced that your statement that service lookups will be "much,
much more" than writes is true in all cases. I have (and know about) scenarios
where the reverse is true. Granted, they are not your everyday "server
application with plugin-mechanism" but still, there are scenarios where lots of
services are provided but almost none looked-up (at least during startup).
I agree, however, that we should spend the time to look at updating the locking
where it makes sense. Interestingly, your observed ModuleImpl.getWires()
contention couldn't be addressed by a COW map as there can not be contention on
the wires in the first place (we hold the global lock when we use that
method). BUT, we use the this lock to protect it which is also used for other
methods (which are unreleated) - which is just plain stupid :-) Good example of
why I'm always advocating to go slowly when concurrency is involved - the
correct solution is probably to just remove the synchronized from the method
altogether or at least, make it use it's own lock and the contention will be
gone.
At any rate, thanks for all this good stuff. Keep it coming!
> 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, FELIX-1746.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.
