[
https://issues.apache.org/jira/browse/HBASE-18054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060014#comment-16060014
]
Mike Drob commented on HBASE-18054:
-----------------------------------
{code}
+ private static Log LOG = LogFactory.getLog(FailedServers.class);
{code}
Nit: should be declared final.
{code}
- public synchronized void addToFailedServers(InetSocketAddress address) {
+ public synchronized void addToFailedServers(InetSocketAddress address,
Throwable throwable) {
{code}
Should we have multiple methods instead to allow a gradual migration? I guess
it's {{@IA.Private}}, so maybe it doesn't matter.
{code}
+ assertEquals(nullException.toString(), "java.lang.NullPointerException");
+ assertEquals(loggingEvent.getRenderedMessage(), "Added failed server with
address "
+ + addr.toString() + " to list caused by " + nullException.toString());
+ assertNotEquals(loggingEvent.getRenderedMessage(), "Added failed server
with address "
+ + addr.toString() + " to list caused by " + iOException.toString());
{code}
I don't think we need to verify the behaviour of NPE.toString. And I don't
think we need to check that the message is both equal to and not equal to
things. The equality check strongly implies the non-equality check.
Nit: Argument order for JUnit is (expected, actual), you have it reversed.
I really like the use of Mock here, I'm going to have to keep that in mind for
when I'm doing something similar in the future.
> log when we add/remove failed servers in client
> -----------------------------------------------
>
> Key: HBASE-18054
> URL: https://issues.apache.org/jira/browse/HBASE-18054
> Project: HBase
> Issue Type: Bug
> Components: Client, Operability
> Affects Versions: 1.3.0
> Reporter: Sean Busbey
> Assignee: Ali
> Attachments: HBASE-18054.patch, HBASE-18054.v2.master.patch,
> HBASE-18054.v3.master.patch, HBASE-18054.v4.master.patch
>
>
> Currently we log if a server is in the failed server list when we go to
> connect to it, but we don't log anything about when the server got into the
> list.
> This means we have to search the log for errors involving the same server
> name that (hopefully) managed to get into the log within
> {{FAILED_SERVER_EXPIRY_KEY}} milliseconds earlier (default 2 seconds).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)