[
https://issues.apache.org/jira/browse/HDFS-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189945#comment-15189945
]
Tsz Wo Nicholas Sze commented on HDFS-9924:
-------------------------------------------
> ... If you can lay down that async operations happen in the order requested,
> then that's a stronger guarantee than having a pool of threads doing
> synchronous calls of runnables.
As the first step, we won't provide ordering guarantee as [~cnauroth]
mentioned. It is a nice thing to have but it needs more works, in particular,
server side change. We will put down ordering guarantee as a future work.
> ... then I find it really hard to see how I would use this as a developer ...
As you pointed out, it is for independent operations such as parallel deletes
and parallel (independent) renames. The number of operations may be large
(hundreds or thousands) so that the parallelism really helps.
On the other hand, I don't see a need to support running dependent operations
in asynchronous mode since the number of operations is usually small.
> ... this sounds like a good chance to play with Java 8's new language
> features ...
Personally, I also like to play with Java 8's new features. Unfortunately, it
is a future work and definitely outside the scope of the first step.
> [umbrella] Asynchronous HDFS Access
> -----------------------------------
>
> Key: HDFS-9924
> URL: https://issues.apache.org/jira/browse/HDFS-9924
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: fs
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Xiaobing Zhou
>
> This is an umbrella JIRA for supporting Asynchronous HDFS Access.
> Currently, all the API methods are blocking calls -- the caller is blocked
> until the method returns. It is very slow if a client makes a large number
> of independent calls in a single thread since each call has to wait until the
> previous call is finished. It is inefficient if a client needs to create a
> large number of threads to invoke the calls.
> We propose adding a new API to support asynchronous calls, i.e. the caller is
> not blocked. The methods in the new API immediately return a Java Future
> object. The return value can be obtained by the usual Future.get() method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)