[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487380#comment-17487380
]
David Capwell commented on CASSANDRA-17292:
-------------------------------------------
bq. I have no idea what should go under the query heading
Configurations which directly impact query execution; your examples on how many
threads to give the read/write stages logically fall under "queries" as they
tune how many threads to give the query system...
CQL currently is our query system, so logically CQL configs should be grouped
there as well (could do cql rather than query.cql, main advantage of query.cql
is its clear where a different query execution configs would go (query), but
without anyone actively working on one don't 100% think we need to deal with
that right now, and can migrate if the time comes).
{code}
cql:
concurrent_read: 42
concurrent_write: 42
prepared_statements:
cache_size: 1mb
user_defined_functions:
enabled: false
threads_enabled: true
timeout:
warn: 500ms
fail: 1500ms
policy: die
{code}
bq. Streaming also has compaction limits (particularly concurrent_validators,
but arguably also the bandwidth)
{code}
(trunk) $ grep -ir concurrent_validators src/
(trunk) $
{code}
I don't see a "concurrent_validators", do you mean "concurrent_validations"?
The code is physically in compaction, but this is part of repair, so should
logically should be under a "repair" top level.
{code}
repair:
validation:
threads: 1
{code}
"bandwidth" is currently scoped to streaming
(stream_throughput_outbound_megabits_per_sec,
entire_sstable_stream_throughput_outbound_megabits_per_sec,
inter_dc_stream_throughput_outbound_megabits_per_sec,
entire_sstable_inter_dc_stream_throughput_outbound_megabits_per_sec, etc.)...
if we want to ask "is streaming scoped to networking, or top level" I think
there are arguments both ways, but the fact that streaming can be rate limited
doesn't mean it should be grouped with other things which can be rate limited...
bq. Should we use internode and native_transport terminology? They're very core
developer focused, and not very user friendly. Perhaps cluster_network and
client_network?
"cluster_network" and "client_network" make sense, a more common pattern I have
seen are client/server
{code}
network:
client: # this is CQL protocol, this may also include thrift in 3.0 (we
should not backport), and/or any alternatives that may come in the future
...
server: # this is the internode protocol
...
{code}
> Move cassandra.yaml toward a nested structure around major database concepts
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-17292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17292
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Caleb Rackliffe
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.x
>
>
> Recent mailing list conversation (see "[DISCUSS] Nested YAML configs for new
> features") has made it clear we will gravitate toward appropriately nested
> structures for new parameters in {{cassandra.yaml}}, but from the scattered
> conversation across a few Guardrails tickets (see CASSANDRA-17212 and
> CASSANDRA-17148) and CASSANDRA-15234, there is also a general desire to
> eventually extend this to the rest of {{cassandra.yaml}}. The benefits of
> this change include those we gain by doing it for new features (single point
> of interest for feature documentation, typed configuration objects, logical
> grouping for additional parameters added over time, discoverability, etc.),
> but one a larger scale.
> This may overlap with ongoing work, including the Guardrails epic. Ideally,
> even a rough cut of a design here would allow that to move forward in a
> timely and coherent manner (with less long-term refactoring pain).
> While these would have to be adjusted to CASSANDRA-15234 (probably after it
> merges), there have been two proposals floated already for what this might
> look like:
> From [~maedhroz] -
> https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8
> From [~benedict] -
> https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
