[
https://issues.apache.org/jira/browse/ACCUMULO-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036730#comment-14036730
]
Josh Elser commented on ACCUMULO-2925:
--------------------------------------
The "proper" fix would be to push the systemTimestamp down into each
ColumnUpdate but I'm worried about the unintended consequences that might arise
from doing that in the "regular" pipeline. I can account for this within the
replication code.
> 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)
