accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2925) Timestamp is not propagated to peer
Date Thu, 19 Jun 2014 03:48:24 GMT

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

Josh Elser commented on ACCUMULO-2925:
--------------------------------------

Despite what I tried, I can't get the timestamp to be propagated through to the server without
completely rewriting all of the Mutations that are being replicated which is really terrible.
Some situations that kept me from being able to get there

* ColumnUpdates on Mutation are immutable and not stored unserialized in a Mutation
* Tried to make BatchWriter aware of ServerMutations and copy them directly, but they would
get thrown away in the conversion to TMutation done inside the BatchWriter

If anyone has any smart ideas on how things could be reworked (assuming [~kturner] would have
the best idea since I think you did logical time), I would be more than accepting.

> Timestamp is not propagated to peer
> -----------------------------------
>
>                 Key: ACCUMULO-2925
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2925
>             Project: Accumulo
>          Issue Type: Bug
>          Components: replication
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 1.7.0
>
>
> Wrote a test that was doing some more intense verification of equality of two tables
and I was surprised to find that the tables were in fact not equal.
> Digging into it some more, I eventually found that the keys and values were identical,
save for the timestamp. Despite the Mutations coming from the local WAL having timestamps
set by the server, these got lost.
> Specifically, the "real" timestamp is stored on the ServerMutation, not each ColumnUpdate.
On the peer, when the BatchWriter makes a shallow copy of the (Server)Mutation to apply on
the target table for replication, we lose that ServerMutation and get a "regular" Mutation
which has updates that don't have any timestamp set. If the BatchWriter didn't make the shallow
copy, this should work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message