Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 16 May 2017 08:28:04 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13072320.1494915769000.218857.1494923284119@Atlassian.JIRA>
In-Reply-To: <JIRA.13072320.1494915769000@Atlassian.JIRA>
References: <JIRA.13072320.1494915769000@Atlassian.JIRA> <JIRA.13072320.1494915769186@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-18055) HBASE-17917 closes the scanners
 while a scan is in progess for switching over to stream reads
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 16 May 2017 08:28:10 -0000


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

ramkrishna.s.vasudevan commented on HBASE-18055:
------------------------------------------------

bq.Great catch! This issue may resolve the corrupted data which happen in the TestAcid*.
Corrupted data in TestAcid? Is TestAcid also backed by L2 cache? If so this could be a problem. But am not sure if TestAcid is working with L2 in master.

> HBASE-17917 closes the scanners while a scan is in progess for switching over to stream reads
> ---------------------------------------------------------------------------------------------
>
>                 Key: HBASE-18055
>                 URL: https://issues.apache.org/jira/browse/HBASE-18055
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver, Scanners
>    Affects Versions: 2.0.0
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>
>
> In HBASE-17917 tries to switch from pread to stream read when a specific size of bytes are read. So in order to switch over, it closes the existing scanners and creates a new scanners with pread=false.
> When we close the exisitng scanners - if the blocks are served from offheap cache we will decrement the ref count on those blocks and if it becomes zero we make the block ready for eviction. Then there is a chance that the result could be corrupted if new blocks occupy the cache. So the expectation was that till the RPC call completes the response we will hold on to the blocks that are referred by the scan. (except the last one). So trying to switch over to stream read will break this expectation and hence TestBlockEvictionfromclient fails. 


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)