[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273767#comment-16273767 ] Jeff Jirsa commented on CASSANDRA-13976: Encourage you to ask dev@ - I was going to suggest that as well. Pretty -0 on this right now (it's pretty firmly in the "I wouldn't do this, but I'm not going to really go out of my way to hard veto it" category). My primary concern is that as we change yaml params, years of blog posts become irrelevant, and eventually we'll deprecate out the old ones and remove them, and then someone's rolling upgrade will break. "Of course you have to change yaml with major versions", you say, but the less true that is, the better life is for users. > introduce max_hint_window_in_min, deprecate max_hint_window_in_ms > - > > Key: CASSANDRA-13976 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13976 > Project: Cassandra > Issue Type: Improvement >Reporter: Jon Haddad >Assignee: Kirk True >Priority: Minor > Labels: lhf > Fix For: 4.0 > > > Milliseconds is unnecessarily precise. At most, minutes would be used. > Config in 4.0 should default to a minute granularity, but if the > max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms > and emit a warning. > max_hint_window_in_min: 180 # new default, still at 3 hours. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273764#comment-16273764 ] Jon Haddad commented on CASSANDRA-13976: I'd actually like to get some feedback on -dev regarding this. I'd like to change *every* setting to use duration types, because it makes it less error prone to set. Mistyping a millisecond based config is pretty easy and hard to catch when it's wrong. > introduce max_hint_window_in_min, deprecate max_hint_window_in_ms > - > > Key: CASSANDRA-13976 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13976 > Project: Cassandra > Issue Type: Improvement >Reporter: Jon Haddad >Assignee: Kirk True >Priority: Minor > Labels: lhf > Fix For: 4.0 > > > Milliseconds is unnecessarily precise. At most, minutes would be used. > Config in 4.0 should default to a minute granularity, but if the > max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms > and emit a warning. > max_hint_window_in_min: 180 # new default, still at 3 hours. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273758#comment-16273758 ] Jeff Jirsa commented on CASSANDRA-13976: We have 25 other config options that take millis. Why are we changing one, when it's one that's rarely tuned anyway? There are plenty others (auth permission validity) that is also almost certainly never set in milliseconds that you haven't suggested changing. How do you propose we keep consistency there? Is this really something where the ease of setting it once is going to outweigh the config churn for the typical user? > introduce max_hint_window_in_min, deprecate max_hint_window_in_ms > - > > Key: CASSANDRA-13976 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13976 > Project: Cassandra > Issue Type: Improvement >Reporter: Jon Haddad >Assignee: Kirk True >Priority: Minor > Labels: lhf > Fix For: 4.0 > > > Milliseconds is unnecessarily precise. At most, minutes would be used. > Config in 4.0 should default to a minute granularity, but if the > max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms > and emit a warning. > max_hint_window_in_min: 180 # new default, still at 3 hours. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[
https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273727#comment-16273727
]
Jon Haddad commented on CASSANDRA-13976:
I've thought about this a bit more, and I think across the board we should be
using duration types and get rid of the _ms label altogether.
It's WAY more readable and friendly to be able to do:
{code}
max_hint_window = 3h
{code}
Regarding nodetool, it would report back whatever setting was in there.
Internally, it would convert everything to ms, leaving the current code in
place.
> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
> Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise. At most, minutes would be used.
> Config in 4.0 should default to a minute granularity, but if the
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[
https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273722#comment-16273722
]
Kurt Greaves commented on CASSANDRA-13976:
--
Not necessary to support both, just convert the minute value to ms if the
{{max_hint_window_in_min}} property exists, otherwise use the
{{max_hint_window_in_ms}} value or default if neither exist.
TBH I don't think we should ever completely get rid of the ms config option as
I wouldn't be surprised if there are tests relying on setting it to <1min, but
we could remove it from the default yaml and add in the minute based config
instead.
> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
> Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise. At most, minutes would be used.
> Config in 4.0 should default to a minute granularity, but if the
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[
https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246847#comment-16246847
]
Kirk True commented on CASSANDRA-13976:
---
Is it possible to use the {{DatabaseDescriptor.applySimpleConfig}} to convert
from milliseconds to minutes so that the code can just use minutes everywhere?
> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
> Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise. At most, minutes would be used.
> Config in 4.0 should default to a minute granularity, but if the
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
[
https://issues.apache.org/jira/browse/CASSANDRA-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246835#comment-16246835
]
Kirk True commented on CASSANDRA-13976:
---
After thinking about this a little bit, it would seem that we need to support
both {{max_hint_window_in_ms}} and {{max_hint_window_in_min}} everywhere. We
would need to add:
# {{max_hint_window_in_min}} to {{Config}}
# {{getMaxHintWindowInMin}}/{{setMaxHintWindowInMin}} methods in
{{DatabaseDescriptor}}, {{NodeProbe}}, {{StorageProxy}}, {{StorageProxyMBean}},
etc.
# A new {{GetMaxHintWindowInMin}} class to match {{GetMaxHintWindow}} to get
the value via {{nodetool}}
# A new {{SetMaxHintWindowInMin}} class to match {{SetMaxHintWindow}} to set
the value via {{nodetool}}
There would need to be a decision about which of {{max_hint_window_in_ms}} or
{{max_hint_window_in_min}} to actually use internally. Regardless of whichever
unit we used internally we'd likely have to convert from and to the other unit
to maintain a coherent interface. For example, if we used minutes internally,
the {{shouldHint}} method in {{StorageProxy}} would need to convert back to
milliseconds from minutes anyway. Also, we'd need to convert back and forth for
users of JMX and {{nodetool}}.
I'm not trying to argue that it's not a good change, I'm just wondering how to
do it in a way that doesn't introduce complexity and confusion for end users
and developers.
> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
> Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise. At most, minutes would be used.
> Config in 4.0 should default to a minute granularity, but if the
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
