Tag Archives: tomcat

HOWTO tame Apache Tomcat’s logging

Apache Tomcat

Apache Tomcat

If you’re like me, you’ve had to support Apache Tomcat for a good chunk of your IT career, and it hasn’t all been wine and roses. Typically Tomcat will work great in a development, or in a proof of concept environment, but when it comes time to put it in production and have it face some real traffic, well, you get complaints. Now, why do I have a picture of Tomcat on a messenger bag here? It’s because I would like to put Tomcat in a bag…and throw it in a river! But, since I haven’t done that (yet), I’ll talk about recently when I had some tomcat servers pumping out hundred of MGs of logfiles that weren’t being rotated quickly enough, filling up the log partition and causing alerts to go off. Now logrotate is supposed to handle things, and while it’s defaults will generally work fine, any persistant error from tomcat will make the logs quickly eat up all your space and cause you grief, so it’s best to set it up to handle them ahead of time. First take a look at:

HOWTO monitor Tomcat with monit and munin in Debian

I have an existing Tomcat installation in production that has been running hot and causing monit to send me notices that such and such service is down, only to come back clear on the next run. Of course since I use monit I can see that the service was never restarted, plus I’ve never had this happen on other servers with monit, so I’m convinced that Tomcat, with its hunger for Java, is the culrprit here. I’ve been running munin for years on this server too, however I never got the Tomcat plugins to work with it, so I can’t gauge how hot Tomcat is running, and how changing the heap size is effecting things. Because of this, yesterday I got serious about it and finally got it working, but I had to take an end run to get it rolling and it wasn’t fun; which is why I’m posting it here. If anyone knows a better way to do this, please share in the comments and I’ll update this, but here’s how I was successful.

HOWTO: serve jpeg2000 images with a scalable infrastructure

page1At the Biodiversity Heritage Library, we have replaced a proprietary jpeg2000 image server, that was straining under the load, with a new, open source jpeg2000 server, djatoka. Chris Freeland and Chris Moyers cover the background in far more detail on the BHL Blog, so here I’ll cover my rationale and decisions I made to provide a scalable, stable infrastructure to provide the images as efficiently as possible.

When I started sketching out how I wanted to run djatoka, I knew I wanted it to provide security, caching for performance and scalability and fault tolerance. Our server runs Tomcat, which I didn’t want to be public facing. Because of this I proxy Tomcat requests through Apache with the use of ajp_proxy, the successor to the old mod_jk. Initially I was using nginx in place of Apache, but after reading about all the functionality and performance improvements ajp_proxy offered, it was a no brainier; this is how to present Tomcat in a production environment.