[undertow-dev] Undertow and non-blocking File IO

Jason Greene jason.greene at redhat.com
Wed Nov 25 16:50:58 EST 2015


> On Nov 25, 2015, at 3:27 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Andrew Brampton" <me at bramp.net>
>> To: undertow-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at 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




More information about the undertow-dev mailing list