executeBlocking Vs Worker Thread

[J0t1]

Hello,

I am working on a vertx project in which we need to call EJB3 deployed in an application server(JBoss) to get some data .

AFAI understand this will be a blocking code and should not go in my main vertical, hence i was contemplating on using either executeBlocking or WorkerVertical for the same.

I have written some sample code and observed that in both these approaches the code i write (inside executeBlocking method or worker vertical start method) is getting executed by worker threads and not by event loop thread. I am not clear on  what is the difference between these 2 approaches?

Using executeBlocking seems to be easier to implement from code perspective as I can directly get the java object which EJB invocation returns and use it. While for using worker vertical i need to use event bus to communicate between my main and worker verticals and convert my Java objects into json and pass them on event bus. I read that we can pass POJOs on event bus by using message codes but yet to try them out (haven't found any example for that yet)

Can someone please guide me on what are the pros and cons of each approach? Is it OK to use executeBlocking instread of WorkerVertical ? Can we configure worker thread pool size in case we are using executeBlocking?

Thanks in advance!

[Julien Viet]

Hi,

you are right, both approach are similar in term of threading model.

The main difference is how you distribute you services. With an executeBlocking block, you use directly the blocking resource with no worker deployment needed, that’s it. With the event bus, you 'encapsulate' the blocking resource behind the event bus and introduce lose coupling between your the consumer and the EJB. Both approach have their respective pro/cons . Perhaps you can start simple and use executeBlocking and later you can use the event bus if you need this decoupling.

Both use the same pool configured with VertxOptions#workerPoolSize 

-- 
Julien Viet
Sent with Airmail

--
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/659762e1-9c46-4384-b012-b2d19e52d2ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[J0t1]

Thanks Julien for your quick and crisp reply :)

Main problem I am facing in using event bus at this moment is converting java objects to json and then back to java while consuming them as my dtos are pretty complex. 

Can you point me to any example which uses message codec for sending custom pojo over event bus.

Appreciate your help on this!

[Julien Viet]

there are a few here : https://github.com/eclipse/vert.x/blob/master/src/test/java/io/vertx/test/core/LocalEventBusTest.java#L775

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d6a941de-5e3a-4a56-88da-55c533d0a531%40googlegroups.com.

[J0t1]

Excuse my ignorance but I want to see some implementation class for Message codec i.e. code for MyPOJOEncode1 class in the example provided in link you have shared.

[Julien Viet]

it is in the parent test class : https://github.com/eclipse/vert.x/blob/master/src/test/java/io/vertx/test/core/EventBusTestBase.java#L458

-- 
Julien Viet
Sent with Airmail

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8cb211c6-ab7a-4f3c-931e-f5ed393c1a6a%40googlegroups.com.

[J0t1]

Thanks again Julien! This should be of great help to me , I will have a look.

[J0t1]

I am able to do EJB call using both executeBlocking as well as Worker vertical approach. Trying to do some error handling now. I want to timeout the request if EJB call is taking too much time.When using event bus to communicate we can set message time out duration in delivery options e.g. 

DeliveryOptions deliveryOptions = new DeliveryOptions().setSendTimeout(120000);

vertx.eventBus().send("ejb.lookup",object,deliveryOptions, r -> {
    if (r.succeeded()) {

  logger.info("[Main] Receiving reply ' " + r.result().body().toString()+ "' in " + Thread.currentThread().getName());
    routingContext.response().end(r.result().body().toString());

 }else{
    logger.error("Response from event bus either failed or timed-out!");

   routingContext.response().end("Error occurred while EJB Invocation!!!");

}

But with executeBlocking the thread waits for long time(10+ minutes) before i get timeout exception from RMI call.  Is there any way to set timeout value in this case?

[Julien Viet]

in case of executeBlocking you need to do it yourself using a vertx timer, the timer should be in the code that calls executeBlocking and not in the blocking code (obviously).

AtomicBoolean done = new AtomicBoolean();

long id = vertx.setTimer(1000, v -> {

  if (done.compareAndSet(false, true)) {

    // Handle timeout here

  }

});

vertx.executeBlocking(ejbBlock, ar -> {

  if (done.compareAndSet(false, true) {

    vertx.cancelTimer(id);

    // Handle the result or failure

  }

});

note that, I used AtomicBoolean not for synchronization purpose (it is the same event loop thread) but rather to have some mutable state in the example. Using a boolean field would also work the same.

-- 
Julien Viet
www.julienviet.com

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/decb1f60-73e5-4477-be14-266bdad76af9%40googlegroups.com.

[J0t1]

Thanks a ton for your help. I have been breaking my head over this for quite some time. Your code worked like a charm !!!

Sorry if i sound lame but will using vertx.setTimer block the event loop thread for the duration specified ? Also if it gets timed out before ejb call is completed , will the worker thread be freed up for handling subsequent requests or they will still be hanging waiting for the operation to complete?

[Julien Viet]

1/ the timer does not block anything, however if you execute the timer in the executeBlocking code block then the blocked thread cannot fire the timer since it is blocked.

2/ no the EJB will still continue to block, the timer will only make the callback react on a timeout. Note that you could unlock the blocked thread from the timer event loop callback if the thread is blocked in an interruptible wait using blockingThread.interrupt (like a wait on an object monitor) . But I think it is safe to let the EJB container do its job, EJB are not designed for being interrupted I think (not sure I’m not EJB specialist).

you can learn more about Vert.x programming model in this article I wrote a while ago : https://github.com/vietj/vertx-materials/blob/master/src/main/asciidoc/Demystifying_the_event_loop.adoc

[J0t1]

I tried this scenario by setting the worker thread pool to 2 and sending 3 requests using jmeter and found that the worker thread is indeed held up so my 3rd request times out without even going to the executeBlocking code ! This might become a bottleneck in my scenario. 

If i use a worker vertical(to make EJB call) instead and set timeout duration on the message and the call takes longer than expected then my r.succeeded() will return false and i can handle that. But what will happen to the worker thread in this case ?

Also, I observed that when i send concurrent requests using jmeter, all the calls to code inside executeBlocking where getting processed sequentially and not parallel and using the same (worker) thread!(i am printing thread name using Thread.currentThread().getName() inside executeBlocking). After i modified the code to  pass the "ordered" parameter as false in executeBlocking the requests started getting processed parallely and using different (worker) threads. 

The link you provided was very informative, Thanks for sharing. 

[Julien Viet]

On 24 Jul 2015 at 20:26:10, J0t1 (jyoti.s...@gmail.com) wrote:

I tried this scenario by setting the worker thread pool to 2 and sending 3 requests using jmeter and found that the worker thread is indeed held up so my 3rd request times out without even going to the executeBlocking code ! This might become a bottleneck in my scenario. 

If i use a worker vertical(to make EJB call) instead and set timeout duration on the message and the call takes longer than expected then my r.succeeded() will return false and i can handle that. But what will happen to the worker thread in this case ?

I’m not sure to understand the question about the worker thread. The worker thread is blocked until it does not block anymore and that does not depend on Vert.x.

[J0t1]

Rephrasing my question, If a message is sent to Worker vertical with timeout duration(say 1min) and operation done by worker thread is taking longer time(doing an ejb/db call which is not responding), then the caller will get timed out after 1 min but in the background that worker thread is still blocked,waiting for the operation to complete i.e. it cannot take up any more requests untill this one is completed though its response is already sent!

Is there anyway to terminate the current execution and make the thread "available" again in the thread pool for picking up other requests on timeout? and is it advisable to do so?

One more thing i observed is, if worker thread continues blocking even after eventbus msg timeout , i keep getting this exception every 1 second

Thread Thread[vert.x-worker-thread-1,5,main] has been blocked for 60439 ms, time limit is 60000

io.vertx.core.VertxException: Thread blocked

As worker verticals are meant for blocking code, why is vertx complaining? And is there any way for this error to stop appearing continuously?

Thanks in advance !

[Tim Fox]

On 24/07/15 19:26, J0t1 wrote:

I tried this scenario by setting the worker thread pool to 2 and sending 3 requests using jmeter and found that the worker thread is indeed held up so my 3rd request times out without even going to the executeBlocking code ! This might become a bottleneck in my scenario. 

If i use a worker vertical(to make EJB call) instead and set timeout duration on the message and the call takes longer than expected then my r.succeeded() will return false and i can handle that. But what will happen to the worker thread in this case ?

Also, I observed that when i send concurrent requests using jmeter, all the calls to code inside executeBlocking where getting processed sequentially and not parallel and using the same (worker) thread!

executeBlocking has parameter "ordered" (default is true).

If you don't want ordered then set it to false. See the docs for more info.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/ab748792-bbd0-43db-888a-ffc8292167b0%40googlegroups.com.

[Levon T]

Hi, 

I understand the architectural differences. But I am curious about performance ramifications, are there any? I am planning on doing benchmarking myself, but wanted to get outside opinions / perhaps links to already existing benchmarks. Specifically, it seems like message parsing on the event bus would in any case be a performance hinderance. I was wondering if there are any added benefits for using a pool of worker verticles? Perhaps higher concurrency capabilities? Or is threading in the event loop identical in every way? 

Thank you,

[Julien Viet]

Hi,

your question is not clear, you are asking of comparison of worker handler versus execute blocking then you mention event loop, what is it you want to know ?

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d1038b82-fdef-4898-b430-e30f9710b48b%40googlegroups.com.

[Levon T]

My apologies, allow me to try and clarify. 

Basically I am trying to understand if there are differences between event loop threads and worker threads. And the pros and cons of each. 

When I do execute blocking, it starts of not he event loop thread, then the blocking code is passed to a worker thread, and the handler is on the same event loop thread. 

If I do execute blocking on a worker vertical, the starts right away on the worker thread, then the blocking code is passed to another worker thread, and the handler is on the original worker thread. 

So what I'm asking is what are the differences between an event loop thread, and a worker thread. Are event loop threads more limited? Are there performance differences? Memory? Basically besides encapsulation, are there any technical (non design) reasons why I would use a worker thread instead executeBlocking on an event loop? 

I've read the great guide https://github.com/vietj/vertx-materials/blob/master/src/main/asciidoc/Demystifying_the_event_loop.adoc that talks about the different contexts, but to be frank I'm still a little fuzzy on the implications. 

[Thomas SEGISMONT]

Worker threads are useful if a part of your application is completely made of blocking calls.

For example, you may have a standard verticle with Vert.x Web for the front-end,  and worker verticle with Hibernate for the backend.

Having the backend logic encapsulated in a worker verticle and communicating over the event bus, you will be able to scale to other cluster nodes easily.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/b3810dae-aa4f-4123-8a0a-ababa2fc0231%40googlegroups.com.