adelapena commented on code in PR #2246:
URL: https://github.com/apache/cassandra/pull/2246#discussion_r1158464478
##########
src/java/org/apache/cassandra/db/guardrails/GuardrailsMBean.java:
##########
@@ -651,4 +651,56 @@
* @param value {@code true} if 0 default TTL on TWCS tables is allowed,
{@code false} otherwise.
*/
void setZeroTTLOnTWCSEnabled(boolean value);
+
+ /**
+ * @param currentTimestamp the current timestamp
+ * @return The highest acceptable timestamp before triggering a warning
+ */
+ long getMaximumTimestampWarnThreshold(long currentTimestamp);
+
+ /**
+ * Sets the warning upper bound for user supplied timestamps
+ *
+ * @param durationSeconds currentTimestamp +
TimeUnit.SECONDS.toMicros(duration)
+ */
+ void setMaximumTimestampWarnThreshold(int durationSeconds);
Review Comment:
During the initial review for guardrails we decided to use a common setter
method for both the warn and fail threshold. IIRC the reason was that the
requisite of keeping the warn threshold lesser than the fail threshold imposes
a certain order on how the separate setter would need to be called. For
example, consider the following:
```java
guardrails().setMinimumTimestampWarnThreshold(1);
guardrails().setMinimumTimestampFailThreshold(2);
```
That might fail or not fail depending on the previous value of the fail
threshold. However, the combined setter will always succeed:
```java
guardrails().setMinimumTimestampThreshold(1, 2);
```
I think we should keep the current style of combined setters in
`GuardrailsMBean` for the sake of consistency.
--
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]
