accumulo-notifications mailing list archives

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


Josh Elser commented on ACCUMULO-2217:

I was thinking about this some more: unless we default to 'gz,none' (which is actually a decent
idea now that I think about it), or at least in some way inform the user about such functionality,
I'm not sure how much better it is to rely on configuration as the fall-back mechanism.

Changing the default from "gz" to "gz,none" might be good the more I think about it. By default,
users will *hopefully* maintain that style of configuration (not just specifying one type),
and those that truly do want everything to come to a grinding halt still have that functionality.

> 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