Blog

Jesse Mcconnell (of maven background) has joined Webtide.  Jesse has been with us for several months now and we are really please to have his experience and skills being applied to the Jetty project and for Webtide clients.

Jesse has started a blog, and his first technical entry is a cracker! He’s used the proposed async servlet 3.0 API to implement an asynchronous web services demonstration. This demonstration clearly shows the huge gains that are possible with an asynchronous approach

Welcome aboard Jesse!

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:

A few months back I was given a chance to come work at Webtide and jumped at the chance.  Really, given the chance to work with amazing people like the founders of Jetty who could say no to something like that? 

Jetty has been a component in my development stack for such a long time, since the early days of jboss when jetty was packaged with it, the name has been circling around my periphery.  It’s also been a critical part of my maven life since the jetty-maven-plugin is just such a wonderful tool for  working with webapps in maven.  I have always been a big command line guy so anything that aids me in keeping the IDE for just editing code and out of esoteric ui plugins and weird editor behavior is a huge bonus in my book.  And now I get to work professionally with the people behind so many good things.  The jetty continuations setup with long polling and how it speeds up ajax traffic coupled with the workaround of servlet shortcomings is just stellar.  I have even been able to work with early servlet 3.0 apis which I’ll blog about next….

So ya, what a great group of people to work with…just awesome.  Akin to the awesome group of people I worked with at Mergere and later Devzuz (you know who you are!)

A patch is now available for the development version of Jetty that introduces some of the proposed features for Servlet 3.0.  Key among these is a suspend/resume API on the request object that is a proposed standardization the Jetty Continuation mechanism for asynchronous servlets.

The patch is against the 6.2-SNAPSHOT version in svn head.  The following commands will checkout jetty, apply the patch and build the server:

svn co https://svn.codehaus.org/jetty/jetty/trunk jetty-6.2
cd jetty-6.2
patch -p0 < patches/servlet-3.0.patch
mvn clean install

The patch updates the cometd bayeux implementations to use the new API in the SuspendingCometdServlet class.   Jetty’s continuations have also been converted to a facade that calls the new ServletRequest.suspend() API.

Testing and feedback are most welcome!

Johannes Brodwall is kind enough to highlight his commercial experience in switching to Jetty. His only regret?… not doing it sooner. Link to his experience

Please drop us a note if we can help you with advice, support, or custom development to go down this path with the experts backing you.

Roberto Chinnici has posted a blog entry discussing the idea of introducing “profiles” in the JavaEE 6 specification(aka JSR-316).
Essentially, a profile is a subset of the enormous number of APIs/specs etc that a JavaEE platform supports. Over time, EE platforms have grown in complexity and size, leading to very large downloads and very large runtimes. Of course, if your app happens to use 99% of those APIs, you’re a happy camper (although IMHO your app could probably benefit from a long, hard think about it’s architecture 🙂 ). For very many – dare I even say the majority – of cases, the full EE environment just isn’t needed. In recognition of this, most of the well known application servers have released “lite” versions of themselves (although the success of the diet has to be measured in terms relative to the starting size and not the absolute outcome).
So that’s the motivation for the JSR’s consideration of  “profiles” – they’re a way of  slimming down the EE environment. A profile defines a minimum feature-set for a compliant product to implement, although a product could also choose to offer additional features, apparently with the provisio that a TCK must exist for those features.
The first profile they will be tackling is the Web Profile. Roberto lists 2 options under discussion:
Option A

• Servlet 3.0
• JSP 2.2
• JSR-45
• EL 1.2
• JSTL 1.2
• JSR-250

Option B

• Servlet 3.0
• JSP 2.2
• JSR-45
• EL 1.2
• JSTL 1.2
• JSR-250
• EJB 3.1 (Lite)
• JTA 1.1
• JPA 2.0
• JSF 2.0 *
• Web Beans 1.0

Whilst being the least heavy of the two, I actually think that Option A still has some dieting to do! The days are long past where one server-side presentation technology should be annointed as an essential part of a web container. These days many dynamic, slick web user interfaces are being created without the use of JSPs at all. Just have a trawl through the technologies listed on http://www.ajaxian.com to get some idea of the variety that is out there. By all means let Web Profile compliant containers provide JSP support as an optional extra. This would permit a migration path for existing web apps. However,  to mandate its inclusion at this point would be to look backwards in time rather than forwards into the future.
Option B, even minus all the JSP-related and derived technologies is still too heavy. I guess when you come right down to it, I think you can get a long way if your web container simply supports the ability to plug in extra services via JNDI. Want to use EJB3? Select one of the implementations available, throw it into the container’s classpath and hookup what’s necessary into JNDI and away you go. Want to use JPA? Throw an implementation library into the container’s classpath, hookup JNDI and again, you’re good to go. Not satisfied with your initial choice of JPA impl? Take it out and replace it with another.
In short, I’m not really sure that profiles are the answer. Is it really feasible to select a set of APIs and expect that one-size will fit all?  I think what we really need is the ability to run a web container and a mix of API implementations according to our needs, and I think to a large extent a web container + JNDI already provides this.
My experience with Jetty is that by using JettyPlus (which is essentially Jetty plus JNDI), you can plug in all manner of tools that let you get the job done. If you can’t be bothered to work out which implementations of the tools you want to use, then you can use something like Hightide, which is JettyPlus with a bunch of tools pre-plugged in. If you don’t like them, then you’re free to swap them for others.

I’ve modified the application is bundled into  Jetty  on adroid so that instead of a simple "Hello World" message,  you can now use the phone’s browser to look at content stored on the phone itself.

Here’s a few screen shots to give you the idea.

Starting Jetty:

The menu options to control jetty.

Jetty from the Home screen:

Notice the little jetty icon to the top left. You can click on that in any screen and drag it down to access the jetty menu.

Surfing to http://localhost:8080:

Clicking on the System option:

I’ve recently been working on porting Jetty to Google’s mobile platform called Android.
It’s early days still, but I’ve succeeded in running a minimal setup with a connector (I’ve tested both bio and nio connectors) and a simple Handler. If you’d like to take a look, then check out the code from the i-jetty project and build it (you’ll need to execute the ant build script and then use Android’s packaging tool or the Eclipse plugin).
Once you’ve built and deployed the i-jetty package to the emulator,  find the “Manage Jetty” application, and select the “Start Jetty” button. Then you’ll be able to select the Browser application and surf to http://127.0.0.1:8080 and hit the demo “Hello” Handler.
For the moment I’ve had to do a teeny hack to the servlet api classes, due to this bug in Android, but hopefully that will be fixed soon and I can revert the temporary patches.
Much work remains to be done, but I thought I’d give everyone early warning that this work was going on. Who knows, it might inspire someone to use Jetty to win the Android developer challenge?!

Based on Greg’s earlier benchmarking on Amazon EC2 nodes. Good stuff! It is great to demonstrate that open approaches can yield the best performance.

InfoQ Link