[
https://issues.apache.org/jira/browse/HBASE-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748276#action_12748276
]
stack commented on HBASE-1784:
------------------------------
I think the patch won't fix what I see in the logs. What I am seeing is that,
as you describe Mathias, the new daughter region has been added to the .META.
table, noticed by the scanner and then assigned AHEAD of the master getting the
split message that includes said daughter. The daughter has been successfully
opened out on the regionserver. On successful open, the master no longer
carries internal state on a region since its no longer 'transitioning'. The
split comes in and the region is reassigned IF !s.isPendingOpen() &&
!s.isOpen(). The daughter region will be in neither state. It won't be
pending since its already opened. isOpen is a bit of a misnomer in that its a
temporary state a region is in after we get the open message from regionserver
but before its open details -- the server it was opened on -- has been added to
the .META. table. After the .META. has been updated, the region is no longer
transistioning and is removed from the master inner state tables. So, the
daughter won't be in the isOpen state either.
Lets chat in morning. Maybe a reordering of the order in which we send events
would make things work well enough in the 0.20 timeframe till we get a chance
to redo this state-transition stuff properly in 0.21.
> Missing rows after medium intensity insert
> ------------------------------------------
>
> Key: HBASE-1784
> URL: https://issues.apache.org/jira/browse/HBASE-1784
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.0
> Reporter: Jean-Daniel Cryans
> Priority: Blocker
> Attachments: DataLoad.java, double-assignment, HBASE-1784.log,
> META.log, processSplitRegion-check-regionIsOpening.patch
>
>
> This bug was uncovered by Mathias in his mail "Issue on data load with
> 0.20.0-rc2". Basically, somehow, after a medium intensity insert a lot of
> rows goes missing. Easy way to reproduce : PE. Doing a PE scan or randomRead
> afterwards won't uncover anything since it doesn't bother about null rows.
> Simply do a count in the shell, easy to test (I changed my scanner caching in
> the shell to do it faster).
> I tested some light insertions with force flush/compact/split in the shell
> and it doesn't break.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
