Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am maintaining a growing base of mainly Cocoon-2.1-based web applications [http://cocoon.apache.org/2.1/], deployed in a Tomcat servlet container [http://tomcat.apache.org/], and proxied with an Apache http server [http://httpd.apache.org/docs/2.2/]. I am conceptually struggling with the best way to deploy multiple web applications in Tomcat. Since I'm not a Java programmer and we don't have any sysadmin staff I have to figure out myself what is the most sensible way to do this. My setup has evolved through 2 scenarios and I'm considering a third for maximal separation of the distinct webapps.

[1] 1 Tomcat instance, 1 Cocoon instance, multiple webapps

-tomcat
  |_ webapps
     |_ webapp1
     |_ webapp2
     |_ webapp[n]
     |_ WEB-INF (with Cocoon libs)

This was my first approach: just drop all web applications inside a single Cocoon webapps folder inside a single Tomcat container. This seemed to run fine, I did not encounter any memory issues.

However, this poses a maintainability drawback, as some Cocoon components are subject to updates, which often affect the webapp coding. Hence, updating Cocoon becomes unwieldy: since all webapps share the same pool of Cocoon components, updating one of them would require the code in all web applications to be updated simultaneously.

In order to isolate the web applications, I moved to the second scenario.

[2] 1 Tomcat instance, each webapp in its dedicated Cocoon environment

-tomcat
  |_ webapps
     |_ webapp1
     |  |_ WEB-INF (with Cocoon libs)
     |_ webapp1
     |  |_ WEB-INF (with Cocoon libs)
     |_ webapp[n]
        |_ WEB-INF (with Cocoon libs)

This approach separates all webapps into their own Cocoon environment, run inside a single Tomcat container. In theory, this works fine: all webapps can be updated independently.

However, this soon results in PermGenSpace errors. It seemed that I could manage the problem by increasing memory allocation for Tomcat, but I realise this isn't a structural solution, and that overloading a single Tomcat in this way is prone to future memory errors.

This set me thinking about the third scenario.

[3] multiple Tomcat instances, each with a single webapp in its dedicated Cocoon environment

-tomcat
 |_ webapps
    |_ webapp1
       |_ WEB-INF (with Cocoon libs)
-tomcat
 |_ webapps
    |_ webapp2
        |_ WEB-INF (with Cocoon libs)
-tomcat
 |_ webapps
    |_ webapp[n]
       |_ WEB-INF (with Cocoon libs)

I haven't tried this approach, but am thinking of the $CATALINA_BASE variable. A single Tomcat distribution can be multiply instanciated with different $CATALINA_BASE environments, each pointing to a Cocoon instance with its own webapp. I wonder whether such an approach could avoid the structural memory-related problems of approach [2], or will the same issues apply?

On the other hand, this approach would complicate management of the Apache http frontend, as it will require the AJP connectors of the different Tomcat instances to be listening at different ports. Hence, Apache's worker configuration has to be updated and reloaded whenever a new webapp (in its own Tomcat instance) is added. And there seems no way to reload worker.properties without restarting the entire Apache http server.

Is there perhaps another / more dynamic way of 'modularizing' multiple Tomcat-served webapps, or can one of these scenarios be refined?

Any thoughts, suggestions, advice much appreciated.

Ron

share|improve this question
    
any update on yor quest? –  Cesar Aug 12 at 0:27
    
I've settled for option [2]. Meanwhile, we've switched to a decent server with lots of available RAM, so (so far) we haven't had any memory issues. –  rvdb Aug 18 at 10:55
    
Thanks. May ask you about how many web apps do you handle? –  Cesar Aug 18 at 22:55
    
It's all rather modest: 6 low traffic apps on our production server. On my development laptop I'm running 12 apps (allocating 4G for Tomcat) without problems. –  rvdb Aug 22 at 19:44

1 Answer 1

I've done all that you've mentioned and at this point we've gone a completely different direction. We have a JEos VM image we use with a slimmed down virtualized OS and we clone it for each new application. It isn't the most efficient from a memory/CPU/disk perspective, but saves my sanity from a "which port /directory is everything hooked to".

Basically the SERVER determines which application we're using instead of the port/directory/what have you.

Obviously this doesn't work if all you have is one machine or you're already virtualized. In that case, I'd recommend the common CATALINA_BASE and point each new app to a new CATALINA_HOME. A port numbering convention (go by 10's for example) goes a long way to saving your sanity in this case (trust me).

share|improve this answer
    
Thanks for your thoughts! I'm afraid JeOS is currently a bit above our hardware and my technical capacities, but it sounds interesting. Meanwhile I've settled for scenario [2]... –  rvdb Aug 30 '10 at 12:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.