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:

Asynchronous Content Aggregation with Servlet 3.0

2 thoughts on “Asynchronous Content Aggregation with Servlet 3.0

  • December 19, 2009 at 12:29 pm

    If you have been following the latest in Servlet technology, you would know that the expert group has finally decided to try to standardize asynchronous servlet support for Servlet 3.0. This came as somewhat of a surprise because I had already been working with my colleague Erinn Koonce on a related feature for WAS version 7 called the Asynchronous Request Dispatcher.

    • April 8, 2012 at 10:41 am

      Hi Jan, agree, support jsp is a tiltle more difficulty. I got one way to develop web application for i-jetty on android by using Developer uses eclipse + maven + jetty-maven-plugin to develop web application and servlet. They need make sure the dependence on jetty6.1.9. all the servlet will be compiled into a jar file, use dex tool convert the jar file to dex, then zip it as a jar. we can even make the process automatic. when make package for web application, put the above servlet jar into webapps’s lib dir. After package, we get a WAR file. This file can be installed to android internal web server webapps dir. During xmlConfiguration configure the web application, I add a class name MyClassLoader to load those servlet.MyClassLoader is derived from URLClassLoader and it uses dexFile to open the jar, use WabAppClassLoader as parent classloader.RegardsHuadong

Comments are closed.