Deploying Multiple Atlassian Applications in a Single Tomcat Container

Deploying multiple Atlassian applications in a single Tomcat container is not supported. We do not test this configuration and upgrading any of the applications (even for point releases) is likely to break it. There are also a number of known issues with this configuration:
  • You may not be able to start up all of the applications in the container, due to class conflicts (in 3rd party libraries bundled with our application) that result from the Atlassian applications sharing a single JVM in the Tomcat container.
  • You will not be able to determine the startup order of the applications. Hence, you may experience problems such as JIRA starting before Crowd, rather than vice versa.
  • Memory problems are also common as one application may allocate all of the memory in the Tomcat JVM to itself, starving the other applications.

We also do not support deploying multiple Atlassian applications to a single Tomcat container for a number of practical reasons. Firstly, you must shut down Tomcat to upgrade any application and secondly, if one application crashes, the other applications running in that Tomcat container will be inaccessible.

Finally, we recommend not deploying any other applications to the same Tomcat container that runs the Atlassian application, especially if these other applications have large memory requirements or require additional libraries in Tomcat's lib subdirectory.

Was this helpful?

Thanks for your feedback!

1 Archived comment

  1. User avatar

    Brian Topping

    While these are all true, there are also numerous advantages to having them running in the same container:

    • Singular config of container connectors means they all work or all don't. No having to debug the same configuration multiple times on different standalone installs that have evolved in different directions.
    • A single connector in the client container (e.g. Tomcat) is far easier to debug when it is frontended by a web server such as Apache HTTPD.
    • Free memory is consolidated and shared, resulting in a far smaller overall footprint. Having five apps with 500M of free space is a far different memory footprint than one container with 1G of free space that is more than generously shared. When I switched from a single Tomcat container to standalone apps as configured on the download site, I had to boost the RAM on the box by 2x to avoid paging!

    There are a lot of pros and cons to either situation and not much we users can do but express our grief. Ideally, Atlassian could come up with their own custom container that housed their webapps, sharing services, increasing reliability, and reducing TCO.

    16 Dec 2010
Powered by Confluence and Scroll Viewport