[
https://issues.apache.org/jira/browse/HDFS-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HDFS-5326:
---------------------------------------
Attachment: HDFS-5326.003.patch
* adjust protobufs as recommended in HDFS-5166. Specifically, create a
{{PathBasedCacheDirectiveInfoProto}}, and use it in the add, modify, and list
RPCs. This avoids having to duplicate those fields everywhere.
* get rid of the descriptor / directive division. Having many different types
for the same thing is confusing to users. The only advantage of the division
is that it prevented using a Directive with an ID in a context where that was
inappropriate; however, we can simply validate this in the one case it matters
(in FSNamesystem when doing addDirective). This also gets rid of some
long-standing WTFs (why does -removeDirective remove a descriptor?, etc)
* Both the directive type and the protobuf now have all fields optional. We
can simply validate that fields exist when we need them. This will be helpful
later in allowing us to compatibly add new fields, once compatibility becomes a
big concern (in branch-2).
* add {{modifyPathBasedCacheDirective}}, which modifies an existing PBCD.
* in CacheManager, there were a few cases where we were converting a PBCE to a
PBCD, just to get some field we could have accessed directly in the PBCE. Just
access the field directly from the PBCE.
* in CacheManager, use try ... catch and log all {{IOException}} objects that
were thrown, rather than making the programmer duplicate the failure message in
the log and in the thrown exception. This does change some indentation but it
makes things much cleaner on the whole.
* use standardized exceptions like {{AccessControlException}} rather than
custom ones like {{AddPathBasedCacheDirectiveException}}. Add
{{IdNotFoundException}} to the common set of exceptions.
* {{addPathBasedCacheDirective}] now returns an ID, not a Directive. The
previous situation was confusing because the object that was being returned had
its ID based on what the NameNode set, but the rest of the fields left
identical to what the client passed. This could result in some of the fields
being wrong. So just return to the client what the server returned.
* Similarly, {{removePathBasedCacheDirective}} now just takes an ID, not an
object. It's confusing to take an object, since it obscures the fact that we
only look at one field (ID). Making the parameter an object encourages people
to try to remove by path or some other field, which simply won't work.
Calling Directive#getId is straightforward and makes it obvious what is going
on.
* Make sure that AddPathBasedCacheDirectiveOp stores the ID of the created
directive. Previously, we were relying on the ordering of the directives and
the ID assignment order, which is brittle. If any edit log entries are
unreadable, this strategy fails completely. Storing the ID is much more robust.
> add modifyDirective to cacheAdmin
> ---------------------------------
>
> Key: HDFS-5326
> URL: https://issues.apache.org/jira/browse/HDFS-5326
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, namenode
> Affects Versions: 3.0.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-5326.003.patch
>
>
> We should add a way of modifying cache directives on the command-line,
> similar to how modifyCachePool works.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
