[ 
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)

Reply via email to