Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 1 Oct 2012 02:16:07 +1100 (NCT)
From: "Flavio Junqueira (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1547433855.145640.1349018167769.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <178667292.25261.1336099369778.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5937) Refactor HLog into an interface.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Flavio Junqueira commented on HBASE-5937:
-----------------------------------------

[~yuzhihong@gmail.com] bq. Looking at HLog interface, I wonder if interface Reader and interface Writer should be moved to their own files. That way we don't need to reference org.apache.hadoop.fs.FileSystem in HLog.

I was wondering the same thing. One reason for not doing it was having all interfaces to implement for HLog in the same place. But, I don't feel very strongly about leaving them in HLog.

[~stack] bq. You fellas like how the new Interface looks or would you change it? Stuff like isLowReplicationRollEnabled, getCoprocessorHost... these seems implementation specific.

I think I said this in another jira, but the plan we proposed was to make of HLog an interface and expose all public methods first. This way it will be simpler to revisit the current public methods and redesign the interface. Making of HLog an interface and redesigning it all at once might be too messy.

The bottom line is that we strongly agree that we need to revisit the methods currently in the interface and we need to do it eventually. 

bq. You have to do this cast? HBaseTestingUtility.setMaxRecoveryErrorCount(((FSHLog) wal2).getOutputStream(), 1);

Well spotted. getOutputStream is currently not part of the interface because it is not a public method of FSHLog. According to the javadoc, it is used internally in FSHLog and in tests. Given that this is used in tests, we possibly don't want to make it specific to a particular implementation, although the test currently can't have anything else other than FSHLog for an instance of HLog. At the same time, getOutputStream returns a java.io.OutputStream, which is not specific to HDFS. I could really go both ways at this point.

 
> Refactor HLog into an interface.
> --------------------------------
>
>                 Key: HBASE-5937
>                 URL: https://issues.apache.org/jira/browse/HBASE-5937
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Li Pi
>            Assignee: Flavio Junqueira
>            Priority: Minor
>         Attachments: 5937-hlog-with-javadoc.txt, HBASE-5937.patch, HBASE-5937.patch, HBASE-5937.patch, HBASE-5937.patch, HBASE-5937.patch, org.apache.hadoop.hbase.client.TestMultiParallel-output.txt
>
>
> What the summary says. Create HLog interface. Make current implementation use it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira