Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 13 Jul 2013 00:25:49 +0000 (UTC)
From: "Amitanand Aiyer (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12657549.1373675056394.44219.1373675149061@arcas>
In-Reply-To: <JIRA.12657549.1373675056394@arcas>
References: <JIRA.12657549.1373675056394@arcas>
Subject: [jira] [Created] (HBASE-8942) DFS errors during a read operation
 (get/scan), may cause write outliers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Amitanand Aiyer created HBASE-8942:
--------------------------------------

             Summary: DFS errors during a read operation (get/scan), may cause write outliers
                 Key: HBASE-8942
                 URL: https://issues.apache.org/jira/browse/HBASE-8942
             Project: HBase
          Issue Type: Bug
    Affects Versions: 0.89-fb, 0.95.2
            Reporter: Amitanand Aiyer
            Assignee: Amitanand Aiyer
            Priority: Minor


This is a similar issue as discussed in HBASE-8228

1) A scanner holds the Store.ReadLock() while opening the store files ... encounters errors. Thus, takes a long time to finish.

2) A flush is completed, in the mean while. It needs the write lock to commit(), and update scanners. Hence ends up waiting.

3+) All Puts (and also Gets) to the CF, which will need a read lock, will have to wait for 1) and 2) to complete. Thus blocking updates to the system for the DFS timeout.

Fix:
 Open Store files outside the read lock. getScanners() already tries to do this optimisation. However, Store.getScanner() which calls this functions through the StoreScanner constructor, redundantly tries to grab the readLock. Causing the readLock to be held while the storeFiles are being opened, and seeked.

 We should get rid of the readLock() in Store.getScanner(). This is not required. The constructor for StoreScanner calls getScanners(xxx, xxx, xxx). This has the required locking already.

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