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 3 lines
#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 53 changed one line
}}}
At line 57 changed 4 lines
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
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
At line 62 changed 3 lines
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 67 changed 4 lines
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:
{{{
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:
At line 73 removed one line
}}}
At line 76 changed one line
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.
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.
At line 80 changed 7 lines
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:
{{{
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:
At line 89 changed 4 lines
-Dcom.highlinecorp.deployment=standAlone
}}}
!Instance Options
Load Sharing instances can be deployed in several ways.
-Dcom.highlinecorp.deployment=standAlone (not needed, but available for future use)
At line 94 changed 4 lines
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)
!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
At line 99 removed 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 108 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.
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 111 changed one line
{{{
At line 113 removed 3 lines
}}}
!Changes to JNLP file
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 92 added 2 lines
!Changes to JNLP file
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.
At line 118 changed one line
{{{
At line 121 changed one line
}}}
At line 125 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, the network path must be specified rather than the local machine path to the directory on the [IMST Preferences|IMST#PreferencesTab] 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, you must also specify the network path, rather than the local machine path to the directory on the IMST preferences tab.
At line 129 removed one line
At line 132 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 134 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 added 3 lines
This page (revision-14) was last changed on 26-Nov-2021 10:22 by rforbesTop