[
https://issues.apache.org/jira/browse/HDFS-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832141#comment-13832141
]
Colin Patrick McCabe commented on HDFS-5430:
--------------------------------------------
I think it would be nicer to have something like this:
{code}
public class CacheDirectiveInfo {
public static class Expiration {
public static Expiration newRelative(long ms) {
return new Expiration(ms, true);
}
public static Expiration newAbsolute(long ms) {
return new Expiration(ms, false);
}
public static Expiration newAbsolute(Date date) {
return new Expiration(date.toLong(), false);
}
private Expiration(long ms, boolean isRelative) {
this.ms = ms;
this.isRelative = isRelative;
}
public long toAbsolute() { // using local clock
...
}
private final long ms;
private final boolean isRelative;
}
...
}
{code}
That way, we wouldn't have to worry about the awkward situation of having two
fields in {{CacheDirectiveInfo}}, which can't be both used at the same time.
What do you think?
We can continue making this just a long in CacheDirective, since at that point,
it's always absolute. It would be nice to have a constant for NEVER, rather
than hard-coding -1 (Sun style guide discourages magic numbers.)
I also wonder if we can add a {{boolean expired}} or something to
{{CacheDirectiveStats}}, since otherwise the client can't easily figure out if
the directive has expired. After all, the clock on the NN might be different.
Looks good aside from that.
> Support TTL on CacheBasedPathDirectives
> ---------------------------------------
>
> Key: HDFS-5430
> URL: https://issues.apache.org/jira/browse/HDFS-5430
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, namenode
> Reporter: Colin Patrick McCabe
> Assignee: Andrew Wang
> Priority: Minor
> Attachments: hdfs-5430-1.patch, hdfs-5430-2.patch, hdfs-5430-3.patch
>
>
> It would be nice if CacheBasedPathDirectives would support an expiration
> time, after which they would be automatically removed by the NameNode. This
> time would probably be in wall-block time for the convenience of system
> administrators.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
