[
https://issues.apache.org/jira/browse/HADOOP-12475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959829#comment-14959829
]
Chris Nauroth commented on HADOOP-12475:
----------------------------------------
[~sjlee0], don't worry. It's not just you. Hence all of the discussions about
getting rid of CHANGES.txt and automating it instead. :-)
Attribution in CHANGES.txt should fall under the earliest release that is
receiving the patch, and it should be consistent across all live branches. If
the patch is targeted to 2.8.0, then its CHANGES.txt entry would go in the
2.8.0 section on trunk and branch-2. If the patch is targeted to 2.7.2, then
its CHANGES.txt entry would go in the 2.7.2 section on trunk, branch-2 and
branch-2.7.
Another interesting case is when a patch gets selected for backporting to a
maintenance line. Suppose a patch initially targets 2.8.0, but then later
becomes a candidate for 2.7.2. On the initial commit, it would have been
listed under the 2.8.0 section on trunk and branch-2. After the decision to
backport to 2.7.2, we'd have to go back and update CHANGES.txt on all branches
to match reality, so we'd have to move it to the 2.7.2 section on trunk,
branch-2 and branch-2.7.
I hope this helps.
> Replace guava Cache with ConcurrentHashMap for caching Connection in ipc
> Client
> -------------------------------------------------------------------------------
>
> Key: HADOOP-12475
> URL: https://issues.apache.org/jira/browse/HADOOP-12475
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: conf, io, ipc
> Reporter: Walter Su
> Assignee: Walter Su
> Fix For: 2.8.0
>
> Attachments: HADOOP-12475.01.patch, HADOOP-12475.02.patch,
> HADOOP-12475.03.patch
>
>
> quote [~daryn] from HADOOP-11772:
> {quote}
> CacheBuilder is obscenely expensive for concurrent map, and it requires
> generating unnecessary garbage even just to look up a key. Replace it with
> ConcurrentHashMap.
> I identified this issue that impaired my own perf testing under load. The
> slowdown isn't just the sync. It's the expensive of Connection's ctor
> stalling other connections. The expensive of ConnectionId#equals causes
> delays. Synch'ing on connections causes unfair contention unlike a sync'ed
> method. Concurrency simply hides this.
> {quote}
> BTW, guava Cache is heavyweight. Per local test, ConcurrentHashMap has better
> overal performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
