[
https://issues.apache.org/jira/browse/HDFS-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780507#comment-13780507
]
Chris Nauroth commented on HDFS-5203:
-------------------------------------
Both usages seem valid for different use cases, so what do you think about
adding API support for both?
Concurrently running apps that both want to cache the same hot file without
interfering with each other create independent cache directives for the same
path, but get issued different unique IDs. When done, the client calls
something like {{deleteCacheDirectiveById(id)}}, which deletes only that
client's cache directive. Whether or not this actually triggers an {{munlock}}
on the datanode depends on whether or not there are any other cache directives
remaining on that path.
System administrators who need to remove all cache directives for a path can
run "hdfs cacheadmin -removeAllForPath <path>", which delegates to a
{{deleteAllCacheDirectivesByPath(path)}} API. (We'd still preserve the
cacheadmin tool's ability to delete a single cache directive by ID, because
that's probably still useful too.)
> Concurrent clients that add a cache directive on the same path may
> prematurely uncache from each other.
> -------------------------------------------------------------------------------------------------------
>
> Key: HDFS-5203
> URL: https://issues.apache.org/jira/browse/HDFS-5203
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: HDFS-4949
> Reporter: Chris Nauroth
>
> When a client adds a cache directive, we assign it a unique ID and return
> that ID to the client. If multiple clients add a cache directive for the
> same path, then we return the same ID. If one client then removes the cache
> entry for that ID, then it is removed for all clients. Then, when this
> change becomes visible in subsequent cache reports, the datanodes may
> {{munlock}} the block before the other clients are done with it.
--
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
