|Home > Documentation > Installing and running > Running Geronimo > Running multiple Geronimo instances|
Regarding both Geronimo javaee6 and minimal release bundles. Full support for multiple instances was completed in GERONIMO-6270 and its sub-tasks. This support is available in the latest snapshots after March 1, 2012, and will be in the 3.0-beta-2 standard release. This documents how to run multiple instances after applying the changes from GERONIMO-6270.
For prior releases, multiple installations can safely run side-by-side by completely copying the server folder to another, and start the 2nd server installation after changing its portOffset value.
GERONIMO_HOME is the path to the server binary installation and
GERONIMO_SERVER is the path to the server run-time configuration.
GERONIMO_HOME is the path to where Geronimo was installed which every instance references, and every Geronimo instance defines its own
GERONIMO_SERVER as the path to the configuration for the instance.
GERONIMO_SERVER in order to have the Geronimo start procedures startup an instance.
GERONIMO_HOME is obtained during startup relative to the directory Geronimo is installed in. By default, if the user does not define
GERONIMO_SERVER it is set to
GERONIMO_HOME. If the user defines
GERONIMO_SERVER it is attempted to be resolved to an absolute path in the following ways:
GERONIMO_SERVERis not absolute
Skip this sub-section if you do not care about the technical internals of Geronimo's use of
Inside Geronimo there is a concept of
server, with corresponding java properties
server are the same, but Geronimo references
base in general to reference the location for run-time configuration. The definition of
server is user provided, and redefines
When Geronimo runs,
base properties are defined relative to the installation directory of Geronimo. When a user starts up a Geronimo instance, the user defines the
server property. Defining the
server property triggers Geronimo to change its
server thus starting up a Geronimo instance.
Several internal libraries used by Geronimo define two categories of properties as
base, and Geronimo defines these further when
server is defined. Outside of running multiple Geronimo instances
base properties can be used to separate the binary installation from the user-modifiable configuration for a single server installation when that is desirable in some disk layout strategies.
It is possible to run multiple instances of Geronimo on the same machine.
Currently multiple instances of Geronimo share the following directories in
<geronimo_home>, the directory where you installed Geronimo. These are read-only.
The repository is shared, and contains lots of basic and important libraries are required to bootstrap server. It is recommended to configure second repositories, one for each instance. See Configuring multiple Repositories.
When running multiple instances, do not run a server from GERONIMO_HOME but only from GERONIMO_SERVER roots. Also set the
GERONIMO_HOME/repository to be read-only to help prevent accidentally deploying to it when instead the intention is to deploy to the local repository for each Geronimo instance at
Each instance gets its own copy of the following at
etc is read-only and
var is read-write. Both are necessary for each Geronimo instance.
These are also read-write but are not part of the minimally necessary directories and files for running a Geronimo instance, but may be desired. The
repository directories will be automatically created when you start Geronimo if they do not already exist.
<geronimo_home>/<instance_name>, and is not the same as the primary shared repository)
The bin, lib and schema directories are read-only, and thus are shared between instances. The repository is also shared, which means that an application deployed in one instance will show up in the list of deployed modules for all instances. Thus creating the second repository for each instance is recommended to keep deployments local to the Geronimo instances. See Configuring multiple Repositories.
Here is an example layout of what it would look like to have installed one Geronimo instance named "foo-server".
Start with a fresh image of Geronimo. Do not use an image that has been used to run the default instance.
To create an instance named
foo-server do the following. All your instance data will be put in
<geronimo_home>/foo-server. All the directories named below are relative to
Follow the procedures as below:
foo-server. You can use the command deploy:new-server-instance to help you with this step. < GERONIMO-6287
foo-server/repositoryand set it up as a second repository for the Geronimo instance. See Configuring multiple Repositories
foo-server/var/config/config-substitutions.propertiesand change the portOffset. Try using any integers such as 1, 2, 10, 20, 30.. for various instances.
GERONIMO_SERVERenvironment variable to define the server instance directory before you start the server. This variable will be set to
GERONIMO_HOMEas default if not defined. Set
GERONIMO_SERVER=foo-serverto change the server name to an instance named
GERONIMO_SERVER=/opt/geronimo/foo-serverto set the absolute path.
foo-server, the port number should be 1099 plus portOffset specified in
GERONIMO_SERVER=foo-server. See Configuring multiple Repositories for more detailed instructions.
The Administrative Console can also be used for all these operations. Connect to an instance by using the right HTTP port (default 8080).
GERONIMO_HOMEto be. We will use
/opt/geronimo3for this example.
etcto each instance directory
repositorydirectory within each instance directory and set it up as a second repository for the corresponding Geronimo instance. See Configuring multiple Repositories
gserv(1|2)/var/config/config-substitutions.propertiesfile for each Geronimo instance changing the
PortOffset. We'll set the
gserv1to 100 and the
gserv2to 200 for our example.
GERONIMO_HOME/varare removed and
GERONIMO_HOME/repositoryis made read-only
To use multiple repositories see Configuring multiple Repositories.