why not both Future and CompletionHandler?

[wolfgang.baltes]

 On 2011-04-14 08:38, Alan Bateman wrote:

Sangjin Lee wrote:
Yes, I think it can come very handy if you want to add some cross-cutting concerns in the completion handlers but allow the end users to interact with the result via Future.

For example, suppose I build a framework/library for others using the async channels (HTTP app, ssh app, etc.). I want to allow my users freedom to choose between the "pull" (future) and the "push" (completion handler). However, *regardless* of what my end user choose to interact with the result, I want to be able to inject some concerns like logging, instrumenting, etc. in the form of a completion handler (can be completely internal to the framework).

With the current APIs, if the user wants a future, the framework cannot use the completion handler and I would need to find another way to inject such logic. Or if I want to retain the completion handler for the framework, then I would need to create my own future objects to provide to the end users. Either approach is doable, but it would be so much easier if the NIO.2 APIs provide both mechanisms in a single method call. My 2 cents. Thanks!
For high performance applications using completion handlers then we don't want to future Future objects that won't be used. In your framework/library then won't it return your own Future type anyway?

-Alan.

(This is a resend with subject filled in. Sorry, but I have email problems this morning.)
Hi,

I encountered a similar need. The problem I wanted to solve was that I didn't want to have my main code thread wait (or block) for completion of the I/O operation only to start a follow up task. I created a class

   class CompletionFuture
   extends FutureTask
   implements CompletionHandler

that does the trick. It's constructor takes a Callable as argument. The created object is a Future. The CompletionFuture's (or CompletionHandler's) completed(Integer, A) method essentially submits itself (in its role as FutureTask) to an ExecutionService. When this task is finished the get() method unblocks. The CompletionFuture's failed(Integer, A) method shortcuts the task by calling the setException(Throwable) method. Again, this unblocks get(), by throwing the exception. Alternatively, fail could also run the task using some instance field to indicate the failed condition.

I can send a skeletal version of my code if desired. I am not sure that this functionality is sufficiently generic to be of general interest as it may need to be adopted to every specific application. For example, the task could be executed by the same thread as the CompletionHandler, by an ExecutionService other than the main thread, or the thread pool in which the main thread runs.

Wolfgang.



Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/b1c52b90/attachment.html