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

[Chris Back]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/28c17550/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReadCompleteHandler.java
Type: application/octet-stream
Size: 1938 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/28c17550/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DataReadListener.java
Type: application/octet-stream
Size: 2292 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20150916/28c17550/attachment-0001.obj