hbase-issues mailing list archives

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

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

Anoop Sam John commented on HBASE-7801:

-      byte [] row = delete.getRow();
+      delete.getRow();

We can avoid this line fully right? Good that u make some cleanup also. :)

 // do what CF defaults to
 +  if (!isDeferredLogSyncEnabled()) {
We can say do what table defaults to?
Even here also
+public enum Durability {
+  /**
+   * Use the column family's default setting to determine durability.
+   * This must remain the first option.
+   */

3.As per code in syncOrDefer() when all the Mutations in the Mini batch says for SKIP_WAL,
we should not call the sync.
+      case SKIP_WAL:
+        // nothing do to
+        break;
But see the code in doMiniBatchMutation()
+      Durability durability = Durability.USE_DEFAULT;
+        Durability tmpDur = m.getDurability(); 
+        if (tmpDur == Durability.SKIP_WAL) {
           if (m instanceof Put) {
+        } else if (tmpDur.ordinal() > durability.ordinal()) {
+          durability = tmpDur;
This is correct for not considering one Mutation's SKIP_WAL to affect with the USE_DEFAULT
of others. But when all the Mutation say SKIP_WAL, still finally the durability = Durability.USE_DEFAULT
and will cause a log sync?

Excellent work Lars.

> 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.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-v1.txt, 7801-0.96-v6.txt,
7801-0.96-v7.txt, 7801-0.96-v8.txt, 7801-0.96-v9.txt
> 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
> 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

View raw message