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

Kurt Greaves commented on CASSANDRA-13622:
------------------------------------------

Sorry missed the email for your last comment. CircleCI appears to have failed 
on [trunk|https://circleci.com/gh/jasonstack/cassandra/424#tests/containers/0]. 
Might be related as it is testing DatabaseDescriptor. On that note probably 
wouldn't hurt to have some simple tests for these cases.

Also the merge into trunk has an extra line in {{CHANGES.txt}} before the 
change. The {{3.0.15}} should be removed.

Might want to rebase as well (sorry for my slowness :/)

Also not a committer so will prod one to commit/review once tests are 
written/are working.
Thanks.

> Better config validation/documentation
> --------------------------------------
>
>                 Key: CASSANDRA-13622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13622
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Configuration
>            Reporter: Kurt Greaves
>            Assignee: ZhaoYang
>            Priority: Minor
>              Labels: lhf
>             Fix For: 4.0
>
>
> 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]

Reply via email to