Appboard/old/multiple instances: Difference between revisions

imported>Cmace
(copied from internalwiki)
 
imported>Jason.nicholls
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Installing Multiple Instances}}
[[Category:AppBoard old]]
There are some special cases where you may want to install more than one instance of AppBoard on the same server. This article details some special considerations to make this work properly.
There are some special cases where you may want to install more than one instance of AppBoard on the same server. This article details some special considerations to make this work properly.


Line 6: Line 8:
The following are some sample cases where you may want to install more than one instance of AppBoard on the same server:
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 aainst one another.
* 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.
* 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.
* 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.
Line 21: Line 23:
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.
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.


Perform the following steps to adjust the AppBoard port configuration for each instance on the server:
Refer to the [[appboard/old/runtime_options|Runtime Options]] page to make changes, specifically the <tt>HTTP_PORT</tt> and <tt>SHUTDOWN_PORT</tt> settings.
 
 
# Open the following file in a text editor: [APPBOARD_HOME]/server/conf/server.xml
# Search for the string "Server port=" to locate the configuration of the shutdown port. You should see a line such as the following:
#: <tt><Server port="8005" shutdown="SHUTDOWN"></tt>
# Make sure this is set to a unique shutdown port value that is not already in use by another AppBoard instance on the same server. Change the port, if needed. For example, change to:
#: <tt><Server port="8006" shutdown="SHUTDOWN"></tt>
# Search for "Connector URIEncoding" to locate the configuration of the main Tomcat startup port. You should see a line such as the following:
#: <tt><Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxThreads="150" <b>port="8080"</b> protocol="com.edgetech.eportal.connector.Http11NioProtocol" redirectPort="8444" compression="on" compressableMimeType="application/x-amf" compressionMinSize="1024"/></tt>
#  Notice the "port=8080" setting in the above example. Make sure this is set to a unique startup port value that is not already in use by another AppBoard instance on the same server. Change the port, if needed. For example, change to:
#: <tt><Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxThreads="150" <b>port="8081"</b> protocol="com.edgetech.eportal.connector.Http11NioProtocol" redirectPort="8444" compression="on" compressableMimeType="application/x-amf" compressionMinSize="1024"/></tt>
 
 
{{Note|The redirectPort is only used when SSL is enabled, to re-direct non-SSL requests to SSL. You can change this to a unique value also, to ensure that there will not be a conflict. However, unlike the shutdown and startup ports, you are able to start multiple instances that have the same redirectPort setting.}}
 


=== Memory Configuration ===  
=== Memory Configuration ===  
Line 43: Line 30:




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.
One way to limit the memory footprint of AppBoard is in the Tomcat [[appboard/old/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 ===
=== Database ===
Line 51: Line 37:


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 [[appboard/old/tomcat_binding|Binding AppBoard/enPortal to a specific IP/Interface]].

Latest revision as of 16:29, 17 July 2014

There are some special cases where you may want to install more than one instance of AppBoard on the same server. This article details some special considerations to make this work properly.


Uses

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.


Configuration

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 page to make changes, specifically the HTTP_PORT and SHUTDOWN_PORT 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 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 AppBoard/enPortal to a specific IP/Interface.

Retrieved from "http://ab.edge-technologies.com/docs/index.php?title=Appboard/old/multiple_instances&oldid=939"