From: "Andrew Brampton" <me(a)bramp.net&gt; To: undertow-dev(a)lists.jboss.org Sent: Wednesday, 25 November, 2015 4:13:03 PM Subject: [undertow-dev] Undertow and non-blocking File IO I just started playing with Undertow, but I had a couple of questions about the use of non-blocking operations vs using the worker thread pool. In the ResourceHandler.java it appears to dispatch itself onto a worker thread, and then uses blocking file IO to actually read the file. I'm curious why a AsynchronousFileChannel wasn't used to read from the file in a non-blocking way? This would be in keeping with the non-blocking IO threads.

I wrote a quick HttpHandler that used the AsynchronousFileChannel and it worked really well. However, when creating AsynchronousFileChannel you have to specify the ExecutorService to be used to schedule the completion handler callback on. I was able to use exchange.getIoThread().getWorker(), but I'm curious if there is a way to schedule it back on the IO Threads? It just seems "purer" keeping everything on a single IO thread per core.

thanks Andrew _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

> On Nov 25, 2015, at 3:27 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: > > > > ----- Original Message ----- >> From: "Andrew Brampton" <me(a)bramp.net&gt; >> To: undertow-dev(a)lists.jboss.org >> Sent: Wednesday, 25 November, 2015 4:13:03 PM >> Subject: [undertow-dev] Undertow and non-blocking File IO >> >> I just started playing with Undertow, but I had a couple of questions about >> the use of non-blocking operations vs using the worker thread pool. >> >> In the ResourceHandler.java it appears to dispatch itself onto a worker >> thread, and then uses blocking file IO to actually read the file. I'm >> curious why a AsynchronousFileChannel wasn't used to read from the file in a >> non-blocking way? This would be in keeping with the non-blocking IO threads. > > This is something we should look at, however this only has an actual benefit on Windows AFAIK. Other platforms use SimpleAsynchronousFileChannelImpl which simply delegates to a thread pool. The major issue that prevents this is that Linux filesystems (in combination with the kernel) can sometimes block in io_submit (e.g. during certain metadata operations). You also have to open a file aligned and in O_DIRECT which Java NIO does not support. If you look at what the glibc impl does, it actually ends up creating a thread pool of its own. > >> >> I wrote a quick HttpHandler that used the AsynchronousFileChannel and it >> worked really well. However, when creating AsynchronousFileChannel you have >> to specify the ExecutorService to be used to schedule the completion handler >> callback on. I was able to use exchange.getIoThread().getWorker(), but I'm >> curious if there is a way to schedule it back on the IO Threads? It just >> seems "purer" keeping everything on a single IO thread per core. > > The IO threads implement Executor not ExecutorService, you could write a wrapper, but if you used it on non Windows platforms you would block the IO thread. > > Stuart > >> >> thanks >> Andrew >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat