Returning a customized CompletableFuture to replace standard CompletableFuture.

[chickenlj]

Instead of returning a standard CompletableFuture for an async call, consider returning a customized Future instance, for example, DubboFuture extends CompletableFuture, so that we can override the default behaviors of the Future, for example, cancel, get and so on.

What do you think?

[carryxyh]

Hi,

I totally agree. I think the futureAdapter in version 2.7.x is a very good design. I also borrowed this design from the rpc asynchronous of music163. Because in a distributed scenario, the cancel method is obviously not effective.

[kun-song]

+1, so we can bring some features of Java 9' CompletableFuture to it.

[chickenlj]

I also borrowed this design from the rpc asynchronous of music163. Because in a distributed scenario, the cancel method is obviously not effective.

@carryxyh do you mean you already have some similar practices in work? It would be great if you could tell more about the details, for example, what do you do when a user calls FutureAdapter.cancel().

[carryxyh]

yes.
In rpc inside music163, I made an asynchronous attempt (client). The idea draws on the asynchronous version of the 2.7.x version. It works fine now.

In internal practice, we also directly returned an instance like FutureAdapter. I disabled his cancel operation directly, and we still have no scenes using cancel.

[chickenlj]

+1, so we can bring some features of Java 9' CompletableFuture to it.

Yes, this can also be a good point to do that.

[chickenlj]

Added comments in FutureAdapter, enhance later.