accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2217) fall back to reliable compression settings on failure
Date Fri, 17 Jan 2014 21:58:21 GMT


Sean Busbey commented on ACCUMULO-2217:

Shorter version of my input: from an operational perspective

expected > correct > stable >>>>> fast

provided that things are "fast enough" that you can throw enough hardware at a problem to
meet your reqs.

This is the basis of me favoring loud failure conditions more than use bending over to try
to keep going in the face of misconfiguration.

Related question: do we have any notion currently of having a tserver declare itself failed
for only some tablets (like those for a table with a compression codec it can't handle)? and
by extension blacklisting of tservers (either by table or globally)? This seems like a more
desirable generalization of the "master keeping track of who has what", analogous to the blacklisting
done in Hadoop.

> fall back to reliable compression settings on failure
> -----------------------------------------------------
>                 Key: ACCUMULO-2217
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.4.4, 1.5.0
>            Reporter: Adam Fuchs
> Bad compression configuration keeps tables online:
> {code}
> createtable test
> config -t test -s table.file.compression.type=snappy
> flush
> droptable test
> {code}
> The flush results in an unsatisfied link error when Snappy is not properly configured.
This keeps the tablet online. Dropping the table when the tablet is stuck online puts a FATE
operation in the queue, which backs everything up.
> Can we fall back to something that is in the java code base (i.e. gz) in the event of
failures to load other compression code?

This message was sent by Atlassian JIRA

View raw message