Question

I am working on a web application with dynamic content generated by a servlet running in a JBoss container and static content/load balancing being handled by Apache + mod_jk.

The client end uses jQuery to making AJAX requests to the servlet which processes them and in turn generates large JSON responses.

One thing I noticed is that the original author chose to manually compress the output stream in the servlet using something like below.

 gzout = new GZIPOutputStream(response.getOutputStream());

Could this have been handled using mod_deflate on the Apache end? If you can do this, is it considered better practice, can you explain why or why not?

Answer 1

A little additional research shows a couple of good alternatives.

Issue:

1. There is a network channel that exists between Apache and Jboss. Without compression of any kind on the jboss end you’d have the same latency and bandwidth issues you have between Apache and your clients.

Solutions:

1. You can use mod_deflate on the Apache and accept uncompressed responses from jboss and compress before delivering to your clients. I could see this making some sense in certain network topologies(Proposed by Dave Ward).

2. You can apply a Java EE filter. This will filter responses compressing them before they exist the JBoss container. This has the benefit of compression at the JBoss level without a bunch of nasty GZIP related code in your business servlet.

3. JBoss with by default uses Tomcat as its Servlet engine. If you navigate to $JBOSS_HOME/deploy/jbossweb-tomcat55.sar you can edit the server.xml file to turn ‘compression=on’ attribute on the HTTP/1.1 connector. This will compress all responses outbound from the container.

The trade-off between 2 and 3 is compressing piece meal for different servlets or compressing all responses.