3

The Tomcat server configuration (server.xml) has AJP connector enabled by default. And so tomcat by default listens at port 8009.

Why is this by default enabled ?
I thought there will be only few people who will use Apache as reverse proxy, or should we use Apache always as front-end (webserver) and keep tomcat only for servlets and JSP pages ?

Yaalie
  • 175
  • 1
  • 2
  • 8

1 Answers1

1

It's common to place a more fully featured webserver in front of an application server, particularly for serving static content and defining redirects/rewrites. As a general rule, it's a good idea to minimize the number of dependencies you have on your application server backend. The AJP connector is more optimized for this particular use case as it transports the proxied traffic over an optimized binary transport.

Feel free to comment the connector out if you're not going to use it, and don't feel compelled to change your production environment to leverage AJP if things are working fine as they are. I do seem to recall a few less than obvious configuration headaches with httpd that one can run into when proxying AJP instead of HTTP. It's been a few years since I was last a Tomcat admin unfortunately, so I can't really offer specifics.

If it seems that server admins are allergic to letting the application server handle more connections than are strictly necessary, you would not be mistaken. There are several time proven reasons for this:

  • Performance. Dedicated webserver software is usually much better optimized toward delivering static content off the filesystem. Their multitasking implementations are almost entirely devoted to this. It may not seem like a large savings to you, but when you start handling thousands of requests per second that overhead makes a difference.
  • Less state to keep track of. Webapp servers are burdened with much more that they need to keep track of in their memory state. Memory footprint per request is typically much less for the dedicated webserver, and that state is mostly disposable: children processes are frequently recycled when they're done serving a request. It also makes little sense for connection oriented code to execute every time the app needs to serve a file. (sloppy code happens, intentionally or unintentionally)
  • Process isolation. This is a much bigger thing than most people realize. If your webapp container malfunctions (usually Java running out of heap), the extent of your breakage is lessened. This is particularly important if your business hasn't gotten around to funding a good set of load balancers that automatically pull malfunctioning webapps out of the service pool.

In short, admins try to avoid "over complicating" things by not letting the application server handle tasks that they don't need to. It may seem like they're making things more complicated by standing up an additional layer of processes, but in practice things work out for the best this way.

Andrew B
  • 32,588
  • 12
  • 93
  • 131
  • Yes, I have seen such setup in production environments even the ones that are not front-end server (and mostly api servers). Can you please clarify me why can't tomcat handle static content and rewrites ? its been here for more than a decade and I believe its more mature enough. – Yaalie Jan 31 '15 at 04:56
  • It *can* handle rewrites, but it's usually simpler for the server admin to define those at the server level. (they typically know httpd/nginx/etc. better than Tomcat) I'll edit the rest into the post proper. – Andrew B Jan 31 '15 at 05:00