[undertow-dev] Async/Rx approach in HttpHandlers

[Bill O'Neil]

Is your goal to be async or non-blocking? If you want to be non-blocking
then every method and library you use must also be non-blocking then you
never need to dispatch to a separate worker pool and can stay on the IO
threads the entire time.

If you want it to be async then you can dispatch to worker threads to
handle the blocking operations. A sleep operation is blocking so yes it
will block a thread for its duration. That is also true with observables or
any of the reactive frameworks.

The defaults for the IO thread and worker thread can be found here
<https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/Undertow.java#L429>
.
IO threads = min (# of CPU cores, 2)
worker threads = IO threads * 8

On a 4 core server, you will have 32 worker threads for blocking
operations. You can configure both of these pools to meet your needs. If
you dispatch then sleep you will be blocking one of the 32 worker threads
but the IO thread is free to accept requests.

Any of the reactive frameworks or WebFlux type frameworks will handle this
in the same way unless the underlying libraries are non-blocking. Most JDBC
libraries (for now) are all blocking which means the only way to make it
async is to run the query in a separate thread blocking that thread until
the query returns.

On Tue, Feb 26, 2019 at 8:03 AM Carter Kozak <ckozak at ckozak.net> wrote:

> spring-webflux supports reactive types on undertow:
> https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html
>
> It may be helpful to read their undertow handler implementation, or to use
> spring-webflux directly.
>
> -ck
>
> On Feb 26, 2019, at 7:47 AM, Girish Sharma <scrapmachines at gmail.com>
> wrote:
>
> I read through the code and did some other reading too. But while
> exploring on stackoverflow and such, I came upon this [0] question.
> I am now assuming that since author here did not mention a separate
> thread-pool, the worker thread pool was used up for the the sleep statement
> as well and thus his concern?
> More interesting however is the reply where the person who replied claims
> undertow is not meant for such cases and mentions his fork undertow-async
> [1].
>
> Any thoughts around that?
>
> [0]
> https://stackoverflow.com/questions/47464828/undertown-async-responce-with-another-thread
> [1] https://github.com/hank-whu/undertow-async
>
> On Tue, Feb 26, 2019 at 5:50 PM Bill O'Neil <bill at dartalley.com> wrote:
>
>> Take a look at the various dispatch methods on HttpServerExchange. They
>> allow you to dispatch from the IO thread to the worker pool or to a custom
>> executor. BlockingHandler is a convenience handler for dispatching to the
>> worker thread pool.
>>
>> On Tue, Feb 26, 2019 at 5:13 AM Girish Sharma <scrapmachines at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have been trying to find some solid examples for using
>>> Observables/Callbacks/Futures to delegate long running tasks (which return
>>> the response to be sent back) over to separate threads. The idea is that
>>> the handler method simply spawns an async task and whenever that async
>>> tasks completes, we send back the response without making the handler
>>> method/worker threads wait for the async task to finish.
>>>
>>> Any pointers/examples would be appreciated.
>>> --
>>> Girish Sharma
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>
> --
> Girish Sharma
> B.Tech(H), Civil Engineering,
> Indian Institute of Technology, Kharagpur
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190226/75bc3ca9/attachment.html