accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Resolved] (ACCUMULO-3077) File never picked up for replication
Date Thu, 28 Aug 2014 02:31:58 GMT


Josh Elser resolved ACCUMULO-3077.

    Resolution: Fixed

> File never picked up for replication
> ------------------------------------
>                 Key: ACCUMULO-3077
>                 URL:
>             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

View raw message