[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765513#action_12765513
]
Don Brown commented on FELIX-1746:
----------------------------------
True, I looked deeper and yes, only one copy, but still, a copy per read. COW
is only slower if you write a lot more than you read, as it only takes one read
to equal things out. In looking at our startup, reads happen much, much more
than writes, even on though it is starting up, which makes sense because you
wouldn't write more services than you consume.
Regarding general locking, I certainly do prefer correct locking to the
alternative, as we've had our share of Felix concurrency issues in the past.
The 2.0 release is looking quite stable so far as our load and functional
tests, as well as multi-platform integration tests, are all showing consistent
green. Therefore, this seems to be a good time and update the locking strategy
to be a bit less conservative. For example, in one run, I saw a lot of
contention in ModuleImpl.getWires(), which again uses an instance lock for all
reads. I especially like your suggestion that you'll go through the code and
look for other places to apply the COW strategy :)
For resolution, I certainly would rather have this patch over nothing. The
consistent bottleneck is gone, which is what really matters in the end.
> 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.
