accumulo-notifications mailing list archives

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

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

Sean Busbey commented on ACCUMULO-2217:
---------------------------------------

I can only think of unlikely edge cases.

# I don't htink the JVM spec says you have to have gzip. While I think it's reasonable for
us to tell people to use e.g. the Oracle JVM or OpenJDK, I think we shouldn't make it overly
hard on those who might try being more adventurous (by refusing to fallback to none or not
logging it or something).
# It's  possible Hadoop will change that gzip behavior in the future

I also want to +1 Adam's comments from earlier, and make sure it doesn't get lost in updating
to this compression fallback change

{quote}
I think the top two things included in this ticket should be:
1. Gracefully and loudly unload the tablet when asked, even if it's not clean, and
2. Get the data out of memory when it's time to minor compact so other tablets can use the
memory.
The latter probably implies that we need to fall back to writing an rfile in some reliable
way and loudly complaining.
{quote}

> fall back to reliable compression settings on failure
> -----------------------------------------------------
>
>                 Key: ACCUMULO-2217
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2217
>             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
(v6.1.5#6160)

Mime
View raw message