[
https://issues.apache.org/jira/browse/HDFS-14284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937111#comment-16937111
]
Ayush Saxena commented on HDFS-14284:
-------------------------------------
Thanx [~hemanthboyina] for the patch.
I think the trace with which we started as reported was :
{code:java}
Exception in thread "main"
org.apache.hadoop.ipc.RemoteException(java.io.IOException): No namenode
available under nameservice ns0
{code}
This seems to be a no namenode available scenario, That is a
{{NoNamenodeException}}. We can add router id in this similarly and there
arent't many occurrences of this, some already have router id appended as
string, we just need to migrate them to use the new constructor.
[~elgoiri] do we have any advantage of having a RouterIOException, rather than
directly calling {{super(msg + "from" + routerId);}} in the new constructors?
> RBF: Log Router identifier when reporting exceptions
> ----------------------------------------------------
>
> Key: HDFS-14284
> URL: https://issues.apache.org/jira/browse/HDFS-14284
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Íñigo Goiri
> Assignee: hemanthboyina
> Priority: Major
> Attachments: HDFS-14284.001.patch
>
>
> The typical setup is to use multiple Routers through
> ConfiguredFailoverProxyProvider.
> In a regular HA Namenode setup, it is easy to know which NN was used.
> However, in RBF, any Router can be the one reporting the exception and it is
> hard to know which was the one.
> We should have a way to identify which Router/Namenode was the one triggering
> the exception.
> This would also apply with Observer Namenodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
