[
https://issues.apache.org/jira/browse/HDFS-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854278#comment-13854278
]
Andrew Wang commented on HDFS-5636:
-----------------------------------
Thanks for the review Colin, fixed the comment and functionized CacheAdmin, the
rest inline:
bq. I think we should have a constant MAX_TTL_MS...
I added this, the enforcement was already in place, so this was just adding
another variable and tweaking usages a bit.
bq. Then we should not accept either relative or absolute limits...
I agree we should evaluate both relative and absolute limits against the same
relative max, but this means when converting to an absolute expiration for the
fsimage, the value could be greater than the relative max. Hope that's suitable.
bq. Can we have a static Expiration.NEVER final constant...?
I'm not sure that's much better, since it conflates Expiration's ability to do
absolute and relative expirations with this, which is just a relative. It's
also already the case that users need to use big longs for
{{Expiration.newRelative(long)}}, so it's not that different from the Java API
perspective. CacheAdmin wraps this up nicely of course.
> Enforce a max TTL per cache pool
> --------------------------------
>
> Key: HDFS-5636
> URL: https://issues.apache.org/jira/browse/HDFS-5636
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: caching, namenode
> Affects Versions: 3.0.0
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Attachments: hdfs-5636-1.patch, hdfs-5636-2.patch
>
>
> It'd be nice for administrators to be able to specify a maximum TTL for
> directives in a cache pool. This forces all directives to eventually age out.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
