[undertow-dev] Worker thread queue size and timeout behavior

Brad Wood bdw429s at gmail.com
Thu Feb 22 10:38:02 EST 2018


Thanks guys.  I seem to have gotten a couple conflicting replies :)

>  it defaults to a queue size of 1000

>  It is unbounded

What exactly is the 1000 backlog setting doing?


Thanks!

~Brad

*Developer Advocate*
*Ortus Solutions, Corp *

E-mail: brad at coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com


On Thu, Feb 22, 2018 at 4:32 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

>
>
> On Thu, Feb 22, 2018 at 4:04 PM, Brad Wood <bdw429s at gmail.com> wrote:
>
>> I'm looking for a bit of understanding on just how Undertow handles large
>> numbers of requests coming into a server.  Specifically when more requests
>> are being sent in than are being completed.  I've been doing some load
>> testing on a CFML app (Lucee Server) where I happen to have my io-threads
>> set to 4 and my worker-threads set to 150.  I'm using a monitoring tool
>> (FusionReactor) that shows me the number of currently executing threads at
>> my app and under heavy load I see exact 150 running HTTP threads in my app
>> server, which makes sense since I have 150 worker threads.  I'm assuming
>> here that I can't simultaneously process more requests than I have worker
>> threads (please correct if I'm off there)
>>
>> So assuming I'm thinking that through correctly, what happens to
>> additional requests that are coming into the server at that point?  I
>> assume they are being queued somewhere, but
>>
>>    - What is this queue?
>>
>> The queue is in the XNIO worker (although if you want you could just use
> a different executor which has its own queue).
>
>
>>
>>    - How do I monitor it?
>>
>> XNIO binds an MBean that you can use to inspect the worker queue size.
>
>
>>
>>    - How big can it get?
>>
>> It is unbounded, as rejecting tasks from the worker is very problematic
> in some circumstances. If you want to limit the number of concurrent
> requests use the io.undertow.server.handlers.RequestLimitingHandler
>
>
>>
>>    - Where do I change the size?
>>    - How long do things stay in there before sending back an error to
>>    the HTTP client?
>>
>> If you use the RequestLimitingHandler this is configurable. It has its
> own queue with a fixed size, and a configurable timeout.
>
>
>>
>>    - Can I control what error comes back to the HTTP client in that
>>    scenario?
>>
>> You can using io.undertow.server.handlers.RequestLimit#setFailureHandler
>
>
>>
>>    - If I'm using an HTTP/S and AJP listener, do they all share the same
>>    settings?  Do they share the same queues?
>>
>> In general yes. You could give each listener its own limiting handler
> with its own queue if you wanted by explicitly setting the listeners root
> handler, however in general they will all just use the same handler chain.
>
> Stuart
>
>
>> I've done a bit of Googling and reviewed some docs but haven't quite
>> found any definitive information on this, and a lot of info I found was
>> about Wildfly specifically so I wasn't sure how much of it applied.
>>
>> Thanks!
>>
>> ~Brad
>>
>> *Developer Advocate*
>> *Ortus Solutions, Corp *
>>
>> E-mail: brad at coldbox.org
>> ColdBox Platform: http://www.coldbox.org
>> Blog: http://www.codersrevolution.com
>>
>>
>> _______________________________________________
>> 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/20180222/74f399f4/attachment.html 


More information about the undertow-dev mailing list