[jira] [Created] (CASSANDRA-20791) Update SetConcurrency command to use separate commands instead of variable argument interpretation

["Maxim Muzafarov (Jira)" <ji...@apache.org>]

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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org