<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>The defaults for the IO thread and worker thread can be found <a href="https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/Undertow.java#L429">here</a>.</div><div>IO threads = min (# of CPU cores, 2)</div><div>worker threads = IO threads * 8</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 8:03 AM Carter Kozak <<a href="mailto:ckozak@ckozak.net">ckozak@ckozak.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">spring-webflux supports reactive types on undertow: <a href="https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html" target="_blank">https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html</a><div><br></div><div>It may be helpful to read their undertow handler implementation, or to use spring-webflux directly.</div><div><br><div id="gmail-m_-5702486531213647835AppleMailSignature" dir="ltr">-ck</div><div dir="ltr"><br>On Feb 26, 2019, at 7:47 AM, Girish Sharma <<a href="mailto:scrapmachines@gmail.com" target="_blank">scrapmachines@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I read through the code and did some other reading too. But while exploring on stackoverflow and such, I came upon this [0] question.</div><div>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?</div><div>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].</div><div><br></div><div>Any thoughts around that?<br></div><div><br></div><div>[0] <a href="https://stackoverflow.com/questions/47464828/undertown-async-responce-with-another-thread" target="_blank">https://stackoverflow.com/questions/47464828/undertown-async-responce-with-another-thread</a><br></div><div>[1] <a href="https://github.com/hank-whu/undertow-async" target="_blank">https://github.com/hank-whu/undertow-async</a><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 5:50 PM Bill O'Neil <<a href="mailto:bill@dartalley.com" target="_blank">bill@dartalley.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 5:13 AM Girish Sharma <<a href="mailto:scrapmachines@gmail.com" target="_blank">scrapmachines@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>Any pointers/examples would be appreciated.<br>-- <br><div dir="ltr" class="gmail-m_-5702486531213647835gmail-m_853758682159103161gmail-m_-2557788302471488105gmail_signature"><span>Girish Sharma</span><br></div></div></div>
_______________________________________________<br>
undertow-dev mailing list<br>
<a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a></blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-5702486531213647835gmail_signature"><span>Girish Sharma<br>B.Tech(H), </span><span>Civil Engineering</span><span>,</span><div><span>Indian Institute of Technology, Kharagpur</span></div>
</div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>undertow-dev mailing list</span><br><span><a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a></span></div></blockquote></div></div></blockquote></div>