executeBlocking in worker thread

[Nat]

From the code, it looks like executeBlocking will be executed by another thread instead of executed inline if the code is called from the worker thread. Wouldn't it be more reasonable to execute it inline to avoid deadlock in case that the worker thread pool is fully utilized?

[Tim Fox]

Not sure I follow, could you provide some more detail on this please?

On 10/07/15 22:34, Nat wrote:

From the code, it looks like executeBlocking will be executed by another thread instead of executed inline if the code is called from the worker thread. Wouldn't it be more reasonable to execute it inline to avoid deadlock in case that the worker thread pool is fully utilized?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francesco Cina]

Good point. I think Nat is right.

It could happen that (simplified scenario):
- ThreadPool has only one Thread
- the code block running in the Thread performs a call to executeBlocking
- Deadlock because no available Threads to execute the executeBlocking

With the proposal of Nat this will never happen if the executeBlocking call is executed in the same Thread of its blockink caller.

[Tim Fox]

Could you explain the point? I was awaiting clarification from Nat, but if you understand it then perhaps you could share? :)

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/06018124-f2dc-46a3-82f4-3435b8071b23%40googlegroups.com.

[Francesco Cina]

I guess that Nat is suggesting that if a portion of code is currently running in a worker Thread and it executes another blocking action through the executeBlocking() method, then this last blocking action could be executed in the current worker thread instead of a new one.

[Nat]

Thanks, Francesco. That's correct. This happens a lot if you don't have enough number of workers. The scenario is 

1. you have a thread worker-thread-1 to process the executeBlocking call.

2. you invoke executeBlocking call

3. inside executeBlocking call, you try to open a file via vert.fileSystem().openBlocking()

4. worker-thread-1 will block on waiting for openBlocking. However, openBlocking is waiting for worker-thread-1 to be available for execution.

[Tim Fox]

Can you create a reproducer?

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0e4ad80a-9d62-4921-abd2-dc09313bb624%40googlegroups.com.

[Nat]

I misinterpreted executeBlocking() a little bit. It looks like you can only cause a deadlock if you intentionally keep holding the thread like the following:

VertxOptions o = new VertxOptions().setWorkerPoolSize(1);
Vertx vertx = Vertx.vertx(o);
CompletableFuture<Void> t = new CompletableFuture<>();
vertx.executeBlocking(x1 -> {
    System.out.println(Thread.currentThread() + ": Execute1");
    vertx.executeBlocking(y1 -> {
        System.out.println(Thread.currentThread() + ": Execute2");
        t.complete(null);
        System.out.println(Thread.currentThread() + ": Executed2");
    }
            , y2 -> System.out.println("Done2"));
    System.out.println(Thread.currentThread() + ": Executed1");
    t.join();
}, z -> System.out.println("Done1"));

You will see the following output:

Thread[vert.x-worker-thread-0,5,main]: Execute1

Thread[vert.x-worker-thread-0,5,main]: Executed1

"vert.x-worker-thread-0@1013" prio=5 tid=0x16 nid=NA waiting

  java.lang.Thread.State: WAITING

 at sun.misc.Unsafe.park(Unsafe.java:-1)

 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

 at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1685)

 at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3320)

 at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1721)

 at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1926)

 at Main.lambda$main$2(Main.java:20)

 at Main$$Lambda$2.614685048.handle(Unknown Source:-1)

 at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$14(ContextImpl.java:279)

 at io.vertx.core.impl.ContextImpl$$Lambda$4.1375995437.run(Unknown Source:-1)

 at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor.lambda$new$161(OrderedExecutorFactory.java:91)

 at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor$$Lambda$1.1205555397.run(Unknown Source:-1)

 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

 at java.lang.Thread.run(Thread.java:745)

[Tim Fox]

Well, you only have one worker thread, so if you're already using that one, and try to execute another blocking action, then clearly that's not going to get executed until the worker is free.

I'd say that's a clear case of expected behaviour :)

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6f9d8720-3435-4aff-b09b-134dbaa79322%40googlegroups.com.

[Mumuney Abdlquadri]

I guess you don't need to wrap code in executeBlocking() in a Worker
Verticle. Vertx already knows you are blocking. Except I am not
getting it right.

> https://groups.google.com/d/msgid/vertx/55A5FE9E.6080108%40gmail.com.