Osvaldo Pinali Doederlein's Blog

Tomcat goes Native

Check Tomcat 5.5.12 or later. When you install these new builds, the installer (at least on Windows) offers to download a native code library that Tomcat will use to optimize some performance-critical tasks like connection handling, file I/O and SSL encryption. This feature is documented here. It looks really cool because it relies on the APR -- Apache Portable Runtime, parte of the Apache HTTP server -- and OpenSSL. Both are very robust, secure and efficient pieces of native code. And of course, these components are also open source, and very multiplatform (I guess that Apache HTTPD/APR and OpenSSL should support more platforms than J2SE does). So I don't bother than Tomcat is less "pure" now (do you?). If you don't want to mess with the additional setup procedures or don't trust this native code, or even if it's not available for your platform (the Tomcat/APR connector is still in alpha stage so it's posible that they don't have pre-built binaries for everybody right now) -- you don't have to use it, it's an optional component.

There are other Java programs and libraries that rely on native libs, but this is indeed very rare in such "standard" components like Tomcat, that is not published by Sun and the JCP but it's very close to such official status. Tomcat is the RI for the Servlets and JSP JSRs, and it's the Web container inside Sun's J2EE server, as well as JBoss and others. Because Tomcat is so popular -- I don't know any numbers, but I guess it should be the #1 Java Web container either directly or indirectly as piece of larger J2EE products -- this native-code support will eventually propagate to the other servers, products and apps that rely on Tomcat.

And of course, there is also Grizzly, presented in JavaOne 2005; this is an effort to optimize Tomcat with java.nio, part of Sun's GlassFish project. I wonder whether Grizzly and Tomcat's native connector (which also uses java.nio) are competing or complementary projects? In either case, none of these projects have yet reached production quality, so we'll have to wait for serious benchmarking.

The Java VM technology is wonderful, it can very often compensate the overheads imposed by Java's high-level design and beat native compilers, thanks to the opportunities of dynamic optimizations. But there are a few areas where native code is still better, like strong interaction with the OS (e.g. for front-end TCP/IP handling), and "extreme" algorithms like encryption that depend on such tricks as manual vectorization/SIMD (very often you gotta get down to Assembly, because not even stock C compilers are good enough on these). Now that java.nio and DirectBuffers solved most of the Java/native overhead issues, the biggest reasons to not use more native code are portability and robustness. But if you're not writing new libs, just using stuff like the APR that's already mature and multiplatform, I think there's no conflict with the "Run Everywhere" tenet.

Comments

• So I don't bother than Tomcat is less "pure" now (do you?).

  Yes, I do.

  Posted by: sevenm on October 03, 2005 at 01:25 PM

• Osvaldo,

  Interesting article, but just a side note: Tomcat is not the RI for any JSR; the RIs for JSP 2.0 and Servlets 2.4 is the J2EE 1.4.

  Of course, the J2EE 1.4 RI uses Tomcat internally (as you mentioned below - (Tomcat) it's the Web container inside Sun's J2EE server), so technically speaking Tomcat does implement these technologies. But officially speaking, it is not the RI.

  -- Felipe

  Posted by: felipeal on October 03, 2005 at 01:42 PM

• isn't this Remy's and Mladen's work?

  Posted by: patriot1burke on October 03, 2005 at 02:46 PM

• 
  Felipe: thanks for the correction, indeed, officially the RI is the J2EESDK, but I consider this a bureaucratic detail. In addition to Tomcat being used as J2EESDK's web container, look at the Tomcat team, with Sun engineers like Amy Roh, who is both a Tomcat committer and responsible for the Servlet and JSP RI work inside Sun. For all practical matters, Tomcat is indeed the RI... and if the next major update of Sun's appserver purposedly excludes this native connector, I say that there won't be any justification other than PR/marketing/politics.

  sevenm: Could you elaborate why? Remember again, the native stuff is optional, it adds no new features, only performance. Even Sun does this, for example in their multimedia APIs that have both a PureJava implementation that works everywhere, and enhanced implementations with native code for selected platforms. And let me tell you, the APR and OpenSSH are ported to much more platforms than JAI, Java3D and JMF...
  

  Posted by: opinali on October 04, 2005 at 08:18 AM

• I would preffer an improvement on the Coyotte connector (speed and features). Something like what has been done for Grizzly (see Jean-François post http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html ), that is : use of NIO and realy benefit from Java platform advanced functionalities !

  And remember « The less native code yoy got the less headaches you have » (Old Duke "JNI" mantra) ;-)

  Posted by: bjb on October 04, 2005 at 10:41 AM

• 'Cause people say hot spot java is faster than native code. So what is with this native addition? Can't java (especially NIO) deliver? 'Cause we were protected from buffer overflows until now. Are we going to leave with this fear from now on?

  The only argument that stands is maybe the encryption stuff. AFAIK there are even dedicated hardware components to accelerate this staff. But what is the gain in speed here?

  Regards
  Horia

  Posted by: sevenm on October 05, 2005 at 12:40 AM

• The keys words here are 'optional' and 'optimization'. If you need the speed it's up to you.

  Posted by: simoncolston on October 05, 2005 at 01:39 AM

• There is another way to see this: the Tomcat native connector allows you to depend on less native code. How is that? People often deploy webapps on the combo Apache+Tomcat (with the AJP connector) because Apache is more efficient on static content and SSL. If this is your case, now you need less native code because you can replace the whole Apache server by just a small piece of it -- and with smaller overhead, because with the new native connector, the APR/OpenSSH code are just one JNI invocation away, while the AJP connector uses a TCP/IP-based protocol to reach Apache.

  Posted by: opinali on October 05, 2005 at 06:03 AM

• Osvaldo, good post.

  I would like to make clear that as you note, the APR connector is an optional piece. We will never require non-Java pieces like the APR in order to run Tomcat. It will stay a pure Java product in its core. But we would like to offer our users more options, especially for those (many) who already have the APR, so this does not present an additional dependency.

  Also, please note that the Coyote connector is not abandoned at all. We spent a lot of time optimizing its performance for the 5.5 releases, and although we feel we are at a good point there, work is ongoing.

  Posted by: yoavshapira on October 21, 2005 at 06:35 AM

This work is licensed under a Creative Commons License.