[
https://issues.apache.org/jira/browse/HADOOP-19346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901302#comment-17901302
]
ASF GitHub Bot commented on HADOOP-19346:
-----------------------------------------
xinglin commented on PR #7187:
URL: https://github.com/apache/hadoop/pull/7187#issuecomment-2501947487
> Oh so was this due to a correctness bug not performance that led you to
this? It wasn't very clear from the JIRA description.
yes, correctness issue: we are getting stale/incorrect reads from observer
nodes (fileLen=0 for non-zero bytes files which has been closed by the same
FileSystem object). We finally narrowed it down the RC: we are using two
different dfs clients/ObserverReadProxyProviders, though the key
(scheme/authority) to InnerCache.map.get() is the same.
Then, we compared trunk and our internal version. We found in our internal
version (based off 2.10.0), we don't have the lock to prevent concurrent
updates to InnerCache.map.
> ViewFileSystem.InnerCache: Replaced ReentrantReadWriteLock with
> ConcurrentHashMap/putIfAbsent()
> -----------------------------------------------------------------------------------------------
>
> Key: HADOOP-19346
> URL: https://issues.apache.org/jira/browse/HADOOP-19346
> Project: Hadoop Common
> Issue Type: Improvement
> Components: common
> Reporter: Xing Lin
> Assignee: Xing Lin
> Priority: Minor
> Labels: pull-request-available
>
> Use of ReentrantReadWriteLock + Map can be replaced/simplified with a
> ConcurrentHashMap.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
