CODEWITHSUNDEEP
javatomcatglassfishjettywar
Aldo Bucchi
Aldo Bucchi

Reputation: 425

Efficiently deploy multiple instances of same WAR ( different contexts, same container )

I have one WAR ( app.war ) and one container ( Tomcat, Jetty, Glassfish, whatever ). My goal is to deploy, on demand, hundreds of instances of this same web application on the container.

http://foo/app1 --> app.war
http://foo/app2 --> app.war
http://foo/app3 --> app.war 
...
http://foo/appN --> app.war

Some obvious ways of achieving this:

I wonder if there is a better method to do this. Ideally, creating a new instance should not take up ANY more disk space ( other than marginal configuration files ) and only take up memory related to thread execution stacks and other runtime allocations.

Any ideas?

Upvotes: 11

Views: 8624

Answers (5)

stimpy
stimpy

Reputation: 492

Well if this is for an experiment then any of the methods you listed can work.

If this is for production then I would recommend against this. While I have not tested ALL containers, the containers i have used lead me to be believe it is much more resilient to simply provision headless VMs with containers. Linux VMs can be very small and with VM technology you can add or subtract as many instances as needed.

If you truly want to have a dynamically growing solution then you should look to eliminate single points of failure rather then try to lump your entire world into one.

If you truly need "up to the second" load expansion/contraction then you should look at AWS or CloundFoundry.

Upvotes: 0

jesse mcconnell
jesse mcconnell

Reputation: 7182

Jetty added support for what you looking for a while back with what are called overlays.

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

Copying a bit from the wiki page:

  • You can keep the WAR file immutable, even signed, so that it is clear which version you have deployed.
  • All modifications you make to customise/configure the web application are separate WARs, and thus are easily identifiable for review and migration to new versions.
  • You can create a parameterised template overlay that contains common customisations and configuration that apply to many instances of the web application (for example, for multi-tenant deployment).
  • Because the layered deployment clearly identifies the common and instance specific components, Jetty is able to share classloaders and static resource caches for the template, greatly reducing the memory footprint of multiple instances.

Upvotes: 5

beny23
beny23

Reputation: 35038

Apologies for being a little bit off-topic, but in my view, your scenario shouts "multi-tenancy" application, so that you've got a single application which will service multiple "tenants" (customers).

With regard to multi-tenancy setups, the following considerations would have to be considered:

Benefits of multitenancy:

  • Shared code means that a bug fixed for one customer is fixed for all (this can be a disadvantage as well if different customers have different views on what constitutes a bug and what constitutes a feature).
  • Clustered deployment can share the load between customers (however, need to ensure that peak capacity is available for all customerS).

Downsides:

  • Code is going to be a bit more complex as queries need to ensure that the "discrimination" between customers works without accidentially exposing customers to each others data.

Upvotes: 2

ccleve
ccleve

Reputation: 15809

If you're using Jetty, you can add contexts programmatically. 

WebAppContext webapp = new WebAppContext();
webapp.setBaseResource(myBaseDirectory);
webapp.setContextPath(myContextPath);

Just do this in a loop for all your contexts. It should have close to zero diskspace overhead.

There's probably a similar way to do it in Tomcat.

Upvotes: 0

Jason Grant Taylor
Jason Grant Taylor

Reputation: 1239

You could configure Apache on the front end (mod_proxy/mod_proxy_ajp) to point named virtual hosts to a single WAR deployed on Tomcat. Your application should be designed/written in a way to service all request -- per website name specific configuration could be stored in a database or as a configuration file within your application -- your app would just need to probe the user's requesting domain name to ensure the correct settings are applied (once per session). Generally speaking, you should be able to solve this with one application. Great developers are LAZY.

Upvotes: 1

Related Questions