[
https://issues.apache.org/jira/browse/CASSANDRA-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836678#comment-16836678
]
Jon Meredith commented on CASSANDRA-15114:
------------------------------------------
I've reproduced the out of space condition with a small ByteMan test, and done
some archaeology.
Looking at the first examples, Cassandra does not treat out of space for
compaction as a disk failure event (CASSANDRA-12385), so changing the thrown
exception to be the more descriptive FSDiskFullWriteError would have it
converted back to a RuntimeException here in
[AbstractCompactionTask|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/compaction/AbstractCompactionTask.java#L63]
However, I do agree it would be more consistent for out of disk space
conditions to be handled the same way between
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter#getWriteDirectory
and org.apache.cassandra.db.Directories#getWriteableLocation.
I don't think the second exception will ever be thrown.
{{org.apache.cassandra.db.Directories#getWriteableLocation}} should be marked
{{@Nonnull}} as it throws FSDiskFullWriterError or FSWriteError if there was a
problem with one of the candidate paths. {{getWriteDirectory}} should just
directly return the result from {{getDirectories().getWriteableLocation()}}.
I don't want to risk changes that could affect logging systems, but think it's
worth outputting the correct exception in 4.next.
> Cassandra does not follow user's disk_failure_policy when getWriteDirectory()
> runs out of disk space
> ----------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15114
> Project: Cassandra
> Issue Type: Bug
> Reporter: eBugs
> Assignee: Jon Meredith
> Priority: Normal
>
> Dear Cassandra developers, we are developing a tool to detect
> exception-related bugs in Java. Our prototype has spotted the following two
> {{throw}} statements whose exception class and error message indicate
> different error conditions.
>
> Version: Cassandra-3.11 (commit: 123113f7b887370a248669ee0db6fdf13df0146e)
> File:
> CASSANDRA-ROOT/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java
> Line: 222 & 231
> {code:java}
> if (availableSpace < estimatedWriteSize)
> throw new RuntimeException(String.format("Not enough space to write %s to
> %s (%s available)",
>
> FBUtilities.prettyPrintMemory(estimatedWriteSize),
> d.location,
>
> FBUtilities.prettyPrintMemory(availableSpace)));{code}
> {code:java}
> d = getDirectories().getWriteableLocation(estimatedWriteSize);
> if (d == null)
> throw new RuntimeException(String.format("Not enough disk space to store
> %s",
>
> FBUtilities.prettyPrintMemory(estimatedWriteSize)));
> {code}
>
> {{RuntimeException}} is usually used to represent errors in the program logic
> (think of one of its subclasses, {{NullPointerException}}), while the error
> messages indicate that the Cassandra node is running out of disk space. This
> mismatch could be a problem. For example, the callers may miss the
> possibility that {{getWriteDirectory()}} can run out of disk space because it
> does not throw an accurate exception class (e.g., CASSANDRA-11448). Or, the
> callers trying to handle other {{RuntimeException}} may accidentally (and
> incorrectly) handle the out of disk space scenario.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
