[
https://issues.apache.org/jira/browse/HBASE-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748855#action_12748855
]
Mathias Herberts commented on HBASE-1784:
-----------------------------------------
I ran my import job against the head of the 0.20 branch + patch for 1784 and
unfortunately I am still missing some rows.
The logs don't show similar messages as the one that lead to discover the
double assignment problem. But they show a few
java.lang.RuntimeException: ScanWildcardColumnTracker.checkColumn ran into a
column actually smaller than the previous column
4 of the 5 reducers were restarted due to timeout being reached when attempting
to contact region servers, the batch therefore ran for more than 15 hours.
Will rerun it once more on an empty table to have a double test, but for now it
seems dataloss still occur.
> 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
> Fix For: 0.20.0
>
> Attachments: 1784.patch, 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.
