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 16 changed 20 lines
!!Project Iterations
An iteration is a deliverable outside of PD. The goal of each iteration should be stated clearly. This section should be updated to show the developer involved and the date completed.
1st Iteration - DK20110401 - Release of major changes to support load sharing & separate report engine
2nd Iteration - Proposed - Split services & watchers between application and report server appropriately
3rd Iteration - Proposed - Report Server Queue - implement maximum number of simultaneous reports
4th Iteration - Proposed - Trim unneeded code from report server to reduce EAR size
5th Iteration - Proposed - Load Sharing becomes more sophisticated Load Balancing & Clustering
!!Related CCARE Cases/Defects
A list of the known CCARE Cases/Defects related to the project and any other background material that may be relevant and helpful.
Below is a list of the CCARE cases/defects related to this project:
Case Defect Cust Pri Status Pgm Problem / Enhancement
45537 PD Done Release of initial changes - Report Server
45538 PD Done Release of initial changes - Load Sharing
45595 QA A Keep getting disconnected from the system
!!Requirements / Features
Outline the specific requirements and features that are being addressed, broken down by topic if the subject area is large. These should be tied to the iterations using [2nd], [3rd], … at the beginning if NOT in the initial iteration so that it is understood by all what will be done and when.
!Separate Report Server
!!Separate Report Server
At line 42 changed 3 lines
*[2nd] Divvy services & watchers between application and report server appropriately
*[3rd] Limit number of reports to run simultaneously and schedule others (Queuing)
*[4th] Remove unneeded packages from report server EAR file
*Divvy services & watchers between application and report server appropriately
*Limit number of reports to run simultaneously and schedule others (Queuing)
*Remove unneeded packages from report server EAR file
At line 46 changed one line
!Load Sharing
!!Load Sharing
At line 52 changed one line
!Common Features
!!Common Features
At line 59 removed 4 lines
!!Implementation
This section MUST be filled out by the developer. It should provide an outline of any business or technical setup required, a list of all processing considerations, and a list of all functions involved in the setup and usage of the feature.
!Overview
At line 65 changed 2 lines
!Application Implementation
;Connections:There are two types of connections made when launching EPersonality; First, the client must visit a link on a web server to download several files which include the java archive (JAR) files containing our code, JARs containing pictures, icons and configuration files, as well as a JNLP file. 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 Implementation
!Connections
There are two types of connections made when launching EPersonality; First, the client must visit a link on a web server to download several files which include the java archive (JAR) files containing our code, JARs containing pictures, icons and configuration files, as well as a JNLP file. 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:
At line 74 changed one line
;Configuration File: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:
!Configuration File
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:
At line 82 changed one line
;Servlet: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.
!Servlet
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.
At line 87 changed one line
;Client Side: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.
!Client Side
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.
At line 90 changed 2 lines
!Set Up
;Deployment Types: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:
!!Set Up
!Deployment Types
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 96 changed one line
;Instance options:Load Sharing instances can be deployed in several ways:
!Instance options
Load Sharing instances can be deployed in several ways:
At line 98 changed 3 lines
• 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
*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
At line 105 changed one line
;Configuration File Location: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.
!Configuration File Location
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 changed one line
;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.
!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
;File Attachment Folders: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.
!File Attachment Folders
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 120 changed one line
;Suggested Deployments:Every instance can be placed on a different machine, or they can all run within the same application server. It depends on available system resources, and the cost of licensing more application servers.
!Suggested Deployments
Every instance can be placed on a different machine, or they can all run within the same application server. It depends on available system resources, and the cost of licensing more application servers.
At line 109 added one line
At line 111 added one line
At line 125 removed 7 lines
!Questions / Additional Notes
This section should contain questions that have been or need to be asked/answered so that the project can be completed.
*What are the specifications needed to support Clustering in an Oracle Application Server?
*Is Clustering easier to support in a WebLogic Application Server?
*Should we consider supporting more than one Report Server instance?
*Can the configuration file be replaced with logic reading connection info directly from OAS?
*Need to form suggested deployment configurations and memory settings (Separate Project)
At line 133 removed 3 lines
!Development Problems / Issues
Provide an outline of all problems, issues or challenges encountered while doing the development work (or anticipated up front).
Where to put Context Watchers? Since there is only one report server, and there should be only one instance of a watcher for a database, it makes sense to put the watchers in the report server instance. However, the WorkFlowLogsWatcher needs to see online users to be able to send messages, and actions to them. This is why the watchers were moved back into the main application deployment. There is no difference to 'Context Watchers' when deployed in a load sharing configuration, to multiple instances pointing to the same database (current option).
At line 137 removed one line
Removing configuration file: Need to research how to get connection information (opmnctl) information directly from Oracle Application Server. However, this removes option to link to other machines, and/or app servers.
At line 139 removed 7 lines
!Resources Released
This does not need to include java classes but should include icons, style changes and documents.
*Sample ePersonality.JNLP file
*Sample connections.config file
*Deployment descriptor web.xml
*Source code changes
This page (revision-14) was last changed on 26-Nov-2021 10:22 by rforbesTop