[
https://issues.apache.org/jira/browse/HBASE-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748008#action_12748008
]
Jonathan Gray commented on HBASE-1784:
--------------------------------------
Looking at your code, seems that you are disabling WAL.
Given that in your testing you don't generally see full-on cluster breakage,
just occasional compactions failing, that if the failed compactions weren't
erradicating data you would probably survive the import to the end.
That's a good argument for fixing this in 0.20.0, but it might not be as easy
as we'd hope.
One other note... At least in the Mathias logs I've seen, the compactions that
are running, and failing, seem to have at least some half readers / referenced
storefiles.
> 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, HBASE-1784.log
>
>
> 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.
