hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5636) Enforce a max TTL per cache pool
Date Fri, 20 Dec 2013 17:44:11 GMT

    [ 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

View raw message