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
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@gmail.com>
> To: undertow-dev@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev