HTTP client connecting to Jetty during its startup hangs

This is a pure Jetty issue.

The user is facing a problem in their OSGi application during its startup. If they try to connect to it through a webService while it is booting up, the connection sometimes "freezes" indefinitely.

From time to time they observe that an HTTP client connecting to Jetty during its startup just "hangs": the TCP connection is accepted, the client sends the HTTP request but then no data gets back.
The TCP connection remains open forever, but no handler is invoked on the server side.

The attached JettyTest reproduces this behaviour, the test dos the following:

Jetty is not started;
10 client threads continuously try to HTTP GET some dummy URL on Jetty;
The clients are getting "cannot connect" errors, which are ignored;
Jetty gets started;
Each client will start receiving 404's (no handler is configured on Jetty);
We wait for 100 404's from each single client thread;
Once we get them, we stop Jetty and we reset the counters;
Loop.
If the wait for the 10x100 404's takes more than 10 seconds, we dump on screen the counter of each thread that did not reach 100 yet.

The typical "cruise" output:

2012-07-31 16:01:38.091:INFO:oejs.Server:jetty-7.5.4.v20111024
2012-07-31 16:01:38.121:INFO:oejs.AbstractConnector:Started SelectChannelConnector@localhost:50001 STARTING
2012-07-31 16:01:39.450:INFO:oejs.Server:Graceful shutdown SelectChannelConnector@localhost:50001 STARTED
2012-07-31 16:01:40.548:INFO:oejs.Server:jetty-7.5.4.v20111024
2012-07-31 16:01:40.548:INFO:oejs.AbstractConnector:Started SelectChannelConnector@localhost:50002 STARTING
2012-07-31 16:01:41.253:INFO:oejs.Server:Graceful shutdown SelectChannelConnector@localhost:50002 STARTED
2012-07-31 16:01:42.335:INFO:oejs.Server:jetty-7.5.4.v20111024
2012-07-31 16:01:42.345:INFO:oejs.AbstractConnector:Started SelectChannelConnector@localhost:50003 STARTING
2012-07-31 16:01:42.346:WARN:oejs.AbstractConnector:
At some point of time one or more client threads will get stuck and will display something like:

XXX 2: 0
XXX 2: 0
XXX 2: 0
Which means that client 2 took more than 10 second to get its 100 404's, and the current counter is 0. Note that from that point the client 2 remains stuck "forever".

Please see the linked DEV-4352 for further info.