[undertow-dev] Mostly IO, non-blocking workload best practice

[Stuart Douglas]

This does look correct. WRT question b) the only way this should be able to happen is if you are using HTTP pipelining combined with blocking IO (i.e. you have dispatched to the worker further down the chain). 

If this happens the root handler of the next request may start in a worker thread rather than an IO thread (this is an optimization designed to prevent a possible double dispatch back to the IO then back to the worker). In practice it does not matter, it is still perfectly fine to perform non-blocking IO from a worker threads. It seems odd that you would run into this though.

Also you asked about dispatching back to the IO thread, this is possible, you can just call dispatch and pass in the IOThread as your executor.

Stuart

----- Original Message -----
> From: "Chris Back" <chris.back at gmail.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Thursday, 17 September, 2015 4:50:30 AM
> Subject: Re: [undertow-dev] Mostly IO, non-blocking workload best practice
> 
> I have included an example of the code I built to make sure all request
> data has been read before passing on to my next handler. It is included in
> the two attached files.
> 
> My questions are :
> a) Does it look correct? Things seem to be working in practice, but I'd
> like confirmation from people more experienced with undertow.
> b) I am occasionally seeing requests that start in a non-io thread (i.e. if
> I call isInIoThread() as the first call of my root HttpHandler it returns
> false. Should that be possible?
> 
> Thanks,
> Chris
> 
> On Tue, Apr 28, 2015 at 9:16 PM Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> > The non blocking API for reading data is actually something we are looking
> > at improving in the next version of Undertow.
> >
> > For now you need to use the XNIO request channel. For an example of how to
> > use this look at io.undertow.util.StringReadChannelListener (you can
> > actually just subclass this class).
> >
> > Basically the most efficient way to use the API is:
> >
> > - Get a pooled buffer from the connections buffer pool
> > - keep calling StreamSinkChannel.read() to read the data
> > - If read returns 0 register a read listener and then call resumeReads()
> > and return. Your listener will be notified when more data is available.
> > - When read returns -1 you are done
> >
> > Stuart
> >
> > ----- Original Message -----
> > > From: "Chris Back" <chris.back at gmail.com>
> > > To: undertow-dev at lists.jboss.org
> > > Sent: Wednesday, 29 April, 2015 12:08:09 AM
> > > Subject: [undertow-dev] Mostly IO, non-blocking workload best practice
> > >
> > > I am writing a server that will need to respond to lots of small web
> > > requests. Most of the requests will come with a small POST payload.
> > Based on
> > > the contents of the payload, the server will either a) respond
> > immediately,
> > > or b) forward the request as is to one of a pool of backend servers,
> > waiting
> > > for a response and forwarding the response back to the client.
> > >
> > > It looks like given the existing undertow code, I have good examples of
> > how
> > > to forward requests to the backend. What isn't as clear is how to handle
> > the
> > > getting the POST data. Is there a way of doing that without blocking?
> > >
> > > Ideally, my handler flow would be:
> > >
> > > 1. Non-blocking request handler that makes sure all POST data is in.
> > > 2. A non-blocking handler that decisions based on content of POST data to
> > > 3a. Immediately return a response to the client (non-blocking).
> > > or
> > > 3b. Dispatch to the worker pool to forward request to backend server and
> > > await response.
> > >
> > > 90% of my requests will go through path 3a, and I'd like that to be as
> > quick
> > > as possible. When the server decides a request should go through 3b, only
> > > then should it go to the blocking worker pool.
> > >
> > > Am I viewing this correctly? What are my options? Based on this thread
> > > http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html
> > > it seems like an option could be to get the request channel in step 1
> > above?
> > > Its not clear to me how that would work.
> > >
> > > Thanks,
> > > Chris
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
>