[
https://issues.apache.org/jira/browse/HBASE-11109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988473#comment-13988473
]
Jeffrey Zhong commented on HBASE-11109:
---------------------------------------
{quote}
Yeah, doesn't the comment say that? In testing, I see us doing 4 or 5 syncs a
ms so when we flush there'd be some hiccup of some portion of a millisecond for
this region only
{quote}
I c. +1 on your current patch. Thanks.
It's possible we can move out the sync when mvcc and seqid is combined. Because
it will be the readpoint(largest sequence number) before the WriteEntry w
inserted with mvcc.beginMemstoreInsert(); when we are holding the updatesLock.
> flush region sequence id may not be larger than all edits flushed
> -----------------------------------------------------------------
>
> Key: HBASE-11109
> URL: https://issues.apache.org/jira/browse/HBASE-11109
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Affects Versions: 0.99.0
> Reporter: stack
> Assignee: stack
> Priority: Critical
> Fix For: 0.99.0
>
> Attachments: 11109.txt, 11109v2.txt
>
>
> This was found by [~jeffreyz] See parent issue. We have this issue since we
> put the ring buffer/disrupter into the WAL (HBASE-10156).
> An edits region sequence id is set only after the edit has traversed the ring
> buffer. Flushing, we just up whatever the current region sequence id is.
> Crossing the ring buffer may take some time and is done by background
> threads. The flusher may be taking the region sequence id though edits have
> not yet made it across the ringbuffer: i.e. edits that are actually scoped by
> the flush may have region sequence ids in excess of that of the flush
> sequence id reported.
> The consequences are not exactly clear. Would rather not have to find out so
> lets fix this here.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
