Maxim Muzafarov created CASSANDRA-20791:
-------------------------------------------
Summary: Update SetConcurrency command to use separate commands
instead of variable argument interpretation
Key: CASSANDRA-20791
URL: https://issues.apache.org/jira/browse/CASSANDRA-20791
Project: Apache Cassandra
Issue Type: Improvement
Reporter: Maxim Muzafarov
The SetConcurrency command currently uses a problematic pattern where the
meaning and type of arguments depends on the number of arguments provided. This
violates picocli best practices and creates several issues:
# The argument interpretation is problematic:
With 2 args: <stage-name> <maximum-concurrency>
With 3 args: <stage-name> <core-pool> <maximum-concurrency>
# The second argument can be either a core-pool size or maximum-concurrency
depending on the total number of arguments, making the API confusing and
error-prone.
# Users must remember the exact argument order and count, with no clear
indication of which argument means what.
# Inconsistent with picocli patterns - most of the nodetool commands use
explicit parameter annotations with clear types and meanings, while this
command relies on runtime argument counting
h3. Proposed Solution
Split the command into two separate commands following the pattern used by
other nodetool commands:
# setmaximumconcurrency <stage-name> <maximum-concurrency>
#
setconcurrencypool <stage-name> <core-pool> <maximum-concurrency>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
