hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Krogen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-14272) [SBN read] ObserverReadProxyProvider should sync with active txnID on startup
Date Mon, 25 Feb 2019 23:43:00 GMT

    [ https://issues.apache.org/jira/browse/HDFS-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777406#comment-16777406

Erik Krogen commented on HDFS-14272:

Since proxies to individual NNs have not been created yet, changeProxy() will create proxy
for the corresponding NN, then call getHAServiceState() and cache the state. Then it will
proceed with the msync() call, which is not needed because the client already knows the state
of that NN.
Yes, the {{changeProxy()}} within ORPP will call {{getHAServiceState()}}. If an {{msync()}}
was subsequently sent over this proxy, I agree it would be somewhat redundant. However, {{msync()}}
is called on the {{failoverProxy}}, which is a CFPP. The {{changeProxy()}} method on CFPP
will _not_ call {{getHAServiceState()}}; the {{msync()}} method is the first call that is
performed on the proxy. Thus the number of RPC calls is identical. Whether those RPCs are
calls to {{getHAServiceState()}} or {{msync()}} is not important for performance, and re-using
the {{msync()}} functionality is cleaner IMO.

[~csun]: thanks for the comments, I uploaded v002 addressing them.

> [SBN read] ObserverReadProxyProvider should sync with active txnID on startup
> -----------------------------------------------------------------------------
>                 Key: HDFS-14272
>                 URL: https://issues.apache.org/jira/browse/HDFS-14272
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: tools
>         Environment: CDH6.1 (Hadoop 3.0.x) + Consistency Reads from Standby + SSL + Kerberos
+ RPC encryption
>            Reporter: Wei-Chiu Chuang
>            Assignee: Erik Krogen
>            Priority: Major
>         Attachments: HDFS-14272.000.patch, HDFS-14272.001.patch, HDFS-14272.002.patch
> It is typical for integration tests to create some files and then check their existence.
For example, like the following simple bash script:
> {code:java}
> # hdfs dfs -touchz /tmp/abc
> # hdfs dfs -ls /tmp/abc
> {code}
> The test executes HDFS bash command sequentially, but it may fail with Consistent Standby
Read because the -ls does not find the file.
> Analysis: the second bash command, while launched sequentially after the first one, is
not aware of the state id returned from the first bash command. So ObserverNode wouldn't wait
for the the edits to get propagated, and thus fails.
> I've got a cluster where the Observer has tens of seconds of RPC latency, and this becomes
very annoying. (I am still trying to figure out why this Observer has such a long RPC latency.
But that's another story.)

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message