I had a question regarding the project.
The problem I've encountered with Vert.x and using CompletableFutures is you have to be very explicit about which ThreadPool (EventLoop vs. WorkerThread) to run your chained tasks.
Consider the following:
public CompletableFuture<Void> write(RequestContext context) {
Assertions.assertOnEventLoop();
return new VertxCompletableFuture(vertx).supplyBlockingAsync( () -> {
Assertions.assertOnWorkerThread();
//do some work
}).thenRun( () -> {
//This assertion can fail!
Assertions.assertOnWorkerThread();
//do some work
});
}
We don't support supplyAsync. It's a static method with a clear semantic about the fork join thread pool (in java 8). It returns a new completable future (not a vert.x one).
Hello,
I had a question regarding the project. The problem I've encountered with Vert.x and using CompletableFutures is you have to be very explicit about which ThreadPool (EventLoop vs. WorkerThread) to run your chained tasks.
Consider the following:
CompletableFuture may schedule the
thenRun
on the client thread (EventLoop) if it noticed it has finished already (https://www.nurkiewicz.com/2015/11/which-thread-executes.html)The README claims that this sort of problem should be taken care of but I don't see how in the code. Looking for some more explanation.
The answer above is simple -- make to execute
thenRunBlocking
again, however its been a GOTCHA several times for me.