[
https://issues.apache.org/jira/browse/HDFS-13872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16594399#comment-16594399
]
Konstantin Shvachko commented on HDFS-13872:
--------------------------------------------
I agree that HAServiceProtocol and DatanodeProtocol do not need to wait for
Observer to catch up. So mostly ClientProtocol methods should wait, but not all
of them, like {{setSafeMode()}}, {{getDatanodeReport()}},
{{getDatanodeStorageReport()}} shouldn't wait as well.
I was thinking if we could add a parameter to {{@ReadOnly}} annotation to
indicate that msync is required for this operation. On the client we can add
{{AlignmentContext}} only to those operations, that require msync. Then on the
server we can bypass waiting for catch up if {{AlignmentContext}} is not
present, which we already do I believe.
> Only ClientProtocol should perform msync wait
> ---------------------------------------------
>
> Key: HDFS-13872
> URL: https://issues.apache.org/jira/browse/HDFS-13872
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Erik Krogen
> Priority: Major
>
> Currently the implementation of msync added in HDFS-13767 waits until the
> server has caught up to the client-specified transaction ID regardless of
> what the inbound RPC is. This particularly causes problems for
> ObserverReadProxyProvider (see HDFS-13779) when we try to fetch the state
> from an observer/standby; this should be a quick operation, but it has to
> wait for the node to catch up to the most current state. I initially thought
> all {{HAServiceProtocol}} methods should thus be excluded from the wait
> period, but actually I think the right approach is that _only_
> {{ClientProtocol}} methods should be subjected to the wait period. I propose
> that we can do this via an annotation on client protocol which can then be
> checked within {{ipc.Server}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
