[
https://issues.apache.org/jira/browse/HDFS-9847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205369#comment-15205369
]
Chris Douglas commented on HDFS-9847:
-------------------------------------
bq. Sorry I didn't understand your proposal to handle compatibility in the last
para, agreed with everything before that.
For params without units we warn, which is consistent with our current strategy
for deprecating config knobs. If the impl increases precision, then nothing
distinguishes throw/nothrow. If we decrease precision, the nothrow
implementation can decide what to do: discard lost precision (default), check
the old precision and warn, or throw; if {{getTimeDuration}} throws, then old
configs will throw (default) unless the impl checks the old precision and
warns, or discards.
w.r.t. compatibility, the only difference is the default for decreasing
precision. The caller is explicitly saying they want the unit in
seconds/hours/days, and following the semantics of {{TimeUnit}} seems
preferable to an error.
I see your point about our existing cases: we can't switch from
{{some.config.seconds}} to {{some.config}} with a default in millis by aliasing
the former to the latter. We need to first warn that {{some.config.seconds}} is
deprecated in a release, then drop it in the next. Where {{some.config}} has no
units in the key, we can't convert the API to use {{getTimeDuration}} and
increase precision in the same release. To be fair, this isn't less flexibility
than we have now: we don't specify {{some.config\[.seconds\]}} as a float.
The opacity of discarded precision creating the possibility for misattribution
(e.g., "increasing the hb interval from 1s to 1500ms improved stability" when
it's noise) is also a concern, but I'd argue that's not a failure of the API.
bq. To continue the example of heartbeat interval do you mean we continue to
query it with a unit of seconds for now and discard precision without throwing?
Yes. Similar to the discussion on casting the result to int, the caller is
responsible for precision.
All that said, while I think nothrow is preferable, I won't insist on it and am
+0 on the latest patch.
> HDFS configuration without time unit name should accept friendly time units
> ---------------------------------------------------------------------------
>
> Key: HDFS-9847
> URL: https://issues.apache.org/jira/browse/HDFS-9847
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Affects Versions: 2.7.1
> Reporter: Lin Yiqun
> Assignee: Lin Yiqun
> Attachments: HDFS-9847.001.patch, HDFS-9847.002.patch,
> HDFS-9847.003.patch, HDFS-9847.004.patch, HDFS-9847.005.patch,
> HDFS-9847.006.patch, timeduration-w-y.patch
>
>
> In HDFS-9821, it talks about the issue of leting existing keys use friendly
> units e.g. 60s, 5m, 1d, 6w etc. But there are som configuration key names
> contain time unit name, like {{dfs.blockreport.intervalMsec}}, so we can make
> some other configurations which without time unit name to accept friendly
> time units. The time unit {{seconds}} is frequently used in hdfs. We can
> updating this configurations first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
