[
https://issues.apache.org/jira/browse/HBASE-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748880#action_12748880
]
Andrew Purtell commented on HBASE-1784:
---------------------------------------
bq. java.lang.RuntimeException: ScanWildcardColumnTracker.checkColumn ran into
a column actually smaller than the previous column
That error means that edits for one family are still ending up in store files
for another. I remember how to hack the code to let the store scanner continue
around this condition. Otherwise it is in effect data loss because the store
scanner cannot continue, though data is there. Let me put up a patch for this.
There is a separate hack for healing the problem as it is discovered during
compaction by moving the edits from the inappropriate store to the appropriate
one. Should we do this too as a workaround until the root cause is found and
fixed?
> 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.
