Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6ECD4D346 for ; Fri, 21 Sep 2012 17:22:08 +0000 (UTC) Received: (qmail 93146 invoked by uid 500); 21 Sep 2012 17:22:08 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 93092 invoked by uid 500); 21 Sep 2012 17:22:08 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 93082 invoked by uid 99); 21 Sep 2012 17:22:08 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Sep 2012 17:22:08 +0000 Date: Sat, 22 Sep 2012 04:22:07 +1100 (NCT) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: <2108313594.108364.1348248128037.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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460631#comment-13460631 ] stack commented on HBASE-5937: ------------------------------ bq. Any clue of why this could be happening? Somehow the test is pointed at wrong fs? Did you mess w/ that? HBase, when it starts, it looks for a file named hbase.version. If present, it reads it to see that the version therein matches that of version the hbase software expects. We used this facility whenever on-fs formats changed in a way that required you to run a migration step before starting cluster. So, version == null makes me think hbase is looking in wrong place for the hbase.version file... looking in localfs rather than in hdf where it perhaps wrote it on startup? bq. ...and the initialization of HLog objects makes it tricky to instantiate it only to get a reader or a writer HLog construction is the way it is again because we presume one implementation only. I'd suggest you look at what it would take moving the heavyweight stuff done in HLog to an init or start method. NP having us change how we do the HLog setup in HBase. Perhaps it won't help much though as the Reader and Writer might want some of the heavy setup done? I'd also say that HLog is the way it is, not because it was designed, but because it evolved this way over the years. If you fellas want to startover, I'd say go for it: make a clean Interface that will work for our current hdfs use case and for the bkfs. We'll shoehorn it into a 0.98 or whatever suits your schedule. > 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: 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