Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 12 Sep 2017 14:36:00 +0000 (UTC)
From: =?utf-8?Q?Andr=C3=A9s_de_la_Pe=C3=B1a_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13081030.1497943885000.91335.1505226960744@Atlassian.JIRA>
In-Reply-To: <JIRA.13081030.1497943885000@Atlassian.JIRA>
References: <JIRA.13081030.1497943885000@Atlassian.JIRA> <JIRA.13081030.1497943885890@jira-lw-us.apache.org>
Subject: [jira] [Updated] (CASSANDRA-13622) Better config
 validation/documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 12 Sep 2017 14:36:06 -0000


     [ https://issues.apache.org/jira/browse/CASSANDRA-13622?page=3Dcom.atl=
assian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andr=C3=A9s de la Pe=C3=B1a updated CASSANDRA-13622:
------------------------------------------
       Resolution: Fixed
    Fix Version/s:     (was: 4.0)
                   4.x
                   3.11.x
                   3.0.x
           Status: Resolved  (was: Ready to Commit)

> Better config validation/documentation
> --------------------------------------
>
>                 Key: CASSANDRA-13622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1362=
2
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Configuration
>            Reporter: Kurt Greaves
>            Assignee: ZhaoYang
>            Priority: Minor
>              Labels: lhf
>             Fix For: 3.0.x, 3.11.x, 4.x
>
>
> There are a number of properties in the yaml that are "in_mb", however re=
solve to bytes when calculated in {{DatabaseDescriptor.java}}, but are stor=
ed in int's. This means that their maximum values are 2047, as any higher w=
hen converted to bytes overflows the int.
> Where possible/reasonable we should convert these to be long's, and store=
d 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 se=
t higher than that. Noting that although it's bad practice to increase a lo=
t 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 an=
d 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=3DDatabaseDescriptor.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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org