[
https://issues.apache.org/jira/browse/HDFS-5158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763999#comment-13763999
]
Colin Patrick McCabe commented on HDFS-5158:
--------------------------------------------
"CachedPath" would be a misleading name, since we may or may not actually be
able to cache the path entries in PathCache. Resources aren't infinite. Bear
in mind that there are going to be other caches that don't operate by path
name-- one example is the LRU cache we've talked about. PathCache, as well as
PathCacheDirective, PathCacheEntry, etc. are named the way they are to
distinguish them from the (future) LruCacheDirective, etc. classes which don't
exist yet.
We could perhaps use "PathBasedCache" instead of "PathCache," at the cost of
adding a few more letters to every type name.
I like the idea of using the prefix "cacheadmin"-- I'll see if I can reorganize
it to use that prefix. We should probably move the pool stuff under there as
well.
bq. Why is it that the add and remove methods and RPCs both take lists of
paths/pools, but the actual command line commands only ever take a single
identifier? Seems to me like we should change the methods/RPCs to only take a
single argument here.
One of the design requirements was that we have a bulk add/remove interface.
This is important for performance. For example, Impala or Hive may want to add
many cache directives at once. On the other hand, the shell's performance is
not overly important so it can just send one at a time, at least for now.
bq. Not clear to me why both the list and add commands take paths/pools as
arguments, but the remove command takes an id. Why not make that command
symmetric with the others?
We discussed this on HDFS-5052. The short summary is that paths don't uniquely
identify path cache directives. You can have multiple directives that apply to
the same path.
bq. [javadoc comments]
fixed.
bq. You should definitely include the actual invalid path name in an IOE
fixed.
bq. If you mark some class as being InterfaceAudience.Private then there's no
need to also mark its InterfaceStability, since there should be no external
consumers of it. You do this in a few places.
I actually just added those InterfaceStability uses because Andrew asked for
them in his previous review :P
https://issues.apache.org/jira/browse/HDFS-5158?focusedCommentId=13763484&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13763484
But now that you've explained the logic, I'll remove them. thanks.
> add command-line support for manipulating cache directives
> ----------------------------------------------------------
>
> Key: HDFS-5158
> URL: https://issues.apache.org/jira/browse/HDFS-5158
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, namenode
> Affects Versions: HDFS-4949
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-5158-caching.003.patch,
> HDFS-5158-caching.004.patch, HDFS-5158-caching.005.patch
>
>
> We should add command-line support for creating, removing, and listing cache
> directives.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
