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 103031837F for ; Tue, 19 Jan 2016 07:44:41 +0000 (UTC) Received: (qmail 65774 invoked by uid 500); 19 Jan 2016 07:44:40 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 65712 invoked by uid 500); 19 Jan 2016 07:44:40 -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 65326 invoked by uid 99); 19 Jan 2016 07:44:40 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jan 2016 07:44:40 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id E386C2C1F5D for ; Tue, 19 Jan 2016 07:44:39 +0000 (UTC) Date: Tue, 19 Jan 2016 07:44:39 +0000 (UTC) From: "ramkrishna.s.vasudevan (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-15101) Leaked References to StoreFile.Reader after HBASE-13082 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-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106396#comment-15106396 ] ramkrishna.s.vasudevan commented on HBASE-15101: ------------------------------------------------ Patch looks good to me. ya I think the shorter version is the easiest way after seeing the code where the patch is prepared. Regarding the point where you say a Region Server dies and you end up seeing lot of uncollected files, in the version without HBASE-13082 - suppose a set of compactions started but that RS got killed or dies before it is completed you wil have all those store files again getting used for subsequent readers when the regions are opened in a new RS and there should be another compaction that needs to run and move the files to the archive dir. Now even after HBASE-13082 - the scenario is similar because once the compaction is done if the Compaction discharger thread does not kick in and before that your RS dies, you end up with the store files again available for reads and you need one more set of compaction to happen in the new RS to move the files to the archive dir. After applying the patch also you still get issues where the compacted files are not cleared? You mean there is always a set of files that is not cleared ? Now coming to do the cleaning operation during close(), I think we are doing it on HStore.close() operation and ensuring that the compacted files are moved to the archive dir. Its good to check this out before we commit the updated patch to branch-1. > Leaked References to StoreFile.Reader after HBASE-13082 > ------------------------------------------------------- > > Key: HBASE-15101 > URL: https://issues.apache.org/jira/browse/HBASE-15101 > Project: HBase > Issue Type: Bug > Components: HFile, io > Affects Versions: 2.0.0 > Reporter: deepankar > Assignee: deepankar > Attachments: HBASE-15101-v1.patch, HBASE-15101-v2.patch, HBASE-15101-v3.patch, HBASE-15101.patch > > > We observed this production that after a region server dies there are huge number of hfiles in that region for the region server running the version with HBASE-13082, In the doc it is given that it is expected to happen, but we found a one place where scanners are not being closed. If the scanners are not closed their references are not decremented and that is leading to the issue of huge number of store files not being finalized > All I was able to find is in the selectScannersFrom, where we discard some of the scanners and we are not closing them. I am attaching a patch for that. > Also to avoid these issues should the files that are done be logged and finalized (moved to archive) as a part of region close operation. This will solve any leaks that can happen and does not cause any dire consequences? -- This message was sent by Atlassian JIRA (v6.3.4#6332)