Caleb Rackliffe created CASSANDRA-18732: -------------------------------------------
Summary: Baseline Diagnostic vtables for Accord Key: CASSANDRA-18732 URL: https://issues.apache.org/jira/browse/CASSANDRA-18732 Project: Cassandra Issue Type: Improvement Components: Accord, Observability/Metrics Reporter: Caleb Rackliffe In addition to JMX-based metrics, there are bits of diagnostic information for Accord that we should consider exposing through vtables: 1.) We should ensure that coordinator-level CQL transactions and the local reads and writes they spawn are visible to the existing {{QueriesTable}} vtable. The first may already just work. We may need to make some tweaks to {{TxnNamedRead}} and {{TxnWrite}} for the local operations though. ({{CommandStore}} tasks are out of scope here, as they would probably be more confusing than useful in {{QueriesTable}}?) 2.) A new vtable for pending commands for a key. - Disable SELECT */require a partition key - Might require partial back-port of stringifying table/partition key from Accord to be correct - ex. {{SELECT timestamps FROM myawesometable where ks=? and table=? and partition_key=?}} - Clustering can be the Accord timestamp elements, no further normal columns. 3.) A new vtable for command store-specific cache stats - Gather via {{Store.execute()}} for correctness. - Store id should be partition key (see {{AccordCommandStore}}) - hits, misses, total (maybe just throw out the keyspaces and coalesce ranges?) 4.) (Requires [~aweisberg]'s outstanding work) A new vtable for live migration state - {{TableMigrationState}} could be flattened into a row - Is this already persisted? If so, why a new vtable? 5.) A vtable to expose {{accord.local.Node#coordinating()}} as a map - ex. {{SELECT txn_id, type}} -- 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