What is the best way to host potentially dozens of fairly trivial Java web applications on a single machine? These will be for different clients, and so having them isolated from each other is important, so that if one goes down, they don't all go down. I realize Tomcat can handle multiple apps on its own, but having them all run in a single tomcat instance sounds a little scary to me. An instance of tomcat per app also seems silly, since these apps are likely to be fairly basic.

Any thoughts?

7 Answers 7


If they're fairly simple, it's probably not too likely that they will bring the entire server down, so you can run all of them on one or a few instance(s).

If they're not really that simple, or if there are security concerns, then separate them. If there are strong security concerns, even separate them into multiple virtual machines.


First of all, you can use a much lighter Servlet container if you have simple apps with lower BW. winstone is very basic, jetty is a good alternative for medium to large sized apps if you ask me.

All apps can of course consume vast amounts of resources and bring down the whole JVM. What I usually do is to throw all the well-behaved ones in one JVM, and give the nasty ones an JVM each. This especially applies to apps which assume that they own the whole JVM, calling System.exit() etc. You can also throw in some security constraints to prevent that, but this gives you very little IMO, you usually want the app to exit on error.

Regarding performance when having multiple JVMs is to set min heap size fairly high, limit max mem usage and play around with the GC algos a bit to tune each app. JBoss start up scripts have good examples there.

A really neat piece of software for managing all the JVMs is Upstart. It lets you set up respawn rules and define actions on crashes. If you don't have Upstart, you can always use inittab, although syntax errors in inittab can have grave consequences :)


I would probably go with OpenVZ virtualization. It allows you to create separate containers that is lighter than something like vmware. I use this for trivial websites, mandatory FTP servers, etc.


...For different clients, eh?

If they're paying clients, give them their own sandboxes, one per client. If they bring it down it only affects themselves. Seems fair to everyone. Different JVMs is probably the best way to do this.


In addition to the other answers, you can also just run multiple appservers. Most appservers can just be installed into a directory and run from there; I regularly do that with Tomcat when testing servers.

That solution is a middle ground between running all apps in one server, and having a full virtualized OS for each app. If the apps run in different installations, they can only affect each other if the exhaust system-wide resources (CPU, RAM, disk space, network bandwidth). This can be prevented by applying appropriate limits on the OS or server level, just like you would need to do for full virtualization.


Using tomcat is actually a pretty good solution. You can create multiply contexts with would keep each client separated and this gives you a single instance of tomcat. Makes life easy for maintaining. Biggest issue with this though, if you need to add another context, you have to restart tomcat. Using multiply contexts also protects the clients with one decides to do something dumb like running System.exit()

Another solution to look at gives you more control and security is to look at something like Glassfish (https://glassfish.dev.java.net/). Glassfish gives you the ability to create domains (like tomcats contexts, but with alot more control). You can do this dynamically on the fly. This allows you install one instance of glassfish, but each domain runs in its own domain (seperate jvms). Each domain can be completely configured separately.

You will find that if you have more than a couple of clients, going with a solution like tomcat, jetty or other light weight will be more work. Glassfish also provides probably the best graphical interface which you can also expose to your clients if you wish.

Installing glassfish is just as simple as tomcat.


GlassFish v3 can be really lightweight if you configure it so. You can for example run the Web Profile version, which is stripped down specifically for running web applications only (leaving out other parts of Java Enterprise Edition).

But perhaps the key feature in you situation is that it provides for embedding the server in a Java application. This means you have full programmatic control over how it is instantiated, and in how many copies and in what configurations. This might help in automation if you are hosting large amounts of web applications.

You must log in to answer this question.