> Connections are a primary resource that Jetty manages
> and it is jetty's responsibility to make sure that these are not exhausted.
The number of active application threads is limited. Nobody prevents you from using a short timeout after the server thread is no longer active.
Apache have a hard-coded limit of 250 running processes, that is not so with Jetty+NIO - no point in fighting for connections there, while all other resources (including HttpServletResponse and other Jetty structures) are still held by an application thread still running.
> An idle timeout is a standard way of controlling these resources
> and I think you will find that almost all servers will timeout idle connections.
Please, see the "disableUploadTimeout" flag (http://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html): "This flag allows the servlet container to use a different, longer connection timeout while a servlet is being executed, which in the end allows either the servlet a longer amount of time to complete its execution, or a longer timeout during data upload. If not specified, this attribute is set to "false"."
Please, see http://ru.php.net/manual/en/features.connection-handling.php
As you can see, most servers implement what i propose: in Tomcat you can ignore timeouts while the thread is still active; in Apache+mod_php you can manually set the timeouts for the current connection, so you can easily disable timeouts during activity and re-anable when done.
> Jetty starts these threads and should be able to stop them when it needs to.
Not when the thread is lent to an application.
Stopping buggy infinite cycle threads might be a viable option, but it must be an option. JVM thread can't intercept or block the Thread#interrupt, unlike the CGI application, which can block or intercept signals. Stopping user application thread without any option to prevent it may lead to unprecedented problems in the application, like loosing all data or blowing a space station. The difference between short-running application and a long-running one is not as obvious as it seems, for example, a typical operation, like deleting a folder, can run in milliseconds for a small folder and hours for a big folder, so "implement long operations separately" is not a practical answer.
> Note that if you only were to interrupt code that was your own, then you would never
> be able to call third party software, as you would be unaware if it can handle interrupts or not.
BDB JE behaviour considering Thread#interrupt is well docummented and is a part of its contract. I don't see how i "would be unaware if it can handle interrupts".