This thread starvation situation can also occur if the database runs slowly or is momentarily unavailable. Thread starvation is a very frequently reported problem, that causes an entire web service to lock up and become unresponsive!
If the web container was able to threadlessly suspend the requests waiting for a JDBC connection, then thread starvation would not occur, as only 30 threads would be consumed by requests accessing the database and the other 470 threads would be available to process the request that do not access the database.
For an example of Jetty's solution, see the Quality of Service Filter.
Remote Web Service
Consider a web application that accesses a remote web service (eg SOAP service or RESTful service). Typically a remote web service can take hundreds of milliseconds to produce a response (eg ebays RESTful web service frequently takes 350ms to respond with a list of auctions matching a given keyword), while only a few 10s of milliseconds of CPU time are needed to locally process a request and generate a response.
If the web container was able to threadlessly suspend the request while waiting for the web service response, then even if 5ms of additional processing was required, the web app would need only 400*(20+5)/1000 = 10 threads on average and would not be vulnerable to thread starvation during bursts or if the web service is slow or unavailable. Moreover, the reduction of in the number of threads required would free up over 70MB of memory (unused stacks) that could be used for the application.
For an example of Jetty's solution, see the Asynchronous Rest example.
Ajax Comet Portfolio application
If the web container was able to threadlessly suspend the request while waiting for the price change, then even if 10ms of additional processing was required,
then only 49.4*(20+10)/1000= 2 threads are needed! This can free up almost 250MB of stack memory for other use by the web application!
For an example of Jetty's solution, see the Cometd (aka Bayeux).