rustyrazorblade opened a new issue, #105:
URL: https://github.com/apache/cassandra-easy-stress/issues/105
### Summary
The `Sets` workload fails 100% of writes with `CodecNotFoundException`.
Reads succeed. No server-side error occurs; the failure is entirely client-side
in the binding.
### Impact
A QUORUM write-heavy `Sets` run reports zero successful writes and a high
client error rate (observed ~635k errors, ~4,199/s), while reads continue at
their normal rate (~461/s). The workload produces no useful stress and its
error rate pollutes dashboards.
### Root cause
`Sets` binds the whole collection by its concrete class. In
`src/main/kotlin/org/apache/cassandra/easystress/workloads/Sets.kt`:
`getNextMutation`, line 63:
```kotlin
bound.set(0, valueSet, java.util.HashSet::class.java)
```
`getNextDelete`, line 83:
```kotlin
bound.set(0, valueSet, java.util.HashSet::class.java)
```
The DataStax Java driver v4 registers the `set<text>` codec against the
`java.util.Set` interface, not against `HashSet`. Looking up a codec for
`set<text>` paired with `HashSet.class` throws `CodecNotFoundException` on
every write and every delete.
The `select` binds only a `String` key, so reads are unaffected. `Maps` is
unaffected because it binds scalar sub-cells (`SET data[?] = ?`), never a whole
collection by class.
### Proof it is a client-side bug, not a server or driver bug
- No node logged a server-side error; the client error counter reached the
requests but `client_request_error_total` stayed at 0 server-side.
- The same write shape works via plain CQL: `UPDATE sets SET values = values
+ {'a','b'} WHERE key='k1'` inserts and reads back correctly.
- The driver behaves per contract: it registers the codec against the `Set`
interface.
### Suggested fix
Bind by the interface, or use the typed setter, at both call sites:
```kotlin
bound.setSet(0, valueSet, String::class.java)
```
Apply the same change on line 83.
### Environment
- cassandra-easy-stress against a 3-node Cassandra 6.0-alpha3 cluster.
- DataStax Java driver v4.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
