Asynchronous Content Aggregation with Servlet 3.0

Jetty Continuations have been addressing the problem of blocking servlet threads for a while now and the concept is under review for inclusion into the servlet 3.0 spec (due out near the end of the year I believe). With jetty 7.0 under development now one of the big new additions will be the implementation of the servlet 3.0 spec, which is handily already sitting on the trunk of jetty.
One of the things I have been knocking around since I started with Webtide is how to use web services in the context of jetty continuations and I mocked up a bit of a demo showing how this would work a while back. I recently dusted it off and decided to see how it would look as an example on the jetty trunk using the new servlet 3.0 api. The previous jetty continuations implementation was pretty straight forward, but taking this non-blocking servlet concept for a spin on jetty trunk was just so simple!
The basic problem I was looking at was performance considerations with content aggregation for a web service. I decided to use the Ebay Shopping Services api along with the Apache CXF project for web service client generation. Then I made a couple of servlets that wrapped up multiple calls to web services. The first servlet grabs a list of search terms off of the url being passed in and executes the find items search through the ebay shopping services api serially in traditional servlet manner, effectively consuming a servlet thread during the entire search time. Each request took over 900ms on the coffee shop connection I was using to test, so for 10 terms that was roughly 10000ms.
The second servlet I made used the asynchronous client cxf generated and the servlet 3.0 suspend()/resume() mechanism. It takes in the same list of search terms and makes the asynchronous calls and then suspends the servlet thread. This frees up the servlet thread of which there is generally a finite number of, just like the jetty continuation would and when the web service requests are done calls the resume() method on the request object (this is found in EbayFindItemAsync) which replays the servlet request, only this time with all of the results complete and available.
So what does this mean? Well, the serial servlet would scale pretty much linearly for each additional search term added to the requesting url, adding 900ms each term, continuing to consume that servlet thread. Even if you implemented the async servlet using previous servlet spec versions you would be consuming that servlet thread for the entire time the calls were pending. However in the case here, your servlet thread is only consumed for the time it takes to process the search terms and make the asynchronous calls.
It is a neat little demo, if you want to take a look it is located on the jetty trunk under the modules/examples/test-ws-cxf directory.
Update:  There is now a cool little index.html page for the webapp test that gives a much better breakdown of the specific timing involved between the synchronous and asynchronous servlets and the results are pretty dramatic for just one request in terms of servlet thread time.  Also updated with resume() additions.
Also updated with screenshot: