This page (revision-14) was last changed on 26-Nov-2021 10:22 by rforbes

This page was created on 26-Nov-2021 10:22 by jmyers

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
14 26-Nov-2021 10:22 11 KB rforbes to previous
13 26-Nov-2021 10:22 11 KB rforbes to previous | to last
12 26-Nov-2021 10:22 11 KB jmyers to previous | to last
11 26-Nov-2021 10:22 11 KB jmyers to previous | to last
10 26-Nov-2021 10:22 11 KB jmyers to previous | to last
9 26-Nov-2021 10:22 11 KB jmyers to previous | to last
8 26-Nov-2021 10:22 11 KB jmyers to previous | to last
7 26-Nov-2021 10:22 14 KB jmyers to previous | to last
6 26-Nov-2021 10:22 14 KB jmyers to previous | to last
5 26-Nov-2021 10:22 14 KB jmyers to previous | to last
4 26-Nov-2021 10:22 14 KB jmyers to previous | to last
3 26-Nov-2021 10:22 14 KB jmyers to previous | to last Load Sharing & Separate Report Server ==> LOAD SHARING AND SEPARATE REPORT SERVER
2 26-Nov-2021 10:22 14 KB jmyers to previous | to last
1 26-Nov-2021 10:22 14 KB jmyers to last

Page References

Incoming links Outgoing links
LOAD SHARING AND SEPARATE REPORT SERVER
LOAD SHARING AND SEPARATE REPORT SERVER

Version management

Difference between version and

At line 48 changed one line
#The JNLP file contains the information to make the second connection to the application server, through which all application communication is routed thereafter. A sample of this part of the JNLP file is included below:\\<application-desc main-class="com.highlinecorp.professional.EPersonality">
#The JNLP file contains the information to make the second connection to the application server, through which all application communication is routed thereafter. A sample of this part of the JNLP file is included below:\\
{{{
<application-desc main-class="com.highlinecorp.professional.EPersonality">
At line 51 changed one line
}}}
At line 55 changed one line
We created a configuration file on the server which contains a comma-separated list of all available application instances as well as a report server instance. A sample of the file is included below:\\ \\#Format: reportHost=xxx|port,yyy|port
A configuration file has been created on the server which contains a comma-separated list of all available application instances as well as a report server instance. A sample of the file is included below:
{{{
#Format: reportHost=xxx|port,yyy|port
At line 57 changed one line
reportHosts=http://phobos.highlinecorp.com:7779/ePersonality_AS07@12413\\ \\A system administrator can add to the list in this file as more instances become available, or restrict the list in this file, and changes are picked up in a matter of seconds. This can reduce downtime by redirecting clients to another instance whenever a new EAR is deployed, or if there is ever a problem with the server and it needs to be restarted.
reportHosts=http://phobos.highlinecorp.com:7779/ePersonality_AS07@12413
}}}
A system administrator can add to the list in this file as more instances become available, or restrict the list in this file, and changes are picked up in a matter of seconds. This can reduce downtime by redirecting clients to another instance whenever a new EAR is deployed, or if there is ever a problem with the server and it needs to be restarted.
At line 60 changed 2 lines
We built a small Java Servlet into the application to 'serve up' this information to clients application when they want to connect. The servlet will iterate over the list for every login, such that the first user logging in will be directed to the first server in the list, the second user login will be directed to the second server in the list, and so on. The servlet will continually repeat through the list in an effort to distribute online users evenly over the available applications. Each client will also retrieve the report server information, in the event they wish to run a report at any time during their session.
The Servlet can be tested by opening (the following sample) URLs in a web browser and refreshing to get new connection information saved in the configuration file:
A small Java servlet was built into the application to 'serve up' this information to applications when users want to connect. The servlet will iterate over the list for every login, such that the first user logging in will be directed to the first server in the list, the second user login will be directed to the second server in the list, and so on. The servlet will continually repeat through the list in an effort to distribute online users evenly over the available applications. Each client will also retrieve the report server information, in the event they wish to run a report at any time during their session.
The servlet can be tested by opening (the following sample) URLs in a web browser and refreshing to get new connection information saved in the configuration file:
{{{
At line 73 added one line
}}}
At line 66 changed 2 lines
Now, when launching EPersonality, three connections are made, the first to download the JARs and JNLP, the second to connect to the servlet and retrieve information to make the third connection to the server which will handle all application communication. The second step also receives connection information to a report server, and a fourth connection may be made if the user launches a report during their session.
Essentially, we have added another step between the original two connections to contact the server and get the correct connection information from the configuration file.
When launching the application, three connections are made, the first to download the JARs and JNLP, the second to connect to the servlet and retrieve information to make the third connection to the server which will handle all application communication. The second step also receives connection information to a report server, and a fourth connection may be made if the user launches a report during their session.\\ \\Essentially, another step has been added between the original two connections to contact the server and get the correct connection information from the configuration file.
At line 71 changed one line
The same EAR can be used for all 3 types of deployments: Load Sharing, Report Server and Stand Alone applications. An example of a stand-alone application is one application instance to one database. With the exception of stand-alone applications, all instances must define the deployment type as one of the following JVM arguments:
The same EAR can be used for all three types of deployments:
*Load Sharing
*Report Server and
*Stand Alone applications
An example of a stand-alone application is one application instance to one database. All instances must define the deployment type as one of the following JVM arguments:
{{{
At line 74 changed one line
-Dcom.highlinecorp.deployment=standAlone (not needed, but available for future use)
-Dcom.highlinecorp.deployment=standAlone
}}}
!Instance Options
Load Sharing instances can be deployed in several ways.
At line 76 changed 9 lines
!Instance options
Load Sharing instances can be deployed in several ways:
For example, if a customer wishes to use 3 instances for load sharing, they could deploy;
*One instance with 3 Java Processes (JVMs)
*OR Three instances could be deployed with 1 JVM each
*OR The client can mix and match (eg) 2 instances with 1 and 2 JVMs respectively
An instance with multiple JVMs has the feature of reduced work when deploying or restarting an instance since the action needs to be done once by an administrator, and the Oracle AS will duplicate the work for every other JVM. However, the drawback is that JVMs cannot be restarted or redeployed individually, causing all application processes to be down (mix and match option may solve this).
Report Servers must have a completely separate instance with (1) JVM.
Report Servers should not have any startup cache loaded - configured in AppResources/selfServiceStyle.xml
For example, if a user wishes to use three instances for load sharing, they could deploy;
*One instance with three Java Processes (JVMs),
*or three instances could be deployed with one JVM each,
*or the user can mix and match (e.g. two instances with one and two JVMs respectively)
At line 99 added 8 lines
An instance with multiple JVMs has the feature of reduced work when deploying or restarting an instance since the action needs to be done once by an administrator and the Oracle AS will duplicate the work for every other JVM.
However, the drawback is that JVMs cannot be restarted or redeployed individually, causing all application processes to be down (mix and match option may solve this).
Report servers must have a completely separate instance with one JVM.
Report servers should not have any startup cache loaded - configured in AppResources/selfServiceStyle.xml
At line 87 changed 2 lines
A file named connections.config must be created for every application deployment, and modified by the system administrator to reflect the available deployments. The applications listens for changes to this file and they are picked up in a matter of seconds.
This file can be placed in the same root directory as the JNLP file. To override this, you may also specify a file locations as a JVM argument using:
A file named connections.config must be created for every application deployment and modified by the system administrator to reflect the available deployments. The applications listens for changes to this file and they are picked up in a matter of seconds.
At line 110 added 2 lines
This file can be placed in the same root directory as the JNLP file. To override this, you may also specify a file locations as a JVM argument using:
{{{
At line 91 changed one line
}}}
At line 93 changed 2 lines
Since the RMI port is now retrieved from the Servlet when the client side application starts up, there is no need to add it into the JNLP file. However, if a PORT argument is in the JNLP file, the client will use it to connect to the same RMI port every time (ie) It will use the old implementation to connect to the server and no load sharing or separate report server will be accessed, even if they exist.
Also, note that when using this servlet, the SERVER_IP argument has changed to use the selfService context. The relevant JNLP file portion now looks like this:
Since the RMI port is now retrieved from the servlet when the client side application starts up, there is no need to add it into the JNLP file. However, if a PORT argument is in the JNLP file, it will be used to connect to the same RMI port every time. (i.e. It will use the old implementation to connect to the server and no load sharing or separate report server will be accessed, even if they exist.)
At line 117 added 2 lines
Also, note that when using this servlet, the SERVER_IP argument has changed to use the selfService context. The relevant JNLP file portion now looks like this:
{{{
At line 98 changed one line
}}}
At line 102 changed one line
If the report server is setup on a different machine, the file attachments folder must be accessible to this server as well in order to save and retrieve report output files. In this case, you must also specify the network path, rather than the local machine path to the directory on the IMST preferences tab.
If the report server is setup on a different machine, the file attachments folder must be accessible to this server as well in order to save and retrieve report output files. In this case, the network path must be specified rather than the local machine path to the directory on the [IMST Preferences|IMST#PreferencesTab] tab.
At line 129 added one line
At line 108 changed one line
The minimal number of instances to take advantage of both features is three; two instances for load sharing and one for a separate report engine.
The minimal number of instances to take advantage of both features is three, two instances for load sharing and one for a separate report engine.
At line 110 changed one line
The correct configuration will depend on the size of the customer database and usage. It may be possible to make an educated guess on the initial number of instances in a load sharing configuration, and then fine tune through experimentation.
The correct configuration will depend on the size of the customer database and usage. It may be possible to make an educated guess on the initial number of instances in a load sharing configuration and then fine tune through experimentation.
At line 112 removed 3 lines
This page (revision-14) was last changed on 26-Nov-2021 10:22 by rforbesTop