[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091251#comment-16091251
]
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: https://issues.apache.org/jira/browse/CASSANDRA-13622
> 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 {{DatabaseDescriptor.java}}, 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|title=DatabaseDescriptor.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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
