hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-3015) recovered.edits files not deleted if it only contain edits that have already been flushed; hurts perf for all future opens of the region
Date Sat, 18 Sep 2010 18:25:32 GMT

     [ https://issues.apache.org/jira/browse/HBASE-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-3015:
-------------------------

    Attachment: 3015.txt

It looks like a silly mistake (on my part I believe).  This patch look ok to you Kannan?

> recovered.edits files not deleted if it only contain edits that have already been flushed;
hurts perf for all future opens of the region
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3015
>                 URL: https://issues.apache.org/jira/browse/HBASE-3015
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Kannan Muthukkaruppan
>         Attachments: 3015.txt
>
>
> On RS crash, master processes the RS's logs, splits them into per region log files, and
puts them in recovered.edits sub-directory of the region. 
> It may be the case the some of these files contain only old edits that have already been
flushed, and don't need to be reapplied again. However, in this case the file is not deleted,
and stays in recovered.edits for ever. This will slow down every future "open" of this region,
as the region will unnecessarily spend time processing this file.
> In  HRegion.java:replaceRecoveredEditsIfAny(), the code below checks if the file we just
processed contain any edits that were applied, and in that case flushes the memstore into
which things were being recovered. 
> {code}
>   if (seqid > minSeqId) {
>       // Then we added some edits to memory. Flush and cleanup split edit files.
>       internalFlushcache(null, seqid);
>       for (Path file: files) {
>         if (!this.fs.delete(file, false)) {
>           LOG.error("Failed delete of " + file);
>         } else {
>           LOG.debug("Deleted recovered.edits file=" + file);
>         }
>       }
>     }
> {code}
> But it is not clear why the 'for' loop to clean up the recovered.edits file is inside
the if check.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message