[
https://issues.apache.org/jira/browse/HDFS-13779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583012#comment-16583012
]
Erik Krogen commented on HDFS-13779:
------------------------------------
{quote}
And {{getProxy}} will trigger {{getAllProxies}} which further triggers
{{refreshProxyState}}.
{quote}
Actually this is not quite true; {{getAllProxies}} only calls
{{refreshProxyState}} when {{proxies}} is empty (i.e., initialization). After
that it just returns the current value of {{proxies}}. However,
{{refreshProxyState}} may be called at any time by, for example,
{{performFailover}}, so your point below about {{isObserver}} is still valid:
{quote}
In short, the value of {{isObserver}} could change at any point of time .... So
when invoke gets called each time, there seems no guarantee what will (not) be
in the list returned from {{getFilteredProxies}} with regard to the previous
state.
{quote}
So yes, I agree that there isn't a guarantee that {{getFilteredProxies}} will
return the same thing when invoked multiple times. That's part of why, at the
top of {{invoke}}, I call {{getFilteredProxies}} a single time and then use
that value throughout the function. But the list should only change upon
failover-style actions (e.g. Observer changes to Standby) and the only thing
that happens if the list changes is to start talking to a different observer,
so I don't think it's an issue, but let me know if there's something I'm
missing.
> Implement performFailover logic for ObserverReadProxyProvider.
> --------------------------------------------------------------
>
> Key: HDFS-13779
> URL: https://issues.apache.org/jira/browse/HDFS-13779
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: Konstantin Shvachko
> Assignee: Erik Krogen
> Priority: Major
> Attachments: HDFS-13779-HDFS-12943.WIP00.patch
>
>
> Currently {{ObserverReadProxyProvider}} inherits {{performFailover()}} method
> from {{ConfiguredFailoverProxyProvider}}, which simply increments the index
> and switches over to another NameNode. The logic for ORPP should be smart
> enough to choose another observer, otherwise it can switch to a SBN, where
> reads are disallowed, or to an ANN, which defeats the purpose of reads from
> standby.
> This was discussed in HDFS-12976.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]