<div dir="ltr">Awesome, thx. I'm not using Undertow in Wildfly, but rather another product called Runwar that we bundle in the CommandBox CLI for running Java wars- primarily CFML engines. I'm actually thinking about bugging a couple of the APM vendors for CF apps to see if they'll tap into this in their serve monitors for apps running on Undertow/CommandBox.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div></div><div>Thanks!</div><div><br></div><div>~Brad</div><div><br></div><div><b>Developer Advocate</b></div><div><i>Ortus Solutions, Corp </i></div><div><b><br></b></div><div>E-mail: <a href="mailto:brad@coldbox.org" target="_blank">brad@coldbox.org</a></div><div>ColdBox Platform: <a href="http://www.coldbox.org" target="_blank">http://www.coldbox.org</a> </div><div>Blog: <a href="http://www.codersrevolution.com" target="_blank">http://www.codersrevolution.com</a></div><div><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Feb 22, 2018 at 2:17 PM, Masafumi Miura <span dir="ltr"><<a href="mailto:masafumi0920@gmail.com" target="_blank">masafumi0920@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You can use jconsole to check org.xnio MBean. (By the way, if you use WildFly 11, you can also check the same metrics under io subsystem through JBoss CLI.)<br><br>If you use Undertow with XNIO 3.4.3 or later, you can also obtain XnioWorkerMXBean from XnioWorker through Undertow API. For example:<br><br> - From io.undertow.server.<wbr>HttpServerExchange: exchange.getConnection().<wbr>getWorker().getMXBean()<br> - From io.undertow.Undertow: undertow.getWorker().<wbr>getMXBean()<br><br>Then, you can access the following metrics from the MXBean:<br><br> - getBusyWorkerThreadCount() = current busy worker thread count<br> - getWorkerQueueSize() = current queue size of worker thread pool<br> - getCoreWorkerPoolSize() = core worker thread pool size which you configured<br> - getMaxWorkerPoolSize() = max worker thread pool size which you configured<br> - getIoThreadCount() = io thread pool size which you configured<br><br>Though the latest undertow pom.xml specifies XNIO 3.3.8.Final as a dependency, I believe it's compatible and it works with newer versions of XNIO. (Actually, WildFly 11 comes with Undertow 1.4.18.Final and XNIO 3.5.4.Final.)<br><br>Thanks,<br>Masafumi<div><div class="h5"><br><br>On Fri, Feb 23, 2018 at 1:03 AM, Brad Wood <<a href="mailto:bdw429s@gmail.com" target="_blank">bdw429s@gmail.com</a>> wrote:<br>> Perfect. Thanks everyone! One final question-- how do I get the MBean to<br>> monitor the queued requests? A tutorial link would be fine.<br>><br>> Thanks!<br>><br>> ~Brad<br>><br>> Developer Advocate<br>> Ortus Solutions, Corp<br>><br>> E-mail: <a href="mailto:brad@coldbox.org" target="_blank">brad@coldbox.org</a><br>> ColdBox Platform: <a href="http://www.coldbox.org" target="_blank">http://www.coldbox.org</a><br>> Blog: <a href="http://www.codersrevolution.com" target="_blank">http://www.codersrevolution.<wbr>com</a><br>><br>><br>> On Thu, Feb 22, 2018 at 9:54 AM, Jason Greene <<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>><br>> wrote:<br>>><br>>> Thats the TCP backlog queue, which is only for connections that are being<br>>> initially established. Once the connection is accepted (which happens pretty<br>>> quickly since undertows I/o handling is non-blocking) then the queue entry<br>>> is removed. Worker size does not affect undertows ability to handle incoming<br>>> connections.<br>>><br>>> The reason applications set limit is just a safeguard against some types<br>>> of flood/dos.<br>>><br>>><br>>> On Feb 22, 2018, at 9:38 AM, Brad Wood <<a href="mailto:bdw429s@gmail.com" target="_blank">bdw429s@gmail.com</a>> wrote:<br>>><br>>> Thanks guys. I seem to have gotten a couple conflicting replies :)<br>>><br>>> > it defaults to a queue size of 1000<br>>><br>>> > It is unbounded<br>>><br>>> What exactly is the 1000 backlog setting doing?<br>>><br>>><br>>> Thanks!<br>>><br>>> ~Brad<br>>><br>>> Developer Advocate<br>>> Ortus Solutions, Corp<br>>><br>>> E-mail: <a href="mailto:brad@coldbox.org" target="_blank">brad@coldbox.org</a><br>>> ColdBox Platform: <a href="http://www.coldbox.org" target="_blank">http://www.coldbox.org</a><br>>> Blog: <a href="http://www.codersrevolution.com" target="_blank">http://www.codersrevolution.<wbr>com</a><br>>><br>>><br>>> On Thu, Feb 22, 2018 at 4:32 AM, Stuart Douglas <<a href="mailto:sdouglas@redhat.com" target="_blank">sdouglas@redhat.com</a>><br>>> wrote:<br>>>><br>>>><br>>>><br>>>> On Thu, Feb 22, 2018 at 4:04 PM, Brad Wood <<a href="mailto:bdw429s@gmail.com" target="_blank">bdw429s@gmail.com</a>> wrote:<br>>>>><br>>>>> I'm looking for a bit of understanding on just how Undertow handles<br>>>>> large numbers of requests coming into a server. Specifically when more<br>>>>> requests are being sent in than are being completed. I've been doing some<br>>>>> load testing on a CFML app (Lucee Server) where I happen to have my<br>>>>> io-threads set to 4 and my worker-threads set to 150. I'm using a<br>>>>> monitoring tool (FusionReactor) that shows me the number of currently<br>>>>> executing threads at my app and under heavy load I see exact 150 running<br>>>>> HTTP threads in my app server, which makes sense since I have 150 worker<br>>>>> threads. I'm assuming here that I can't simultaneously process more<br>>>>> requests than I have worker threads (please correct if I'm off there) <br>>>>><br>>>>> So assuming I'm thinking that through correctly, what happens to<br>>>>> additional requests that are coming into the server at that point? I assume<br>>>>> they are being queued somewhere, but<br>>>>><br>>>>> What is this queue?<br>>>><br>>>> The queue is in the XNIO worker (although if you want you could just use<br>>>> a different executor which has its own queue).<br>>>> <br>>>>><br>>>>> How do I monitor it?<br>>>><br>>>> XNIO binds an MBean that you can use to inspect the worker queue size.<br>>>> <br>>>>><br>>>>> How big can it get?<br>>>><br>>>> It is unbounded, as rejecting tasks from the worker is very problematic<br>>>> in some circumstances. If you want to limit the number of concurrent<br>>>> requests use the io.undertow.server.handlers.<wbr>RequestLimitingHandler<br>>>> <br>>>>><br>>>>> Where do I change the size?<br>>>>> How long do things stay in there before sending back an error to the<br>>>>> HTTP client?<br>>>><br>>>> If you use the RequestLimitingHandler this is configurable. It has its<br>>>> own queue with a fixed size, and a configurable timeout.<br>>>> <br>>>>><br>>>>> Can I control what error comes back to the HTTP client in that scenario?<br>>>><br>>>> You can using io.undertow.server.handlers.<wbr>RequestLimit#setFailureHandler<br>>>> <br>>>>><br>>>>> If I'm using an HTTP/S and AJP listener, do they all share the same<br>>>>> settings? Do they share the same queues?<br>>>><br>>>> In general yes. You could give each listener its own limiting handler<br>>>> with its own queue if you wanted by explicitly setting the listeners root<br>>>> handler, however in general they will all just use the same handler chain.<br>>>><br>>>> Stuart<br>>>> <br>>>>><br>>>>> I've done a bit of Googling and reviewed some docs but haven't quite<br>>>>> found any definitive information on this, and a lot of info I found was<br>>>>> about Wildfly specifically so I wasn't sure how much of it applied. <br>>>>><br>>>>> Thanks!<br>>>>><br>>>>> ~Brad<br>>>>><br>>>>> Developer Advocate<br>>>>> Ortus Solutions, Corp<br>>>>><br>>>>> E-mail: <a href="mailto:brad@coldbox.org" target="_blank">brad@coldbox.org</a><br>>>>> ColdBox Platform: <a href="http://www.coldbox.org" target="_blank">http://www.coldbox.org</a><br>>>>> Blog: <a href="http://www.codersrevolution.com" target="_blank">http://www.codersrevolution.<wbr>com</a><br>>>>><br>>>>><br>>>>> ______________________________<wbr>_________________<br>>>>> undertow-dev mailing list<br>>>>> <a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a><br>>>>> <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/undertow-dev</a><br>>>><br>>>><br>>><br>>> ______________________________<wbr>_________________<br>>> undertow-dev mailing list<br>>> <a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a><br>>> <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/undertow-dev</a><br>><br>><br>><br>> ______________________________<wbr>_________________<br>> undertow-dev mailing list<br>> <a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/undertow-dev</a></div></div></div>
</blockquote></div><br></div>