[
https://issues.apache.org/jira/browse/CASSANDRA-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712322#comment-17712322
]
Andres de la Peña commented on CASSANDRA-18352:
-----------------------------------------------
Great, thanks.
A detail that is missing is using [a single
setter|https://github.com/apache/cassandra/pull/2246#discussion_r1158464478]
for both the warn and fail thresholds, [this
way|https://github.com/adelapena/cassandra/commit/8cf47d8be03d7563762acd320866b86b9952d25c].
Something that I missed on my first review round is that the guardrails for
column and collection sizes use {{String}} arguemnts on the JMX methods that
manipulate the underlying {{DataStorageSpec}} attributes. Those
{{{}String{}}}-based methods are probably more useful than directly expressing
the thresholds in bytes, and give us a good alignment between JMX and the
values on {{{}cassandra.yaml{}}}.
We should probably also use {{String}} arguments on the JMX methods for new
{{{}DurationSpec{}}}-based guardrails, That way they would be better aligned
with the other guardrails and the {{cassandra.yaml}} properties. [This
commit|https://github.com/adelapena/cassandra/commit/4a40d94fae723655ef90c6a94817cf49676f0b3c]
shows how the approach would look like.
Once we have standarized the JMX methods for the new guardrails, we can make
their tests extend {{{}ThresholdTester{}}}. The benefit of doing so is that
{{ThresholdTester}} includes some testing for config validation that we are
missing on the current tests. This requires some minor changes on
{{ThresholdTester}} in order to make it work with {{{}DurationSpec{}}}-based
guardrails. I have included those changes in the previous commit.
A final detail would be adding some tests for the new
{{DurationSpec.LongMicrosecondsBound}} class. Those tests can be added on
[{{DurationSpecTest}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/config/DurationSpecTest.java],
which already contains tests for the other subclasses of {{{}DurationSpec{}}}.
Regarding CI, I think that the runs are not running the jobs to repeatedly run
the new tests. Those jobs are meant reduce the risk of introducing new flakies.
The CircleCI config file including the repeated runs can be generated by
running:
{code:java}
.circleci/generate.sh -p{code}
> Add Option to Timebox write timestamps
> --------------------------------------
>
> Key: CASSANDRA-18352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18352
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
> Reporter: Jordan West
> Assignee: Jordan West
> Priority: Normal
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> In several cases it is desirable to have client provided timestamps generated
> at the application-level. This can be error prone, however. In particular,
> applications can choose timestamps that may be nonsensical for a given
> application. One dangerous manifestation of this is the "doomstone" (a
> tombstone far in the future of any realistic write). This feature would allow
> either operators or users to specify a minimum and maximum timebound of
> "reasonable" timestamps. The default would be negative infinity, positive
> infinity to maintain backwards compatibility. Writes that are USING TIMESTAMP
> with a timestamp outside of the timebox will see an exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
