You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Andres de la Peña (Jira)" <ji...@apache.org> on 2022/04/20 14:01:00 UTC
[jira] [Comment Edited] (CASSANDRA-17551) 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525005#comment-17525005 ]
Andres de la Peña edited comment on CASSANDRA-17551 at 4/20/22 2:00 PM:
------------------------------------------------------------------------
The current guardrails for collection size are checked during write queries and on sstable write (flush and compaction). The error message has the form {{{}Detected collection %s of size %s, this exceeds the warning/failure threshold of %s{}}}.
I think that the check for disabled collections should probably be done when creating/altering a table, probably with a different warning/error message, such as {{{}Collections are not enabled{}}}. That could done in an easier way with a {{DisableFlag}} guardrail and new \{{collections_enabled}} property.
The advantage of using 0 as disabled value is that config would be briefer than adding separate properties. Maybe we could modify {{Threshold}} guardrails to include the functionalities of {{{}DisableFlag{}}}, which are an {{ensureEnabled}} method and a separate warn/error message for the particular case of 0. That would be useful not only for size-based guardrails but also for numeric guardrails such as, for example, {{{}materialized_views_per_table_warn_threshold{}}}/{{{}materialized_views_per_table_fail_threshold{}}}, where 0 would disallow or warn about MV creation in general, independently of the number of MVs. wdyt?
was (Author: adelapena):
The current guardrails for collection size are checked during write queries and on sstable write (flush and compaction). The error message has the form {{{}Detected collection %s of size %s, this exceeds the warning/failure threshold of %s{}}}.
I think that the check for disabled collections should probably be checked when creating/altering a table, probably with a different warning/error message, such as {{{}Collections are not enabled{}}}. That could probably be better done with a {{DisableFlag}} guardrail.
The advantage of using 0 as disabled value is that config would be briefer than adding separate properties. Maybe we could modify {{Threshold}} guardrails to include the functionalities of {{{}DisableFlag{}}}, which are an {{ensureEnabled}} method and a separate warn/error message for the particular case of 0. That would be useful not only for size-based guardrails but also for numeric guardrails such as, for example, {{materialized_views_per_table_warn_threshold}}/{{materialized_views_per_table_fail_threshold}}, where 0 would disallow or warn about MV creation in general, independently of the number of MVs. wdyt?
> 0KiB should be used to prohibit collections and not to disable the guardrails collection_size_warn_threshold and collection_size_fail_threshold
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17551
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Guardrails
> Reporter: Ekaterina Dimitrova
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 4.x
>
>
> # The two thresholds default to 0KiB to disable.
> # collection_size_warn_threshold: 0KiB
> # collection_size_fail_threshold: 0KiB
> 0KiB should be used to prohibit collections and not to disable the guardrail.
> Disabled should be null as we moved to that as part of CASSANDRA-17431 while investigating other config corner cases.
> Old config which had -1 for disable will be converted internally to null with the new config types and new config should use null for disable. Of course, disabling 0 as a non-valid value is a different story which should be handled on per-case basis.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org