[
https://issues.apache.org/jira/browse/HBASE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255877#comment-13255877
]
stack commented on HBASE-5782:
------------------------------
Looking at Lars patch.
On you 1. and 2. above, apparently the append is also expensive according to
Dhruba. Just saying.
Also on.... "...might lead to sync be issued multiple time when only one was
necessary (it seems the same race condition existed before)."
Yes, this we have always had.
I'd say kill this stuff... it looks like rubbish to me:
{code}
+ syncBatchSize.addAndGet(doneUpto - this.syncedTillHere);
{code}
Its not read by anyone, looks like the math can go wonky, and when it is read,
its set back to zero which is probably unexpected. Kill it I'd say.
I think this is ok:
{code}
+ this.syncedTillHere = Math.max(this.syncedTillHere, doneUpto);
{code}
but this is racy
{code}
long doneUpto = this.unflushedEntries.get();
{code}
It could be low in number; i.e. we could be putting into hdfs more edits than
the current value of unflushedEntries if we read after an edit has been added
to the queue but before the above is updated. Is that ok? Its ok if this is a
little sloppy especially if it under reports?
On tactic for 0.94, sure on doing this for 0.94 though I like Todds fix better.
The verification tool will help you figure if this slows stuff much and if we
are writing out of order. Let me know if you want me to run it for you. Let
me add in log rolling too as per Todd suggestion.
> Edits can be appended out of seqid order since HBASE-4487
> ---------------------------------------------------------
>
> Key: HBASE-5782
> URL: https://issues.apache.org/jira/browse/HBASE-5782
> Project: HBase
> Issue Type: Bug
> Components: wal
> Affects Versions: 0.94.0
> Reporter: Gopinathan A
> Assignee: ramkrishna.s.vasudevan
> Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 5782-lars-v2.txt, 5782-sketch.txt, 5782.txt,
> 5782.unfinished-stack.txt, HBASE-5782.patch, hbase-5782.txt
>
>
> Create a table with 1000 splits, after the region assignemnt, kill the
> regionserver wich contains META table.
> Here few regions are missing after the log splitting and region assigment.
> HBCK report shows multiple region holes are got created.
> Same scenario was verified mulitple times in 0.92.1, no issues.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
