9:08 a.m.
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
11:16 p.m.
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(a)gmail.com>
To: undertow-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
1:50 p.m.
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(a)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(a)gmail.com>
> To: undertow-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
5:25 p.m.
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(a)gmail.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>
Cc: undertow-dev(a)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(a)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(a)gmail.com>
> > To: undertow-dev(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
3353
days inactive
3495
days old
3 comments
2 participants
participants (2)
-
Chris Back -
Stuart Douglas