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, 24 Jan 2014 20:12:45 GMT


Sean Busbey commented on ACCUMULO-2217:

   2. Run a test to see if compression algorithm is available and if not, then fallback
Option 2 seems best. It seems like the test for gzip would always say "available" for now.
However as Sean Busbey said there may be a condition in the future where the gzip test says
"not available". So the config "gz,none" still makes sense.


# fail to compact
# create more files than the user specified limit
# try to find a file we can read
# try to reassign tablet to tserver than can read file

If we did #4 by just saying "I can't have this assigned to me" and all nodes are misconfigured,
things would surface eventually as unassigned tablets, correct?

> 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