[
https://issues.apache.org/jira/browse/HBASE-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749990#action_12749990
]
Jonathan Gray commented on HBASE-1806:
--------------------------------------
Agree with apurtell. It's an accepted fact about scanners, from user POV. But
must be addressed for master/meta, and I think ZK is the right direction. For
now, ugly stuff in HBASE-1784 is fine with me... this is another one of the
issues that only rears it's head during high-load, sustained imports. But
dealing with it in the case it does happen with a Get sounds fine for now.
> Scanners do not respect row locks; scanner view could return a skewed view on
> row if ongoing update
> ---------------------------------------------------------------------------------------------------
>
> Key: HBASE-1806
> URL: https://issues.apache.org/jira/browse/HBASE-1806
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: stack
>
> What I'm seeing is that BaseScanner misses updates made by an update
> milliseconds before -- even hundreds of milliseconds before. See hbase-1784
> where I'm seeing double-assignment of regions.
> Scanners do not respect row locks. They should else could return a row with
> partial updates committed. What if a .META. region has tens of storefiles
> and a scan does a get full row which takes a long time. Say an update comes
> in during this read. First it will go in because no row lock is outstanding.
> Second, we'll miss the edit given we look at things in order -- memstore,
> then each storefile down to the oldest. What if the update is followed by an
> update of server state; e.g. region is moved out of intransition state? And
> inside in same server, say the master, it makes decisions dependent on what
> it sees when it does a scanner#next; e.g. BaseScanner checking for assignment?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
