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 Mon, 15 Apr 2013 03:26:18 GMT

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

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

We have a silent agreement that attributes starting with _ are for internal use only (same
for the cluster id), I agree that that should have been documented somewhere.

As for catching the exception... Not sure what we should do in this case, other than throwing
an Exception. Or you mean you want to catch and ignore it and then check the value of writeToWAL?
Could do that too, but it seems a bit overkill. I'd rather know in the client code if there's
something wrong the enum.

                
> 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