Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 28 Aug 2014 02:31:58 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12735988.1408684295715.29356.1409193118634@arcas>
In-Reply-To: <JIRA.12735988.1408684295715@arcas>
References: <JIRA.12735988.1408684295715@arcas>
Subject: [jira] [Resolved] (ACCUMULO-3077) File never picked up for
 replication
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ACCUMULO-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Elser resolved ACCUMULO-3077.
----------------------------------

    Resolution: Fixed

> File never picked up for replication
> ------------------------------------
>
>                 Key: ACCUMULO-3077
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3077
>             Project: Accumulo
>          Issue Type: Bug
>          Components: replication
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Critical
>             Fix For: 1.7.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> I was running some tests and noticed that a single file was getting ignored. The logs were warning that the Status message that was written to {{accumulo.metadata}} didn't have a createdTime on the Status record.
> The odd part is that all other Status messages had a createdTime and were successfully replicated. Looking at the writes from the TabletServer logs, the expected record *was* written by the TabletServer, and writing a test with the full series of Status records written does net the correct Status (which was different than what was observed in the actual table).
> Looking into it, the log which was subject to this error was the first WAL that was used when the instance was started. Because the table configurations are lazily configured when they are actually used, I believe that the StatusCombiner that is set on {{accumulo.metadata}} was not seen by the TabletServer, and the VersioningIterator "ate" the first record.
> I need to come up with a way that I can be sure that all tservers will have seen the Combiner set on accumulo.metadata before any data is written to it to avoid losing a record like this.


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