[concurrency-interest] CompletableFuture with delay

Millies, Sebastian Sebastian.Millies at softwareag.com
Mon Aug 25 14:48:01 EDT 2014


Although I really was not doing that in my OP, showing method delayedSuccess(), I did fall into exactly this trap with my second example, showing method supplyAsyncWithTimeout(), which I think is what Zhong was talking about. That method should be reformulated like this:


public static <T> CompletableFuture<T> supplyAsyncWithTimeout(Supplier<T> supplier, Executor executor, T defaultValue,

      int timeout, TimeUnit unit) {

    CompletableFuture<T> compute = CompletableFuture.supplyAsync(supplier, executor);

    CompletableFuture<T> useDefault = delayedSuccess(defaultValue, timeout, unit);

    CompletableFuture<T> either = compute.applyToEither(useDefault, Function.identity());

    either.whenComplete((t, ex) -> {

      compute.cancel(true);

      useDefault.cancel(true);

    });

    return either;

  }

Now the returned future can be cancelled, the cancellation will cause the completion method to be called, which in turn will propagate the cancellation to both embedded futures.


n  Sebastian

From: Peter Levart [mailto:peter.levart at gmail.com]
Sent: Monday, August 25, 2014 6:22 PM
To: Zhong Yu; Millies, Sebastian
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] CompletableFuture with delay

On 08/25/2014 05:32 PM, Zhong Yu wrote:

If you expose it as CompletableFuture, the caller is able to complete() it.

If you expose it as CompletionStage, the caller has no way to "cancel()" it.



Also note that CompletableFuture composition does not propagate

cancellation. If the caller of your supplyAsyncWithTimeout() decides to

cancel the returned future for some other reason, it will not trigger

`compute.cancel()` or `task.cancel()`.



    future1 = ...

    future2 = future1.whenComplete(...)

    ...

    future2.cancel()  // does not affect future1

I think that's because future2 is dependent on future1 and not vice versa. You could have:

future2 = future1.whenComplete(...);
future3 = future1.whenComplete(...);

Now of course, cancelling future2 should not have an effect on computation of future3.

If you call future1.cancel(), then both future2 and future3 will complete with CompletionException having the future1's CancelationException as their cause...

But that's not what Sebastian is doing. He is returning 'future1' and cancelling it does call the completion function.

Regards, Peter







Zhong Yu

bayou.io






_______________________________________________

Concurrency-interest mailing list

Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>

http://cs.oswego.edu/mailman/listinfo/concurrency-interest


Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140825/92b85834/attachment-0001.html>


More information about the Concurrency-interest mailing list