hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7801) Allow a deferred sync option per Mutation.
Date Sat, 13 Apr 2013 05:16:16 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630940#comment-13630940
] 

Lars Hofhansl commented on HBASE-7801:
--------------------------------------

Here's a list of changes I deliberately avoided in the 0.94 patch to keep it small and low
risk:
* Changing the coprocessor signature. The pre/post hooks still get only a boolean indicating
whether the entry written to the WAL or not
* Make HRegion.interalPut honor deferred sync. Currently internalPut does not honor this at
all (not even when set on the Table); it is use for checkAndPut. This patch does not fix that.
* cleanup the Increment/Appand method signatures. These receive an Append (or Increment) and
also a writeToWAL boolean, even though the Append/Increment have that boolean already.

If we wanted to change any of these, it should be a separate jira.

                
> Allow a deferred sync option per Mutation.
> ------------------------------------------
>
>                 Key: HBASE-7801
>                 URL: https://issues.apache.org/jira/browse/HBASE-7801
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 0.94.6, 0.95.0
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.98.0, 0.94.7, 0.95.1
>
>         Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, 7801-0.94-v4.txt,
7801-0.94-v5.txt, 7801-0.94-v6.txt, 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt,
7801-0.96-full-v5.txt, 7801-0.96-v10.txt, 7801-0.96-v1.txt, 7801-0.96-v6.txt, 7801-0.96-v7.txt,
7801-0.96-v8.txt, 7801-0.96-v9.txt, hbase-7801-addendum.patch
>
>
> Won't have time for parent. But a deferred sync option on a per operation basis comes
up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a special mutation
attribute.
> For batch operation we'd take the safest sync option of any of the mutations. I.e. if
there is at least one that wants to be flushed we'd sync the batch, if there's none of those
but at least one that wants deferred flush we defer flush the batch, etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message