cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Greaves (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13622) Better config validation/documentation
Date Tue, 18 Jul 2017 08:01:11 GMT


Kurt Greaves commented on CASSANDRA-13622:

Not sure how keen I am on bounding commitlog_segment_size to 2GB. Obviously that's a ridiculous
size for a segment, but I have had to increase it to 1.2GB in the past to allow a write through.
Granted it was a side effect from MV's (I think it was streaming related), however the ability
to do so helped. Obviously that's not great justification but I think it would be better to
give it a much higher limit (store it as a long) and simply advise users (in docs+yaml) that
they really shouldn't need to set it above the default. 

Same goes for max_value_size. I don't see any compelling reason we should stop people experimenting
with that if they want to, as it's really just a safety net that the user configures. 

> Better config validation/documentation
> --------------------------------------
>                 Key: CASSANDRA-13622
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Kurt Greaves
>            Assignee: ZhaoYang
>            Priority: Minor
>              Labels: lhf
> There are a number of properties in the yaml that are "in_mb", however resolve to bytes
when calculated in {{}}, but are stored in int's. This means that their
maximum values are 2047, as any higher when converted to bytes overflows the int.
> Where possible/reasonable we should convert these to be long's, and stored as long's.
If there is no reason for the value to ever be >2047 we should at least document that as
the max value, or better yet make it error if set higher than that. Noting that although it's
bad practice to increase a lot of them to such high values, there may be cases where it is
necessary and in which case we should handle it appropriately rather than overflowing and
surprising the user. That is, causing it to break but not in the way the user expected it
to :)
> Following are functions that currently could be at risk of the above:
> {code:java|}
> getThriftFramedTransportSize()
> getMaxValueSize()
> getCompactionLargePartitionWarningThreshold()
> getCommitLogSegmentSize()
> getNativeTransportMaxFrameSize()
> # These are in KB so max value of 2096128
> getBatchSizeWarnThreshold()
> getColumnIndexSize()
> getColumnIndexCacheSize()
> getMaxMutationSize()
> {code}
> Note we may not actually need to fix all of these, and there may be more. This was just
from a rough scan over the code.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message