Appboard/2.4/admin/multiple instances - Revision history

imported>Jason.nicholls: /* Configuration */

2014-07-10T10:02:05Z

Configuration

← Older revision		Revision as of 10:02, 10 July 2014
Line 35:		Line 35:


	{{Warning\|When running multiple AppBoard instances the total memory usage of all AppBoard copies needs to be considered with respect to the total available memory on the server. Refer to the [[~~Memory_Configuration~~\|Memory Configuration]] page for more information}}		{{Warning\|When running multiple AppBoard instances the total memory usage of all AppBoard copies needs to be considered with respect to the total available memory on the server. Refer to the [[appboard/2.4/admin/memory_configuration\|Memory Configuration]] page for more information}}

	{{Note\|On Linux/UNIX systems it's possible to install multiple system services for multiple AppBoard instances on the same server, as long as each service is given it's own unique name.}}		{{Note\|On Linux/UNIX systems it's possible to install multiple system services for multiple AppBoard instances on the same server, as long as each service is given it's own unique name.}}

imported>Jason.nicholls: /* Configuration */

2014-04-01T06:55:35Z

Configuration

← Older revision		Revision as of 06:55, 1 April 2014
Line 18:		Line 18:
	== Configuration ==		== Configuration ==

	Refer to the [[~~Runtime_Options~~\|Runtime Options]] page for a complete listing of options and how to configure, but for the purposes of running multiple copies of AppBoard on the same server the following are critical:		Refer to the [[appboard/2.4/admin/runtime_options\|Runtime Options]] page for a complete listing of options and how to configure, but for the purposes of running multiple copies of AppBoard on the same server the following are critical:

	{\|class='wikitable'		{\|class='wikitable'

imported>Jason.nicholls at 06:43, 14 December 2013

2013-12-14T06:43:09Z

← Older revision		Revision as of 06:43, 14 December 2013
Line 1:		Line 1:
	{{DISPLAYTITLE:Multiple Instances}}		{{DISPLAYTITLE:Multiple Instances}}
			[[Category:AppBoard 2.4]]

	Multiple instances of AppBoard can be configured to run on the same system. This article details some of the considerations to have this work correctly.		Multiple instances of AppBoard can be configured to run on the same system. This article details some of the considerations to have this work correctly.

imported>Jason.nicholls: /* Configuration */

2013-09-30T12:29:13Z

Configuration

← Older revision		Revision as of 12:29, 30 September 2013
Line 35:		Line 35:

	{{Warning\|When running multiple AppBoard instances the total memory usage of all AppBoard copies needs to be considered with respect to the total available memory on the server. Refer to the [[Memory_Configuration\|Memory Configuration]] page for more information}}		{{Warning\|When running multiple AppBoard instances the total memory usage of all AppBoard copies needs to be considered with respect to the total available memory on the server. Refer to the [[Memory_Configuration\|Memory Configuration]] page for more information}}

			{{Note\|On Linux/UNIX systems it's possible to install multiple system services for multiple AppBoard instances on the same server, as long as each service is given it's own unique name.}}

imported>Jason.nicholls: /* Configuration Database */

2013-09-30T12:27:20Z

Configuration Database

← Older revision		Revision as of 12:27, 30 September 2013
Line 37:		Line 37:


	=== Configuration ~~Database~~ ===		=== Database Configuration ===

	If you are using the default AppBoard database settings and the embedded local AppBoard H2 database, no special configuration is required to run multiple instances on the same server. Each instance ill use it's own database.		If you are using the default AppBoard database settings and the embedded local AppBoard H2 database, no special configuration is required to run multiple instances on the same server. Each instance ill use it's own database.

	If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.		If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.

imported>Jason.nicholls: /* Database */

2013-09-30T12:27:04Z

Database

← Older revision		Revision as of 12:27, 30 September 2013
Line 37:		Line 37:


	=== Database ===		=== Configuration Database ===

	If you are using the default AppBoard database settings and the embedded local AppBoard H2 database, no special configuration is required to run multiple instances on the same server. Each instance ill use it's own database.		If you are using the default AppBoard database settings and the embedded local AppBoard H2 database, no special configuration is required to run multiple instances on the same server. Each instance ill use it's own database.

	If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.		If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.

imported>Jason.nicholls: /* Configuration */

2013-09-30T12:25:01Z

Configuration

← Older revision		Revision as of 12:25, 30 September 2013
Line 17:		Line 17:
	== Configuration ==		== Configuration ==

	Refer to the [[Runtime_Options\|Runtime Options]] page for a complete listing of options, but for the purposes of running multiple copies of AppBoard on the same server the following are critical:		Refer to the [[Runtime_Options\|Runtime Options]] page for a complete listing of options and how to configure, but for the purposes of running multiple copies of AppBoard on the same server the following are critical:

	{\|class='wikitable'		{\|class='wikitable'
Line 33:		Line 33:
	\|}		\|}

	~~Review the following items to make sure each of the AppBoard instances is configured properly.~~

			{{Warning\|When running multiple AppBoard instances the total memory usage of all AppBoard copies needs to be considered with respect to the total available memory on the server. Refer to the [[Memory_Configuration\|Memory Configuration]] page for more information}}
	~~=== Port Configuration ===~~

	When installing more than one instance of AppBoard on the same server, the most important item to configure is the ports. There are two ports used by each instance, and they must be unique for each system. If you start an AppBoard system, and it tries to use a port that is already in use, you will receive a JVM Bind Error, and the system will not start.

	~~Refer to the [[Runtime_Options~~\|~~Runtime Options]] page to make changes, specifically the <tt>HTTP_PORT</tt> and <tt>SHUTDOWN_PORT</tt> settings.~~


	~~=== Memory Configuration ===~~

	When running multiple AppBoard instances ~~on the same server, the system administrator should consider~~ the memory ~~capacity~~ of ~~the server. If the System Requirements recommend 2 GB of RAM for~~ AppBoard~~, it would~~ be ~~advisable for example~~ to ~~have 4 GB of RAM if two instances will be running~~ on the ~~same~~ server.


	~~One way~~ to ~~limit the memory footprint of AppBoard is in~~ the ~~Tomcat~~ [[Memory_Configuration\|~~memory configuration settings~~]]. For a dev or demo instance, you can typically lower the Java Virtual Machine (JVM) maximum heap size (-Xmx JVM parameter) to a low setting such as -Xmx512m. without any noticeable change in performance.


Line 56:		Line 42:

	If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.		If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.


	~~=== Configuring Dual-NIC Deployments ===~~

	In some cases, you may want to run two AppBoard applications on the same server that bind to different IP addresses. For instructions on this, see [[Binding_To_A_Specific_IP\|Binding AppBoard/enPortal to a specific IP/Interface]].

imported>Jason.nicholls: Created page with '{{DISPLAYTITLE:Multiple Instances}} Multiple instances of AppBoard can be configured to run on the same system. This article details some of the considerations to have this work…'

2013-09-30T12:22:31Z

Created page with '{{DISPLAYTITLE:Multiple Instances}} Multiple instances of AppBoard can be configured to run on the same system. This article details some of the considerations to have this work…'

New page

{{DISPLAYTITLE:Multiple Instances}}

Multiple instances of AppBoard can be configured to run on the same system. This article details some of the considerations to have this work correctly.

== Why Multiple Instances? ==

The following are some sample cases where you may want to install more than one instance of AppBoard on the same server:

* Testing - The test team needs to have multiple versions of the system available so they can validate the functionality and features against one another.
* Development - A developer is working on multiple AppBoard development projects at the same time.
* Staging - A production and dev system are both running on the production server. They can be swapped, for example, to make the dev system become the production system after validation is complete and certified.
* Demos - Multiple demo systems can be created and provided at the same time for review.
* Multi-homed server - have different copies of AppBoard running for different target networks.

== Configuration ==

Refer to the [[Runtime_Options|Runtime Options]] page for a complete listing of options, but for the purposes of running multiple copies of AppBoard on the same server the following are critical:

{|class='wikitable'
!Option
!Description
|-
|HTTP_PORT
|Each instance will need to listen on a different port.
|-
|SHUTDOWN_PORT
|Each instance will need it's own shutdown port.
|-
|HTTP_ADDRESS
|(optional) for multi-homed systems, restrict AppBoard to listen only on a specific IP address.
|}

Review the following items to make sure each of the AppBoard instances is configured properly.

=== Port Configuration ===

When installing more than one instance of AppBoard on the same server, the most important item to configure is the ports. There are two ports used by each instance, and they must be unique for each system. If you start an AppBoard system, and it tries to use a port that is already in use, you will receive a JVM Bind Error, and the system will not start.

Refer to the [[Runtime_Options|Runtime Options]] page to make changes, specifically the <tt>HTTP_PORT</tt> and <tt>SHUTDOWN_PORT</tt> settings.

=== Memory Configuration ===

When running multiple AppBoard instances on the same server, the system administrator should consider the memory capacity of the server. If the System Requirements recommend 2 GB of RAM for AppBoard, it would be advisable for example to have 4 GB of RAM if two instances will be running on the same server.

One way to limit the memory footprint of AppBoard is in the Tomcat [[Memory_Configuration|memory configuration settings]]. For a dev or demo instance, you can typically lower the Java Virtual Machine (JVM) maximum heap size (-Xmx JVM parameter) to a low setting such as -Xmx512m. without any noticeable change in performance.

=== Database ===

If you are using the default AppBoard database settings and the embedded local AppBoard H2 database, no special configuration is required to run multiple instances on the same server. Each instance ill use it's own database.

If your system is configured to access an external database, such as Oracle or MySQL, then care must be taken. If you have two systems running locally that are accessing the same database, unpredictable results may occur. For example, if you add a test User on the dev instance, and this is connected to the same database as the production instance, the test User will also appear in the production instance.

=== Configuring Dual-NIC Deployments ===

In some cases, you may want to run two AppBoard applications on the same server that bind to different IP addresses. For instructions on this, see [[Binding_To_A_Specific_IP|Binding AppBoard/enPortal to a specific IP/Interface]].