You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Erik Krogen (JIRA)" <ji...@apache.org> on 2019/02/20 18:38:00 UTC

[jira] [Comment Edited] (HDFS-14272) [SBN read] ObserverReadProxyProvider should sync with active txnID on startup

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

Erik Krogen edited comment on HDFS-14272 at 2/20/19 6:37 PM:
-------------------------------------------------------------

[~shv], [~vagarychen], [~csun], appreciate if any of you can help review

[~jojochuang], I changed the title to reflect the more broad change I would like to make as a fix for your original issue, let me know if you have any concern with this


was (Author: xkrogen):
[~shv], [~vagarychen], [~csun], appreciate if any of you can help review

> [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
>
>
> 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
(v7.6.3#76005)

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