hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4344) Persist memstoreTS to disk
Date Wed, 28 Sep 2011 18:46:49 GMT

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

stack commented on HBASE-4344:
------------------------------

Looking at v12.  Minor nits.  Can fix on commit.  Small question below.

On commit we should just remove the below rather than comment them out:

{code}
-  @Ignore("Currently not passing - see HBASE-2856")
+  //@Ignore("Currently not passing - see HBASE-2856")
{code}

Looks like we usually just delete the '@Ignore'.

In StoreScanner we do:

{code}
+    matcher.ignoreNewerKVs();
{code}

Does this mean that we will always ignore kvs with newer readpoints?  If so, should we just
strip this method altogether and the setting of boolean attribute?  Same for similar method
out in hfile v2.

Why should someone be able to do this?

{code}
+  public void setMaxMemstoreTS(long maxMemstoreTS) {
+    this.maxMemstoreTS = maxMemstoreTS;
+  }
{code}

Shouldn't we be getting this from looking at the kvs that come in when writing and then when
reading, it comes up out of the hfile metadata?  A client should never be able to set it?

This looks like it could be too much logging (I'd think that around here we are already dumping
out the file path):

{code}
 
+    LOG.info("HFileReaderV2 trying to read from " + path);
+    
{code}


                
> Persist memstoreTS to disk
> --------------------------
>
>                 Key: HBASE-4344
>                 URL: https://issues.apache.org/jira/browse/HBASE-4344
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Amitanand Aiyer
>            Assignee: Amitanand Aiyer
>             Fix For: 0.89.20100924
>
>         Attachments: 4344-v10.txt, 4344-v11.txt, 4344-v12.txt, 4344-v2.txt, 4344-v4.txt,
4344-v5.txt, 4344-v6.txt, 4344-v7.txt, 4344-v8.txt, 4344-v9.txt, patch-2
>
>
> Atomicity can be achieved in two ways -- (i) by using  a multiversion concurrency system
(MVCC), or (ii) by ensuring that "new" writes do not complete, until the "old" reads complete.
> Currently, Memstore uses something along the lines of MVCC (called RWCC for read-write-consistency-control).
But, this mechanism is not incorporated for the key-values written to the disk, as they do
not include the memstore TS.
> Let us make the two approaches be similar, by persisting the memstoreTS along with the
key-value when it is written to the disk.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message