[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13622:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.15
3.11.1
4.0
> Better config validation/documentation
> --
>
> Key: CASSANDRA-13622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13622
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Kurt Greaves
>Assignee: ZhaoYang
>Priority: Low
> Labels: lhf
> Fix For: 3.0.15, 3.11.1, 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrés de la Peña 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-13622
> 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
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-13622:
-
Status: Ready to Commit (was: Patch Available)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-13622:
-
Reviewer: Kurt Greaves
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-13622:
Component/s: Configuration
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-13622:
-
Fix Version/s: 4.0
> 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
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13622) Better config validation/documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-13622:
-
Status: Patch Available (was: Open)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
