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

[Andrew Brampton]

Thanks all, my mind is blown that the async file IO is actually using
threads under the hood. I just spent a little while reading through the
SimpleAsynchronousFileChannelImpl source code, as well as reading up on
Linux's AIO.

Thanks
Andrew


On 25 November 2015 at 13:50, Jason Greene <jason.greene at redhat.com> wrote:

>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151125/a7b93eb9/attachment.html