hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18055) HBASE-17917 closes the scanners while a scan is in progess for switching over to stream reads
Date Tue, 16 May 2017 08:18:04 GMT

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

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

bq.Or we can just move the entire switch logic into the shipped method.
Was checking the code and saw your comment. I think this should work out. Already shipped
call will return the used blocks except the current one. 
Since switching to stream read will seek to the last key and close the older scanners all
the blocks including the 'curBlock' in HfileScannerImpl will be returned back. How ever the
last block ref would have been incremented because of the seek. 
The only thing is that the switch over will happen after an RPC is done and that could have
read more bytes than the default maxPreadBytes.

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

Mime
View raw message