Jetty 9 ignoring my config XML - jetty

Question

I'm using Jetty-Runner in a project, and recently upgraded to Jetty 9. After migrating the XML with the new configuration, I noticed the following line in startup logs:
WARN:oejx.XmlConfiguration:main: Ignored arg: ...
The arg ignored being printed is pretty much my whole XML, which is:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Arg name="threadpool">
<New class="org.eclipse.jetty.util.thread.QueuedThreadPool">
<Arg name="maxThreads">200</Arg>
<Arg name="minThreads">50</Arg>
<Arg name="idleTimeout">1000</Arg>
<Arg name="queue">
<New class="java.util.concurrent.ArrayBlockingQueue">
<Arg type="int">6000</Arg>
</New>
</Arg>
<Set name="detailedDump">false</Set>
</New>
</Arg>
</Configure>
I've checked each arg name/type/setter with current Jetty Javadocs, but still can't understand what's wrong with this setup, to be ignored.
Could you please help?

Answer 1

Update: Feb 2018
Ignored arg: means you have an <Arg> that isn't being used for the constructor of the object referenced in <Configure> (or <New>). The most likely reason is you are attempting to change something that has already been set earlier.
If you are here because you want to change the ThreadPool, read on.
If you only want to configure the QueuedThreadPool, you have options.
The Recommended Choice: Using the jetty-home or jetty-distribution to start Jetty?
Configure the threading property values in your ${jetty.base} directory.
You can find them either in your ${jetty.base}/start.ini or ${jetty.base}/start.d/*.ini files.
Not using jetty-home or jetty-distribution, but still using the XML? Why? (really, we want to know!)
The XML <Get> approach is preferable to set the values on the existing threadpool instead.
Example (from Jetty 9.2.20, same as Jetty 9.4.8):
<Configure id="Server" class="org.eclipse.jetty.server.Server">
...
<Get name="ThreadPool">
<Set name="minThreads" type="int">10</Set>
<Set name="maxThreads" type="int">200</Set>
<Set name="idleTimeout" type="int">60000</Set>
<Set name="detailedDump">false</Set>
</Get>
If you want to change from QueuedThreadPool to something else, this is considered an extreme expert level option. You have to be aware of the impact this will have on your server.
When making changes for minimum / maximum threads be aware of the following:
The number of CPU cores you have. (this impacts minimum required threads)
The number of network interfaces you have. (this impacts minimum required threads)
The number of simultaneous connections you will have. (this impacts minimum required threads)
The number of simultaneous requests you will have. (this impacts minimum required threads)
The use of HTTP/2 will increase your threading requirements significantly.
The use of old-school Servlet blocking APIs will increase your threading requirements. (consider using the newer AsyncContext and Async I/O behaviors, and it will significantly drop your thread requirements)
Some minimum threading examples:
The following examples are for illustration purposes and do not represent a "recommended" set of values from the Jetty project.
The Jetty recommended values are the default values already present in Jetty.
On an Intel i7, with 1 network interface, serving an average web page, with resources (images, css, javascript, etc). You'll need (8 for cpu cores, 1 for network interface, 1 for the acceptor, 1 for the selector, and about 10 more to serve the webpage and its resources to a typical, modern day Chrome browser) about 22 minimum threads.
On an Raspberry Pi, with 1 network interface, serving REST requests to a single REST client in sequence (never parallel), you'll need 8 minimum threads.
More notes:
Also, Do not assume that 1 thread == 1 request / response exchange. That is not true on Jetty. A single request / response exchange can be handled by [1...n] threads over its lifetime. Only blocking reads/writes using the old school Servlet APIs will hold a thread (again, use the new Servlet API Async I/O operations)
If you are wanting to adjust the thread configurations under some assumption of reducing traffic/requests to something on Jetty, consider using QoSFilter (for controlling endpoint/resource specific behaviors) or DoSFilter (for controlling overall load limits) instead.
OLD ANSWER (From Dec 2013)
1) Fix your DTD
Yours:
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure.dtd">
The correct one for Jetty 9+
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure_9_0.dtd">
2) Use type attribute better
The type="int" is unsupported in that older version of Jetty, as "int" is not a valid object type. Use java.lang.Integer instead (or upgrade to a newer version of Jetty that supports "int")
Try this out instead.
<Arg name="threadpool">
<New id="threadpool" class="org.eclipse.jetty.util.thread.QueuedThreadPool">
<Arg type="java.lang.Integer" name="maxThreads">200</Arg>
<Arg type="java.lang.Integer" name="minThreads">50</Arg>
<Arg type="java.lang.Integer" name="idleTimeout">1000</Arg>
<Arg name="queue">
<New class="java.util.concurrent.ArrayBlockingQueue">
<Arg type="java.lang.Integer">6000</Arg>
</New>
</Arg>
<Set name="detailedDump">false</Set>
</New>
</Arg>
The above was verified with jetty-9.1.0.v20131115 distribution.