[
https://issues.apache.org/jira/browse/HDFS-14822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924633#comment-16924633
]
Chao Sun commented on HDFS-14822:
---------------------------------
Thanks [~vagarychen]. Yes, this looks OK to me as well. Seems 3) is most
relevant here. By reading the code, it looks to me that the {{FSEditLog#txnId}}
is updated as part of a write operation, which means in the case of 3rd party
communication, a client who wants to issue a read call after receiving a
message from a client that just completed a write operation should be able to
do that by fetching the txnId from ANN first without locking.
> [SBN read] Revisit GlobalStateIdContext locking when getting server state id
> ----------------------------------------------------------------------------
>
> Key: HDFS-14822
> URL: https://issues.apache.org/jira/browse/HDFS-14822
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs
> Reporter: Chen Liang
> Assignee: Chen Liang
> Priority: Major
> Labels: release-blocker
> Attachments: HDFS-14822.001.patch
>
>
> As mentioned under HDFS-14277. One potential performance issue of Observer
> read is that {{GlobalStateIdContext#getLastSeenStateId}} calls
> getCorrectLastAppliedOrWrittenTxId which ends up acquiring lock on txnid. We
> internally had some discussion and analysis, we believe this lock can be
> avoided, by calling the non-locking version method
> {{getLastAppliedOrWrittenTxId.}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
