hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3588) Proposal to optimize ReadWriteConsistencyControl
Date Wed, 02 Mar 2011 21:17:37 GMT

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

Ted Yu commented on HBASE-3588:
-------------------------------

The new method:
{code}
  public MemStore(final Configuration conf,
                  final KeyValue.KVComparator c,
                  final ReadWriteConsistencyControl rwcc) {
{code}
would produce this test failure:
{code}
testMultipleVersionsSimple(org.apache.hadoop.hbase.regionserver.TestMemStore)  Time elapsed:
0.007 sec  <<< ERROR!
java.lang.NoSuchMethodError: org.apache.hadoop.hbase.regionserver.MemStore.<init>(Lorg/apache/hadoop/conf/Configuration;Lorg/apache/hadoop/hbase/KeyValue$KVComparator;)V
        at org.apache.hadoop.hbase.regionserver.TestMemStore.testMultipleVersionsSimple(TestMemStore.java:477)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
{code}

> Proposal to optimize ReadWriteConsistencyControl
> ------------------------------------------------
>
>                 Key: HBASE-3588
>                 URL: https://issues.apache.org/jira/browse/HBASE-3588
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>         Attachments: rwcc.trunk.1, rwcc.trunk.1
>
>
> The ReadWriteConsistencyControl (RWCC) mechanism facilitates making a set of memstore
updates atomically visible to readers. Also, the rwcc.completeMemstoreInsert() blocks till
the memstore read point advances to the current writeNumber. This is done to ensure that if
an application that does a put immediately issues a new get call for the same key, then the
get should see the values inserted by the previous call to put. The current implementation
assumes this worst-case and penalizes the put rpc to not return to the client until the read
point advances to this transaction's write number.
> In many use-cases, the application never actually issues a get for the most recent put
that it inserted. In this case, it would be nice if we can transfer the penalty (of blocking)
to the get call that follows the initial put.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message