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-3077) File never picked up for replication
Date Fri, 22 Aug 2014 05:33:11 GMT

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

Josh Elser commented on ACCUMULO-3077:
--------------------------------------

I can't come up with a solution that configures the Combiner "as necessary". Any time that
I want to update a table property (which is going to rely on ZooKeeper Watchers firing on
all possible tservers -- which I can't know definitively), I have the potential to hit this
bug.

I think the only solution which is 100% is to set this on {{accumulo init}} and the "upgrade
path". Thoughts, [~kturner] [~ecn], others?

> 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
>
>
> 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)

Mime
View raw message