[
https://issues.apache.org/jira/browse/CASSANDRA-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1370:
--------------------------------------
Affects Version/s: (was: 0.6.4)
0.6
Fix Version/s: 0.7.1
0.6.9
Assignee: Brandon Williams
Also: getWriteEndpoints calls getPendingRanges twice when it is not empty;
cheaper to save the first result.
> TokenMetaData.getPendingRangesMM() is unnecessarily synchronized
> ----------------------------------------------------------------
>
> Key: CASSANDRA-1370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1370
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.6
> Reporter: Jason Fager
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6.9, 0.7.1
>
>
> TokenMetaData.getPendingRangesMM() is currently synchronized to avoid a race
> condition where multiple threads might create a multimap for the given table.
> However, the pendingRanges instance variable that's the subject of the race
> condition is already a ConcurrentHashMap, and the race condition can be
> avoided by using putIfAbsent, leaving the case where the table's map is
> already initialized lock-free:
> private Multimap<Range, InetAddress> getPendingRangesMM(String table)
> {
> Multimap<Range, InetAddress> map = pendingRanges.get(table);
> if (map == null)
> {
> map = HashMultimap.create();
> Multimap<Range, InetAddress> fasterHorse
> = pendingRanges.putIfAbsent(table, map);
> if(fasterHorse != null) {
> //another thread beat us to creating the map, oh well.
> map = fasterHorse;
> }
> }
> return map;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
