Oracle WebLogic Server 11g for IT OPS

WebLogic Server 11g for IT Operations Name – Rakesh Gujjarlapudi

Email Address – [email protected]

mailto:[email protected]

Oracle Weblogic 11g P a g e | 2

Introduction This document introduce through the setup, configuration, and operation of a production configuration of WebLogic Server. The goal of this document is for IT Operators to quickly become familiar with WebLogic Server and understand some of its most important capabilities. The version of the application server that will be used throughout the labs is WebLogic 10.3.4.

Assumption: WebLogic server is already installed on the machine with Windows operating system

WebLogic Server 11g Info:

1. MIDDLEWARE_HOME=c:\Oracle\Middleware 2. Configuration Wizard = ${MIDDLEWARE_HOME}\wlserver_10.3\common\bin\config.cmd 3. By default the admin server in each domain will listen to requests at port 7001. 4. The Admin Server Console for the domain can be accessed with the URL:

http://<machine_ip>:7001/console Oracle XE Info:

Database Version: 10.2.0 (10g) XE

Installation folder: c:\oraclexe

User: sys / oracle

User: system/oracle


Lesson 1: Creating a WebLogic Domain Summary

This lesson will teach how to create a domain in 2 different ways: 1. WebLogic Domain from scratch 2. WebLogic Domain based on a domain template

We can use either a Graphical User Interface (GUI) or the command line tool to create a domain. Command line tool will do everything you can do with the GUI.

Clean-up work Verify that there are no existing domain folders in the following directory.

Change directory to c:\Oracle\Middleware\user_projects.

Delete any folder that may exist in this directory. Note: This is required to avoid any conflicts

Creating a WebLogic Domain from scratch

1. To create a WebLogic Domain from scratch, use the Domain Configuration Wizard. Access the Configuration wizard from the “Start Menu” on your Windows XP image as shown:

2. Follow prompts and enter the fields as shown: Field Value Domain Name wls_domain WL Username weblogic WL Password welcome1


3. Steps

Step 1

Step 2


Step 3

Step 4


Step 5 For the JDK, choose either the Sun JDK or the JRockit JDK since WebLogic supports both. Select JRockit. Select the default “Development mode” for WebLogic Startup mode.

Step 6

Click on the “Next” button for the next couple of screens until you arrive at the “Configuration Summary” screen as shown below. Now click “Create”. This will create the domain and all the artifacts required to run a domain.


Step 6

On the Domain summary screen, note the location on the file system where the domain folder has been created as well as the host and port number where the domain will listen for requests. By default, WebLogic Domains listen to unencrypted requests at port 7001 and encrypted requests at 7002. Click on “Start Admin Server” and then “Done”. This will close the wizard and automatically start the Admin server in a separate command window.

Step 7

You should see the command window that WebLogic runs in pop up. To determine that the domain is done starting, look for “RUNNING mode” and the correct listen address above it.


Step 8

Using either Internet Explorer or Firefox, visit the WLS console at http://<hostname>:7001/console and verify that you can log in as weblogic/welcome1. Note that you can use “localhost” or your hostname as part of the URL, and this is entirely configurable. You may see the following screen saying that the application is being deployed followed by the login screen. This is normal

Step 9


Step 10

The WebLogic administration console pictured below allows a user to start and stop server, create clusters, configure parameters, configure JDBC data sources, configure JMS connection factories, queues and topics.

Step 11

Logout of the admin console and stop WebLogic that is running in the window. To stop it, you can hit Ctrl+C in the window where WebLogic is running. Or (better for real-life scenarios), there is also a stop script located in the <DOMAIN_HOME>/bin directory that is usually customized and run. The following screen shows the stop script about to be executed from another prompt:

Note: <DOMAIN_HOME> in our exercise is

c:\oracle\middleware\user_projects\domains\wls_domain.


Creating a WebLogic Domain from a domain template

Create a WebLogic domain using a pre-packaged domain template which includes a WebLogic domain, a configured connection pool, and a deployed application. This is a typical way to build a production domain, since it ensures consistency with other environments. Although GUI is used here, this is entirely scriptable, and allows for cross-platform work. Navigate to the configuration wizard as shown below

A pre-configured template that is wls_domain.jar is provided

Start the configuration wizard and step through the following screens:


Step 1

Step 2


Step 3

On the next screen, make sure to change the domain name from the default “wls_domain” to “wls-domain_template”. Failure to do will result in overwriting and corrupting the domain created in the previous exercise.

Step 4 Accept the default values on the next few screens


Step 5

Step 6 On the Configure JDBC Data Sources screen, select wls as shown below and enter the password as “oracle”. Then select “Next” to proceed to the next screen.


Step 7

Step 8

Select “Deployment and Services” on the next screen as shown below in order to see what

applications have been deployed and what services have been pre-configured in this domain

template:


Step 9

Step 10


Step 11

Create the domain by selecting the “Create” button on the Configuration Summary screen

Step 12

Once the domain has been created, check “Start Admin Server” and select “Done”. This will close the domain configuration wizard and automatically start the WebLogic server


Step 13 Verify the domain has started by looking for “RUNNING MODE” and the listen port as verification that the server has started. By default the server will listen for requests on port 7001 on the localhost

Step 14 Using a browser, access the WebLogic console using the URL http://<hostname>:7001/console and verify that you can login as “weblogic/weblogic1”.


Step 15

Step 16 Click on “Deployments” under “Domain Structure” and notice that the application “DizzyHR” that had been pre-deployed in the domain template is listed


Step 17 Also navigate to “Services” and then “Data Sources” and notice that the data source “wls” that we tested during domain creation is also listed

Logout of the admin console and stop WebLogic that is running in the window. To stop it, you can hit Ctrl+C in the window where WebLogic is running. Or (better for real-life scenarios there is also a stop script located in the <DOMAIN_HOME>/bin directory that is usually customized and run.


Lesson 2: Creating a WebLogic Domain

Summary

Create a WebLogic cluster with two managed servers. Below is a diagram of a typical environment for a highly-available clustered deployment of WebLogic Server. In this configuration, WebLogic Server runs an application that a user has deployed on two “managed servers” that are running on two physically separate servers. These managed servers are configured as a WebLogic Server “cluster” to support failover and high availability. Additionally, two web servers are configured in front of the cluster and proxy requests to the two managed servers in the cluster.

Following is the definition of the physical and logical names and configuration parameters needed to define the WebLogic Server Environment.

Machine 1

Server Names Non-Secure Port Secure Port

AdminServer_foo 7001 7001

MS1 8001 8002

MS2 9001 9002

nodemanager 5556

apache 80 443

NOTE 1: Ideally, it is best to put the Admin Server on its own machine just as a separation of concerns

(manager versus operational servers that are managed).


NOTE 2: Naming convention “AdminServer_X” is handy where “X” is the name of the domain that this

AdminServer manages. In this case it is the “foo_domain”.

Middleware Home:

This is the environment variable “MW_HOME” indicating where WebLogic Server 10.3.4 is installed. The default value for this workshop is:

C:\Oracle\Middleware

Domain Name and Location:

Location: $MW_HOME\user_projects\domains

Name: foo_domain

Cluster Names multicast port #s:

app1_cluster 239.192.0.0/7001


Configuring Domain

1. Start the Domain Configuration Wizard. On Windows, select Start -> All Programs -> Oracle WebLogic -> WebLogic Server 11gR1 -> Tools -> Configuration Wizard.

Alternatively, you can run the command: C:\Oracle\Middleware\wlserver_10.3\common\bin\config.cmd

2. Below are screenshots stepping through the creation of the domain using the Oracle WebLogic

Configuration Wizard


3. Enter the domain name: “foo_domain”


4. Specify the Username and Password for the administration user – typically set to

“weblogic/welcome1”

5. Select JRockit and Production mode


6. Next, select to customize both the “Administration Server” and “Managed Servers…” settings:

7. Set the Administration Server settings to the following:

Name: AdminServer_foo Listen Address: “All Local Addresses” Listen Port: 7001 SSL Listen Port: 7002 SSL Enabled : Checked


8. Configure Managed Servers by selecting the “Add” button and enter the information as shown

below:

9. Configure the cluster as shown below. WebLogic supports both unicast

and multicast communication between cluster members. For this lab,

make sure to choose multicast.


10. Assign each managed server to the cluster by selecting the managed server with

the mouse then clicking on the button to move the managed server under the

cluster.


11. Configure Machines – Note that the “Machine” tab is for Windows boxes and “Unix Machine”

tab is for Unix boxes. In real production systems, you are required to put in the hostnames/IP

addresses that are in DNS.

12. Assign all three of the servers to the machine (host1) that you just created.


13. In the Configuration Summary screen, review all the config information. Select the “Create”

button to create the domain. Don’t select “Start Admin Server” as you did previously. Instead

just select “Done”.

14. It may be desirable to modify the startup memory parameters of the servers. To do this, one would have to modify the “setDomainEnv.cmd” script in the domain’s home directory.

These would be in the directory:

C:\Oracle\Middleware\user_projects\domains\foo_domain\bin

Accept the default parameters.

Starting Admin Server

1. Start the Admin server. One can do it either through the Windows Menu or

through the command line tool. In order to start the admin server from the

Windows Menu follow the path shown in the screen shot below:


One can also start the admin server from the command prompt by navigating to

C:\Oracle\Middleware\user_projects\domains\foo_domain and running startWebLogic.cmd

2. A command-window will run the JVM with a WebLogic Server instance

displaying the console output for the admin server. Put in the admin

credentials specified when the domain was created (weblogic/welcome1 –

later we’ll discuss how to eliminate the need for typing credentials in by

hand).

3. Wait for WLS to fully startup. Look for the string “Server started in RUNNING mode” in the

console window


4. Verify that the admin server is working properly by using a browser to

navigate to the admin console. You should be able to use the URL:

http://localhost:7001/console The username/password is

“weblogic/welcome1”.

5. Verify domain configuration by drilling into the foo_domain -> Environment ->

Servers node on the “Domain Structure” left-hand-navigation. Note that all the

managed servers will be in the “SHUTDOWN” state and that the

AdminServer_foo is in the “RUNNING” state.

http://localhost:7001/console


6. Drill into the “Clusters” selection on the left-hand-navigation and verify cluster

config. Note that there should be two managed servers (MS1 and MS2) mapped

to the cluster app1_cluster.

7. Note the “Change Center” in the upper left corner of the admin console. This

is an important feature for managing WLS. It allows any change that’s made

through the console to be transactional – that is, whatever is done within a

“Lock & Edit” session can be undone. It also keeps multiple administrators

from stepping on each other’s’ toes by acting as a semaphore.


Starting Managed Servers

1. Open a command-window in the directory and change directory to

C:\Oracle\Middleware\user_projects\domains\foo_domain\bin

2. Use the startManagedWebLogic.cmd script to start one of the managed servers:

startManagedWebLogic.cmd MS1 http://localhost:7001

3. Enter the authentication credentials when prompted (weblogic/welcome1)

4. Go to the admin console to make sure it reflects the correct state of that managed server.

5. Start the other managed server on a separate command prompt. Change directory to c:\Oracle\Middleware\user_projects\domains\foo_domain\bin. Run the following command: startManagedWebLogic.cmd MS2 http://localhost:7001

6. Enter the authentication credentials when prompted (weblogic/welcome1).

7. Note that after each managed server starts, a directory with that managed

servers runtime information will be created under the “servers” directory

(in our case:

C:\Oracle\Middleware\user_projects\domains\foo_domain\servers)

8. Ensure that you can see the state of all servers as “RUNNING” in the Admin Console. This

includes the Admin Server and the two managed servers

http://localhost:7001/

http://localhost:7001/


9. Now stop all the managed servers and the Admin server using the Admin console. Click on the “Control” tab

10. Select all three servers by clicking on the checkbox to the left of the server name. From the

“Shutdown” menu, select “Force Shutdown Now”.

11. When the “Server Lifecycle Assistant” is displayed, click the “Yes” button

P a g e | 35

Lesson 3: Eliminating Need to enter Username/Password During

Server Startup

Summary: Prompting to enter the username/password every time to start a server can be tedious. We need ability to start a server automatically via a script or through the WebLogic Nodemanager process. In order to avoid doing this, WebLogic provides users the ability

to store the username/password in an encrypted file called “boot.properties” and hence automate the start-up process. Creating a boot.properties file

1. Stop any running managed servers and Admin server 2. Place the following two lines in a text file: Username weblogic Password welcome1

3. Save the file as boot.properties and locate it in the security directory of the server’s

root directory. C:\Oracle\Middleware\user_projects\domains\foo_doma

in\servers\AdminServer_foo\security

4. Restart the Admin server a. At restart, the server reads the file and then overwrites it with an

encrypted version of the username and password b. Note that you won’t have to enter the username and password for starting the server

any more after you do this. 5. Check out the contents of the boot.properties file after AdminServer_foo has

restarted and you’ll see that the username and password have been encrypted.

6. For every managed server on each host, you’ll need to copy this new security\boot.properties file into that managed server’s directory (you’ll need to create the security directory too).

7. Restart all managed servers using the startup scripts. Verify that you are not prompted for the credentials to start the servers.

P a g e | 36

Lesson 4: WebLogic Nodemanager

Summary:

Server instances in a WebLogic Server production environment are often distributed across multiple domains, machines, and geographic locations. Node Manager is a WebLogic Server utility that enables you to start, shut down, and restart Administration Server and Managed Server instances from a remote location. Although Node Manager is optional, it is recommended if your WebLogic Server environment hosts applications with high availability requirements.

A Node Manager process is not associated with a specific WebLogic domain but with a machine. You can use the same Node Manager process to control server instances in any WebLogic Server domain, as long as the server instances reside on the same machine as the Node Manager process. Node Manager must run on each computer that hosts WebLogic Server instances—whether Administration Server or Managed Server—that you want to control with Node Manager.

Configure a Nodemanager service that can be used to start and stop the Administration server and the Managed Servers. Node Manager must run on each computer that hosts a WebLogic Server instance. Nodemanager Setup:

1. Verify that no managed server instances are running. If they are, stop them by issuing Ctrl-C in the command prompt.

2. Run the Admin Server by running the script “startWebLogic.cmd” from directory c:\oracle\middleware\user_projects\domains\foo_domain This will start the Admin Server

3. Verify that the server has started by looking for the “RUNNING” mode in the console window 4. Using the browser navigate to the admin console by using the URL

http://<hostname>:7001/console. 5. Login to the admin console using credentials “weblogic/welcome1” 6. Navigate to “Environment -> Servers and then click on the “Control” tab

P a g e | 37

7. Click on the checkbox next to the server “MS1” and then click on the “Start” button

Notice that the command failed and there is an error message both on the admin console and the command prompt where the admin server is running. The command failed because Nodemanager service configured on this host

P a g e | 38

Configure a Nodemanager service on this host and issue the same command

Installing Nodemanager service

8. Open a windows command prompt and run the following command to install Node Manager as a Windows Service: C:\Oracle\Middleware\wlserver_10.3\server\bin\installNodeMgrSvc.cmd

9. Verify that it was installed as a service by opening up the “Services” control panel and looking for “Oracle WebLogic NodeManager…” (Start -> Control Panel -> Administrative Tools -> Services)

P a g e | 39

Start the node manager by selecting the “Start” link or the play icon Configuring Nodemanager on localhost

1. Login to the admin console by using a browser and navigating to the URL http://localhost:7001/console. Use weblogic/welcome1 for user credentials

2. Lock & Edit admin session in the Change Centre

3. On the right hand side click on “Domain” under Domain Configurations

Under “Settings for foo_domain”, Click on Security->General and then expand the “Advanced” Tab

http://localhost:7001/console

P a g e | 40

For the fields “Nodemanager Username” and “Nodemanager Password” enter weblogic/welcome1. These credentials will be pulled over by nodemanager when the nodemanager is enrolled with the nmEnroll WLST directive later. These will be the credentials that the admin server uses to authenticate to the nodemanager. Since a nodemanager can manage multiple domains on a single system, different credentials can be specified for each domain

4. Save changes by clicking on the “Save” button on the bottom

Activate the changes in the Change Centre by selecting the “Activate Changes” button

P a g e | 41

Testing Nodemanager

1. In the admin console, navigate to Environment->Machines and select host1 (the name we specified for the machine during domain configuration) Select the “Monitoring” tab at the top – you should be able to see the status “Reachable”. If this isn’t the status, then Nodemanager isn’t communicating properly with the AdminServer_foo.

2. Navigate to Environment->Servers and select the “Control” tab. Select the checkbox next to MS1 and click on the “Start” button. Before we installed the Nodemanager service, this operation had failed. Let us see what happens this time around

When the Server Life Cycle Assistant screen is displayed, click on Yes.

You can select the little turning arrows to have the console auto-refresh 3. Observe the server state transition from “UNKNOWN” or “SHUTDOWN” to “STARTING” and

finally to “RUNNING”.

P a g e | 42

P a g e | 43

Lesson 5: Deploying Applications

Summary:

IT Operators are often required to deploy applications into their WebLogic environments. In this lesson, we will walk you through a typical deployment scenario. A sample application, “whichServer.war”.

This is a simple JSP application which reads session runtime information to tell you which managed server it is being served up from. It also increments an integer and then stores it into the HTTPSession, simulating the storage of state information. The application whichServer.war has been configured to share its session state within the WebLogic cluster. This gives it high application availability and the guarantee that the session information will not be lost if one of the nodes in the cluster goes down.

The session replication is enabled by adding the following parameters to the weblogic.xml file for the webapp:

<session-descriptor>

<persistent-store-type>REPLICATED</persistent-store-type>

</session-descriptor>

Deploying Application:

1. Ensure that the admin server and the managed servers are started by accessing the admin console and going to Environment->Servers. Verify that the state of the admin server and the managed servers MS1 and MS2 is shown as “RUNNING”.

2. Go to the Environment -> Deployments section of the console. 3. Create an admin session by selecting the “Lock & Edit” button in the Change Centre

Select the “Install” button on the right hand side of the screen under “Deployments”

4. Navigate to the folder where whichServer.war resides and select it.

P a g e | 44

Select Next

5. Install this as an application (versus a library)

6. Select “Next”. Then target all servers in the app1_cluster

P a g e | 45

7. Select “Next”, then accept the default values given on the next page

8. Select “Next” then “No, I will review the configuration later”

9. Finally select “Finish”. Activate the changes in the Change Centre by clicking on the Activate

Changes button. The state of the deployment will go from “Distribution Initializing” to “Prepared” You must now activate the application by first selecting the checkbox next to “whichServer”,

P a g e | 46

then selecting the “Start Servicing All Requests” pulldown.

Confirm that you want to activate/start this deployment. You will see the state changed from “Prepared” to “Active” (You may have to refresh your browser).

Testing Deployment

1. Since we deployed the application in the app1_cluster, we can access the web application by navigating to the following URL:

http://localhost:8001/whichServer/whichServer.jsp


2. Now Refresh the page several times (F5) to see the stored value increment



P a g e | 47

P a g e | 48

Lesson 6: Apache Plugin Installation and Testing for Load Balancing, Session Stickiness, Failover and Session Replication Summary: A typical environment for a highly-available clustered deployment of WebLogic Server is depicted below

In Lesson 2, we created a cluster. In Lesson 4, we installed the Nodemanager service. In Lesson 5, we deployed an application to the members of the cluster. In this lesson, we will configure a web server proxy and test our application for load balancing (even distribution of sessions across the nodes of the cluster), session stickiness (sending subsequent requests from a session to the same node), failover (sending the request to an alternate node if the node originally managing the session is not available) and session replication (maintaining session state across the nodes of the cluster, thus making the application highly available). The best way to front-end a WebLogic Server cluster is through a load-balancer of some kind. This way, clients can hit a single endpoint and get load-balanced between all nodes of the cluster. WebLogic Server comes out of the box with plug-ins for Apache, Microsoft IIS, and the Oracle Sun Java WebServer. Apache Plugin is taken as an example in this lesson. Apache Server will be configured to load balance requests across both of the managed servers MS1 and MS2 in the cluster

P a g e | 49

Apache Plug-in Setup

1. Install Apache HTTP Server Accept all the defaults while installing the Apache web server On Windows it normally installs into the directory C:\Program Files\Apache Software Foundation\Apache2.2

2. The apache-weblogic proxy plugin is distributed with WLS 10.3.4 – find it in the

“[MW_HOME]/wlserver_10.3/server/plugin/…” directory Since our VM is a Windows 32-bit machine, choose the Win->32 folder (C:\Oracle\Middleware\wlserver_10.3\server\plugin\win\32)

3. Copy mod_wl_22.so into the directory C:\Program Files\Apache Software Foundation\Apache2.2\modules Edit C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.conf and Add the following lines at the end of the section where are the other LoadModule directives are:

LoadModule weblogic_module modules/mod_wl_22.so <IfModule mod_weblogic.c>

WebLogicCluster localhost:8001,localhost:9001 MatchExpression *

</IfModule>

NOTE: No spaces can exist between the cluster members

4. In the admin console (URL: http://localhost:7001/console weblogic/welcome1) go to the Environment->Clusters and then click on the app1_cluster

5. On the next Screen, click on “Advanced”

P a g e | 50

6. Click on “Lock & Edit” in the change centre

7. Check the “WebLogic Plug-in Enabled” checkbox

Click on “Save” at the bottom of the screen. Since we have to repeat these steps for the managed servers MS1 and MS2, we will not activate our changes now.

8. Click on Environment->Servers and then click on MS1

P a g e | 51

9. Click on the “General” tab under “Settings for MS1” and then click on the “Advanced” button at the bottom. Check the “WebLogic Plug-in Enabled” checkbox

10. Save changes by clicking on the “Save” button at the bottom of the screen

Repeat steps for managed server MS2. Remember to save your changes by clicking on the “Save” button.

11. Activate changes by clicking on the “Activate Changes” button in the Change centre

12. Re-start both the managed servers MS1 and MS2. In the admin console, navigate to Environment->Servers and then on the right hand screen click on “Control”. Select the checkbox next to the managed servers MS1 and MS2

P a g e | 52

13. First click on “Shutdown” and choose “Force shutdown Now”. Select “Yes” on the Service Lifecycle Assistant screen. The state of the two managed servers will change eventually to “SHUTDOWN”.

14. Select the checkbox next to the two managed servers MS1 and MS2. Now click on the “Start” button. Select “Yes” on the Service Lifecycle Assistant screen. The state of the servers will eventually change to “RUNNING”

P a g e | 53

15. Now re-start the Apache service by going to the windows Start Programs and following Programs->Apache HTTP Server 2.2->Control Apache Server->Restart

Now access the application that we deployed previously through the apache web server proxy by using the URL: http://localhost/whichServer/whichServer.jsp. Notice that since the web server is running on port 80, we do not have to specify the port number explicitly.

P a g e | 54

Testing Load Balancing, Session Stickiness, Failover and Session Replication

Since we deployed the application in the app1_cluster, and we have an Apache HTTP server fronting requests for the cluster, we can now test the application for

Load Balancing (even distribution of sessions across the nodes of the cluster),

Session Stickiness (sending subsequent requests from a session to the same node),

Failover (sending the request to an alternate node if the node originally managing the session is not available) and

Session Replication (maintaining session state across the nodes of the cluster, thus making the application highly available).

Step 1 To test load balancing, use your default web browser (Firefox in this example) to access the application by using the URL: http://localhost/whichServer/whichServer.jsp Notice the name of the managed server serving this request, MS1 in our case

Step 2

Now use an alternate web browser (like Internet Explorer or Google Chrome) to access the application by using the same URL: http://localhost/whichServer/whichServer.jsp

http://localhost/whichServer/whichServer.jsp

http://localhost/whichServer/whichServer.jsp

P a g e | 55

Notice that the request has been served by a different managed server in the cluster

Step 3 Now we will test session stickiness, failover and session replication. In order to do that, refresh the page in the first web browser to increase the counter up to a certain value. Notice that this demonstrates session stickiness by having the same managed server handle all subsequent requests

Step 4 Now go to the WebLogic Admin Console and use the Environment -> Servers -> Control tab to shut down the managed server serving the request (MS1 in our example)

After confirming your request, go back to the browser and refresh the page (F5) to see what happens

P a g e | 56

Notice that failover has been demonstrated by having a different server of the cluster serve such request. However, the counter went back to “1”, so the session state is not being maintained. What could be causing this issue?

Step 5 In order to fix it, we need to edit the weblogic.xml file, located on the WEB-INF folder of the whichServer.war file (C:\WLS-Admin-Workshop-Lab\Lab-Material\Lab5- AppDeploy\whichServer.war\WEB-INF\weblogic.xml)

P a g e | 57

Use Notepad to uncomment the <session-descriptor> element by deleting the “” characters before and after the element

Save (Ctrl-S) and close the file, accepting the update dialog after it has been closed

P a g e | 58

Now the application is ready to be redeployed and tested for high availability

Step 6 First, let’s bring the previously shutdown managed server back up by going to the WebLogic Admin Console and using the Environment -> Servers -> Control tab to startup the managed server (MS1 in our example)

Activate the automatic refresh function to ensure the managed server goes back to RUNNING Mode

P a g e | 59

Now let us redeploy the application by going to Edit mode (if not already there) and navigating to the Deployments section of the WLS Admin Console

Select the whichServer application and click “Update”

P a g e | 60

Now activate the changes by clicking the “Activate Changes” button on the Change Centre section of the WLS Admin Console

P a g e | 61

Step 7 Validate that all changes have been applied and the whichServer app state is shown as “Active” on the “Deployments” section

Step 8 Now let’s test the application for session replication (aka high availability). Go back to the whichServer application and refreshing the page several times to increase the number of the counter

P a g e | 62

Now go to the WebLogic Admin Console and use the Environment -> Servers -> Control tab to shut down the managed server serving the request (MS2 in our example)

After confirming your request, go back to the browser and refresh the page (F5) to see what happens

P a g e | 63

Step 9 Notice that the managed server changed but the counter continues from the last value, thus demonstrating that the session is being replicated among the managed servers of the cluster, giving high availability to the application As an optional step, in case you want to test the Load Balancing, Session Stickiness, Failover and Session Replication with an alternate application, you can bring back up all managed servers, deploy and activate the InMemRepClient.war application found in C:\WLS-Admin- Workshop-Lab\Lab-Material\Lab5-AppDeploy\InMemRepClientApp\, and access it thru the URL http://localhost/InMemRepClient/Session.jsp

Stop the managed server and admin server instances either through the admin console (Environment->Servers->Control; select servers and then select “shutdown” and “Force shutdown Now”) or by hitting Ctrl-C in the windows command prompt.

P a g e | 64

Lesson 7: WebLogic Scripting Tool (WLST)

Summary: The WebLogic Scripting Tool (WLST) is a command-line scripting interface that system administrators and operators use to monitor and manage WebLogic Server instances and domains. The WLST scripting environment is based on the Java scripting interpreter, Jython. WLST lets you perform the following tasks:

Propagate a WebLogic Server domain to multiple destinations using predefined configuration and extension templates.

Retrieve domain configuration and runtime information.

Edit the domain configuration and persist the changes in the domain's configuration files.

Edit custom, user-created MBeans and non-WebLogic Server MBeans, such as WebLogic Integration Server and WebLogic Portal Server MBeans.

Automate domain configuration tasks and application deployment.

Control and manage the server life cycle.

Access the Node Manager and start, stop, and suspend server instances remotely or locally, without requiring the presence of a running Administration Server. In this lesson, a brief introduction to the WebLogic Scripting Tool (WLST) will be provided

Activity Steps:

1. Stop all running admin server and managed server instances.

2. From windows command prompt and change directories to c:\oracle\middleware\user_projects\domains\wls_domain.

3. Run the startWebLogic.cmd script.

4. Verify that the server is running by looking for the “RUNNING” mode in the command

prompt.

5. Using a browser navigate to the URL http://localhost:7001/console in order to access the admin console.

6. User the user credentials “weblogic/welcome1” to login to the console.

Running WLST:

P a g e | 65

Step 1 There are different ways to start the WLST tool. One way is to run the tool from the Windows Start Menu as shown

The other way is to start a windows command prompt and run the tool from the command line. In our installation, the tool resides at c:\oracle\middleware\wlserver_10.3\common\bin\wlst.cmd

Step 2

Using either steps, run the wlst tool. The tool starts in offline mode as shown below.

Offline mode means that the tool is not connected to a running server. In this mode, one can create domains, change configuration elements and build templates for domains.

Step 3 Connect to a running domain to see the “Online” mode of WLST. To do this, use the connect() command: connect('weblogic','welcome1','t3://localhost:7001')

P a g e | 66

Step 4 Basic UNIX-style commands are available here, such as pwd(), ls(), and cd(). Run “ls()” to see what is located in the base of the server hierarchy. Note the left side column, which indicates whether the item is akin to a “directory”, which allows you to use cd(‘the item’) to change your location within the tree.

Type exit() to exit out of the wlst command prompt.

P a g e | 67

Automatic Script Recording Step 1 Users often build wlst scripts from scratch or leverage existing samples that are available with the WebLogic distribution. Another way to create scripts that we’ll show here is to “Record” them from the WLS console and then leverage them to automate your processes. In this activity we will illustrate this use with a simple example In the admin console, locate the Change Center at the top left and lock the console for editing

Step2

Now click the Script Recording button that is shown at the top of the admin console to start the recording. The console will show you where it is placing the script you will record.

P a g e | 68

Step 3 Here we will make a change to the server’s configuration and see the resulting script. First, open Environments -> Servers, then click on AdminServer. Once up, find the “Notes” tab and type something in the box and save it. The following screen shots show this.

P a g e | 69

Click on the “Save” button to save your changes. Now click on the “Record” button again to stop the recording. Now let us go to the directory where the script has been saved which is C:\Oracle\Middleware\user_projects\domains\wls_domain Open the script in an editor to see what was recorded.

Step 4 You will see that it recorded the directory within the configuration tree and the command it ran to change the Note field. Now open the following files in the folder: C:\WLS-Admin-Workshop-Lab\Lab-Material\Lab7- WLST\WLS_ServerNote.py C:\WLS-Admin-Workshop-Lab\Lab-Material\Lab7- WLST\note.properties

P a g e | 70

In the WLS_ServerNote.py script, we have parameterized the value, as well as the connection string so that we can easily make changes without having to create or modify existing scripts. Open a command prompt and cd to C:\WLS-Admin-Workshop-Lab\Lab- Material\Lab7-WLST

Step 5

Run the WLS_ServerNote.py script using the following command: wlst.cmd WLS_ServerNote.py

Look for the activation completed message when the script finishes

Step 6 Back in the WLS admin console, navigate to Environment->Servers, then click on “Admin Server” and then on the “Notes” tab. You will notice that server’s Notes field has been changed to a new value.

P a g e | 71

Domain Configuration using WLST Step1 In the admin console go to Environment->Deployments and notice that no application has been deployed.

Step 2

Go to Environment->Services and expand the services tree. Click on “Data Sources” and notice

that no data sources have been configured

Step 3 Run some pre written scripts that will automate the process of creating a Data Source as well as deploy an application. Now run the command: wlst.cmd WLS_Deploy.py. This script will deploy an application You can verify this by going to the admin console and navigating to Environment->Deployments. You will see an application listed here that was not there previously.

P a g e | 72

Step 4 Run the WLS_JDBC.py script to create a JDBC data source and verify that it has been created via the admin console. The WebLogic installation provides sample WLST scripts that users can leverage to build their own scripts and automate their deployment process. These scripts allow you to configure a cluster as well as create JMS connection factories, queues and topics. You can find these samples at C:\Oracle\Middleware\wlserver_10.3\samples\server\examples\src\ex amples\wlst\online

P a g e | 73

Lab 8: JRockit Mission Control (JRMC)

Summary: Oracle JRockit Mission Control (JRMC) is a suite of tools for managing, monitoring, profiling, and troubleshooting your Java applications. JRockit Mission Control consists of the Management Console, the JRockit Runtime Analyzer and the Memory Leak Detector. JRMC will be used to analyze the memoryHog application JRockit Mission Control is installed in the folder “C:\Program Files\Java\jrockit- jdk1.6.0_20-R28.1.0-4.0.1” Starting JRMC:

Step 1 Start JRMC and the console will automatically detect the JVMs on the local system(both Jrockit and non-Jrockit JVMs)

Step 2

In order to monitor a MemoryHog application, select it in the pick list of Local JVMs. Then right click and select the “Start Console” button.

P a g e | 74

Step 3 You will now see the General view in the main dashboard for the application – explore the memory and CPU statistics and note the shark-tooth pattern in memory consumption due to Garbage Collections (GCs):

Step 4

Explore the other views in the main console such as the MBeans, Runtime, and Advanced:

P a g e | 75

In the MBeans view, triggers can be setup to create actions (such as sending an email) on specified conditions (such as the Live Set memory being too high).

In the Runtime view, the tabs on the bottom of the screen allow one to explore the System usage and information, Memory information such as GC pauses and algorithm. Thread information is also available to look at information about all the live threads running in the JVM.

In the Advanced view, the tabs at the bottom enable access to the Method Profiler, Exception Counter, and access to Diagnostic Commands that may be available in the JVM.

Step 5 Use the JRMC Memory Leak Detector. Select the memory leak tool icon in the top of the JVM Browser as shown below:

Step 6 A new tab will be opened and the Trend Analysis screen will first come up so you can see which object allocations are growing in the heap

P a g e | 76

Step 7 By right-clicking on the biggest object type (in this case the char[] array) and selecting “Add to Type Graph” you can see what’s creating the objects and holding onto them

Step 8

Click on the little plus sign in the char[] array to see which objects created the char arrays The Type Graph will now show that there are hundreds of thousands of Strings in the character arrays. Note that the type graph will colour code the object types that are the largest – the java.lang.String is in red along with char[].

P a g e | 77

Now, hit the plus sign to expand the java.lang.String object to see which objects are holding onto the Strings

Example: We can now easily see that our code, com.oracle.memoryhog.MemoryHog has an inner class called DataClass which is holding onto all the Strings. We’ve found the culprit that’s causing the leak! Eventually, after about 129 Loops, you will see the JVM Runtime Exception in the MemoryHog command window when the application uses all of the 500MB of RAM it was allocated: Exception in thread "Main Thread" java.lang.OutOfMemoryError At this point, JRMC will lose the connection to the JVM and the “Connection Lost” messages will be seen

P a g e | 78

JRockit Flight Recorder

Step 1 It is often desirable to see what is going on in the JVM for later-analysis

You will now be able to see the status of the recording in the lower-right corner of JRMC

Once the recording is completed, the flightRecording[uniq_id].jfr file will be opened for analysis of that minute during the recording:

P a g e | 79

Step 2

Explore the main tabs on the left to see what was going on in the application.

Step 3 Going to the Memory -> Allocation tab shows that the char[] array is huge and that the allocations came from the methods outlined in the bottom of the window – originating at the method com.oracle.memoryhog.MemoryHog.comsumeRAM() – Hmmm, sounds fishy! ;)

These recordings are great ways to communicate with others in the organization about what is going on with production applications. If you notice, the size of the flight recording is also quite small – a one minute recording is only 80KB

Documents

Oracle WebLogic Server 11g for IT OPS