Taking weblogic thread dumps

Thread Dump will be printed to the servers standard out (by default, the shell in which the server
is running)
On Windows machine:
cltr + break
On Unix Machine:
get pid using ps -ef grep java
kill -3 (process id)
When weblogic is running as windows service
For Out file add in JAVA_OPTIONS:
-Dweblogic.Stdout=
Using beasvc :
beasvc dump svcname:bea Admin_server
Using Weblogic Admin utility
C:\bea\user_projects\domains\rDomain>java weblogic.Admin -url t3://localhost:7001
-username weblogic -password weblogic THREAD_DUMP
Collecting thread dumps from the console:
Server > Monitoring > Threads > Dump Thread Stacks
Using WLST:
java weblogic.WLST
connect("weblogic","weblogic","t3:\\localhost:7001")
threadDump()

Script to take thread dump prstat and pstack.

#
# Takes an argument (PID of the WLS process) and loops three times.
# This will append the prstat information to a file called dump_high_cpu.txt.
# The thread dump information will either be in file where stdout was redirected or
printed on the screen.
#

if test $# -eq 0
then
echo "usage: $0 <processID>";
else

for loopnum in 1 2 3
do
echo `date`
CURDATIME=`date '+%y%m%d_%H%M%S'`
echo $CURDATIME
prstat -L -p $1 1 1 >> ~/export/home/username/`hostname`_$
{CURDATIME}_$1.out
pstack $1 >> ~/export/home/username/`hostname`_$
{CURDATIME}_$1.out
kill -3 $1
echo "prstat, pstack, and thread dump done. #" $loopnum
sleep 1
echo "Done sleeping."
done
fi

Thread states are R - Runnable, S - Suspended, CWConditional Wait, MW - Monitor wait.

Tools to analyze thread dumps (downloads)

1. Samurai

2. Thread dump analyzer.

We need to look into quite a few parameters from the collected dump information. From prstat
output we can get the LWP numbes and the corresponding cpu utilization of all of them.
We can convert the LWP number from prstat to nid (hexadecimal value by using nawk or
something similar)
From the thread dump we can see the nid and look into the stack trace.
In pstack output we can see the native stack of the lwp (from prstat output) or search for the tid
from the thread dump. From the corresponding stack, look for the program counter number and
map it to pmap output.

Nodemanager
Nodemanager is used to remotely start, stop and restart weblogic managed servers
remotely.

Nodemanager configuration files will be location in common/nodemanager

Nodemanager configuration file
<server_name>/data/nodemanager/startup.properties

Nodemanager configuration:
nodemanager.properties is created in the directory where you start Node Manager the first time
you start Node Manager after installation of WebLogic Server. Each time you start Node
Manager, it looks for nodemanager.properties in the current directory, and creates the file if it
does not exist in that directory.
Start the nodemanager using startNodeManager.cmd (sh) in your server/bin directory.
Configure machines and fill in the server start tab in the Admin console with necessary
information.
Now you can remotely start and stop servers using Admin console/WLST
When we start manager it give all the configuration information on the screen as below:
Configuration settings:

NodeManagerHome=D:\bea\WLSERV~1.3\common\NODEMA~1
ListenAddress=
ListenPort=5556
ListenBacklog=50
SecureListener=true
AuthenticationEnabled=true
NativeVersionEnabled=true
CrashRecoveryEnabled=false
JavaHome=d:\bea\JROCKI~2\jre
StartScriptEnabled=false
StopScriptEnabled=false
StartScriptName=startWebLogic.cmd
StopScriptName=
LogFile=D:\bea\WLSERV~1.3\common\NODEMA~1\nodemanager.log
LogLevel=INFO
LogLimit=0
LogCount=1
LogAppend=true
LogToStderr=true
LogFormatter=weblogic.nodemanager.server.LogFormatter
DomainsFile=D:\bea\WLSERV~1.3\common\NODEMA~1\nodemanager.domains
DomainsFileEnabled=true
StateCheckInterval=500
Domain name mappings:
wl_server -> D:\bea\wlserver_10.3\samples\domains\wl_server
lab -> d:\bea\user_projects\domains\lab
medrec -> D:\bea\wlserver_10.3\samples\domains\medrec
Under data/nodemanager (Example,
C:\bea\user_projects\domains\new_domain\servers\new_ManagedServer_1\data\nodemanager)
we can see startup.properties file for nodemanager. The boot.properties file is also copied here.
The nm_password.properties is located under Domain_Home\config\nodemanager
Under the monitoring tab of each machine, we can check if node manager is reachable of not.
Else we can enroll nodemanager and this copies all security information to each managed server.
Also file called new_ManagedServer_1.state,.lck, .pid etc., are created under the
data/nodemanager of each managed server.

Summary:
nodemanager.properties
This is the configuration file used by the Java-based version of Node Manager.
This file is located in WL_HOME/common/nodemanager.
nodemanager.hosts
This file contains a list of all the trusted hosts that can issue commands to Node Manager.
This file is located in WL_HOME/common/nodemanager.
nodemanager.domains
This file contains mappings between the names of domains managed by Node Manager and their
corresponding directories.
This file is located in WL_HOME/common/nodemanager.
nm_data.properties
This file stores the encryption data the Node Manager uses a symmetric encryption key. The data
is stored in encrypted form.
This file is located in WL_HOME/common/nodemanager.
nm_password.properties
This file stores a username/password pair specific to the Node Manager server that is managing
this domain. This is known as the Node Manager secret. The username and password are
appended to a salt value (obtained from the SerializedSystemIni.dat of the domain) and SHAhashed.
This file is located in DOMAIN_HOME/config/nodemanager.
boot.properties
Node Manager uses this file to specify a boot identity when starting a server. This file is located
in domain-name/servers/server_name/data/nodemanager.
startup.properties

Each Managed Server instance has its own startup.properties file with properties that control how
Node Manager starts up and controls the server. Node Manager automatically creates this file by
using properties passed to Node Manager when the Administrative Server was last used to start
the server. This allows a Node Manager client or startup scripts to restart a Managed Server using
the same properties last used by the Administrative Server.
These properties correspond to the server startup attributes contained in ServerStartMBean and
the health monitoring attributes in ServerStartMBean.
This file is located in domain-name/servers/server_name/data/nodemanager.
server_name.addr
server_name.addr stores the IP address added when a server starts or is migrated. This file is
generated after the server IP address is successfully brought online during migration.
server_name.addr is deleted when the IP address is brought offline. The server IP address is used
to validate remove requests to prevent addresses being erroneously removed while shutting down
the server.
This file is located in domain-name/servers/server_name/data/nodemanager.
server_name.lck
server_name.lck is generated by each server and contains an internally used lock ID.
This file is located in domain-name/servers/server_name/data/nodemanager
server_name.pid
server_name.pid is generated by each server and contains the process ID of the server. Node
Manager checks the process ID generated by the server during crash recovery.
This file is located in domain-name/servers/server_name/data/nodemanager
server_name.state
server_name.state is generated by the server and contains the server's current state. Node
Manager monitors the contents of this file to determine the current state of the server.
Note: Do not delete or alter this file. Without this file Node Manager cannot determine the
current state of the server.

This file is located in domain-name/servers/server_name/data/nodemanager.

The nm_password.properties file contains the Node Manager username and password. These are
used to authenticate connection between a client (for example, the Administration Server) and
Node Manager. This username and password are only used to authenticate connections between
Node Manager and clients.
The nodemanager.domains file specifies the domains that a Node Manager instance controls.
When we add new machine to a node manager we need to use the following command to register
the node manager.
nmEnroll('C:/bea/user_projects/domains/prod_domain',
'C:/bea/wlserver_10.0/common/nodemanager')
Running nmEnroll() ensures that the correct Node Manager user and password token are
supplied to each Managed Server. Once these are available for each Managed Server, you can
use nmConnect() in a production environment.
If Nmenroll failes for some reason, we need to copy SerializedsystemIni.dat and
nm_password.properties from Admin server to the new remote server. Additionally we can add
the domain name in nodemanager.domains file.

Starup and Shutdown :

There are different ways to start and stop weblogic server.

1. Through scripts
2. Through Admin console or WLST / weblogic.Admin using nodemanager.
Through scripts:
startWebLogic.cmd is the script used to start the JVM with the necessary options. Its location in
the DOMAIN_HOME\bin directory. This script without options will start the admin server.
startManagedWebLogic.cmd/sh is used to start managed server.
Example: startManagedWebLogic.cmd/sh managedserver1 http://localhost:7001

Similarly stopManagedWebLogic.cmd/sh and stopWebLogic.cmd/sh are used to stop weblogic

servers. The scripts use WLST python scrpt.

Session Persistence:
There are five different implementations of session persistence:

Memory (single-server, non-replicated)

File system persistence

JDBC persistence

Cookie-based session persistence

In-memory replication (across a cluster)

These attributes are part of the session-param element, which is a child element of the sessiondescriptor element in the weblogic.xml deployment descriptor file. We can get more detail about
weblogic deployment descriptor in Oracle's documentation.
Enabling Session Persistence:
Set the persistent-store-type parameter in the session-descriptor element in the weblogic.xml
deployment descriptor file to memory.
Enabling File system persistence:
In the deployment descriptor file weblogic.xml, set the persistent-store-type parameter in the
session-descriptor element in the weblogic.xml deployment descriptor file to file.
Create the necessary file store.
Enabling JDBC persistence
Set the persistent-store-type parameter in the session-descriptor element in the weblogic.xml
deployment descriptor file to jdbc
Set a JDBC connection pool to be used for persistence storage with the persistent-storepool parameter in the session-descriptor element in the weblogic.xml deployment descriptor file
Create JDBC datasource and tables in database.

Enabling Cookie-based session persistence.

Set the persistent-store-type parameter in the session-descriptor element in the weblogic.xml
deployment descriptor file to cookie.
Jdbc :

We can use Administration Console or the WebLogic Scripting Tool (WLST) to create and
deploy (target) JDBC modules. They can be manged using JMX
Using weblogic console : http://sureshsvn.com/creatingjdbcconnectionpool.html
DB Ping command:
java -classpath /bea103/wl_server103/server/lib/weblogic.jar utils.dbping ORACLE_THIN
<dbUserName> <dbPasswoes> <dbURL>
JDBC Drivers :
The JDBC API defines the Java interfaces and classes that programmers use to
connect to databases and send queries. A JDBC driver implements these interfaces
and classes for a particular DBMS vendor.
The Oracle JDBC Thin driver is a JDBC Type 4 driver(written entirely in Java).
JDBC OCI client-side driver (OCI driver):
Oracle's JDBC OCI driver provides a JDBC Type 2 driver (native-API, partly Java)
implementation of the JDBC interfaces using OCI (Oracle Call Interface) to interact
with an Oracle database
JDBC server-side Internal driver (KPRB driver):
This JDBC Type 2 driver can be used by Java code that runs inside the oracle
database server JVM, such as Java stored procedures
DBC Thin server-side driver:
This JDBC Type 4 driver allows Java program running inside an Oracle database
server JVM to access remote databases.
BC Version JDK version**

JDBC File Name

11.2.0

1.6.x
1.5.x

ojdbc6.jar
ojdbc5.jar

11.1.0

1.6.x
1.5.x

ojdbc6.jar
ojdbc5.jar

10.2.0

1.2.x
1.3.x
1.4.x
1.5.x

classes12.jar
classes12.jar
ojdbc14.jar
ojdbc14.jar

10.1.0

1.2.x
1.3.x
1.4.x

classes12.jar
classes12.jar
ojdbc14.jar

9.2.0

1.1.x
1.2.x
1.3.x
1.4.x

classes111.zip*
classes12.zip*
classes12.zip*
ojdbc14.jar

Drivers

Oracle database

11.2.0

11.2.0
11.1.0
10.2.0
10.1.0
9.2.0

11.1.0

11.2.0
11.1.0
10.2.0
10.1.0
9.2.0

10.2.0

11.2.0
11.1.0
10.2.0
10.1.0
9.2.0

10.1

11.2.0
11.1.0
10.2.0
10.1.0
9.2.0

9.2.0

11.2.0
11.1.0
10.2.0
10.1.0
9.2.0

In terms of datasources, an XA datasource is a data source that can participate in an XA global

transaction. A non-XA datasource generally can't participate in a global transaction (sort of some people implement what's called a "last participant" optimization that can let you do this for
exactly one non-XA item).
Most of the dirvers are non XA. The Transaction Manager coordinates all of this through a
protocol called Two Phase Commit (2PC). This protocol also has to be supported by the
individual resources.
Thin driver

Oracle's JDBC Thin driver uses Java sockets to connect directly to Oracle. It provides its
own TCP/IP version of Oracle's SQL*Net protocol. Because it is 100% Java, this driver is
platform independent and can also run from a Web Browser (applets).
Logging Last Resource is recommended over Emulate Two-Phase Commit

Domain Creation :
We can create weblogic server domain using domain configuration wizard, weblogic.Server
command, weblogic.Admin command and WLST.
Using weblogic.Server command:
java -Dweblogic.Domain=SimpleDomain -Dweblogic.Name=SimpleServer
-Dweblogic.management.username=weblogic
-Dweblogic.management.password=weblogic -Dweblogic.ListenPort=7001
weblogic.Server

Using Configuration Wizard:

Refer http://sureshsvn.com/creating_weblogic_domain_windows.html
Using weblogic.Admin: (
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/admin_ref/cli_tasks.html)

Create skeletal domain with the java weblogic.Server command and Using CREATE -mbean
argument to create different mbeans.
Using WLST: (
http://download.oracle.com/docs/cd/E11035_01/wls100/config_scripting/domains.html )
WLST enables you to create a new domain or update an existing domain without connecting to a
running WebLogic Server (that is, using WLST offline)supporting the same functionality as
the Configuration Wizard.
createDomain(domainTemplate, domainDir, user, password)
ls:/offline> createDomain('c:/bea/wlserver_10.0/common/templates/domains
/wls_medrec.jar','c:/bea/user_projects/domains/medrec', 'weblogic',
'weblogic')
Domain teamplates can be build using

config_builder in common /bin directory

Weblogic.Admin:
Usage: java [<SSL trust options>] weblogic.Admin [ [-url | -adminurl]
[<protocol>://]<listen-address>:<port>]
-username <username> [-password <password>]<COMMAND> <ARGUMENTS>

To list all the available commands: java weblogic.Admin help ALL

Managing the Server Life Cycle

UNLOCK
RESUME [<targetServer>]
FORCESHUTDOWN [<targetServer>]
SHUTDOWN [-ignoreExistingSessions] [-timeout <seconds>] [<targetServer>]
OR
(Deprecated) SHUTDOWN [<seconds> ["<stringMessage>"]] [<targetServer>]
LOCK ["<stringMessage>"]
START <targetServer>
(Deprecated) STARTINSTANDBY <targetServer>
DISCOVERMANAGEDSERVER [-serverName <targetServer> [-listenPort <listenport>] [listenAddress <listen address>] [-listenPortSecure]]

Retrieving Information about WebLogic Server

GETSTATE [<targetServer>]
HELP [<COMMAND>]
CONNECT [<count>]
LICENSES
LIST [<JNDIcontextName>]
PING [<roundTrips>] [<messageLength>]
THREAD_DUMP
VERSION
SERVERLOG [<startTime> [<endTime>]]
Working with JDBC Connection Pools
SUSPEND_POOL -poolName <connection pool name>
(Deprecated) DISABLE_POOL <poolName> [true | false]
RESET_POOL <poolName>
CREATE_POOL <poolName> <poolString>
(Deprecated) DESTROY_POOL <poolName> [true | false]
SHUTDOWN_POOL -poolName <connection pool name>
RESUME_POOL -poolName <connection pool name>
TEST_POOL <poolName>
EXISTS_POOL <poolName>
(Deprecated) ENABLE_POOL <poolName>
DELETE_POOL -poolName <connection pool name>
Managing WebLogic Server MBeans
GET [-pretty] {-type <mbeanType>|-mbean <objectName>} [-property <property>]...
CREATE {-name <name> -type <mbeanType>} | {-mbean <objectName>}
INVOKE {-type <mbeanType>|-mbean <objectName>} -method <methodName>
[<argument>...]
BATCHUPDATE -batchFile <fileLocation> [-continueOnError] [-batchCmdVerbose]
DELETE {-type <mbeanType> | -mbean <objectName>}
QUERY [-pretty] -pattern <objectName_pattern>
SET {-type <mbeanType>|-mbean <objectName>} [-property <property> [<value>]]...
We can create servers, clusters etc., using this option. To get list of MBeans:
java weblogic.Admin -username weblogic -password weblogic -url adminurl query -pretty
-pattern *:*

Working with Clusters

VALIDATECLUSTERCONFIG -configPath <pathname>
MIGRATEALL -server <servername> -destination <servername> [-sourcedown] [destinationdown]
CLUSTERSTATE -clusterName <clusterName>
STOPCLUSTER -clusterName <clusterName>
MIGRATESERVER -migratableserver <servername> -destinationmachine <machinename>
MIGRATE [-jta] -migratabletarget {<migratabletargetName> | <servername>} -destination
<servername> [-sourcedown] [-destinationdown]
STARTCLUSTER -clusterName <clusterName>
Managing the Admin Configuration
STOREUSERCONFIG -username <user> -password <password> [-userconfigfile <file>] [userkeyfile <file>]
Weblogic.Deployer:
Weblogic.Deployer is a Java-based deployment tool that provides a command-line
interface to the WebLogic Server deployment API
Usage: java weblogic.Deployer [options] [action] [Deployment units(s)]
java weblogic.Deployer -help to display all the available options

Deploy application on admin server:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -deploy c:/myapps/myapp.ear
Deploy individual modules in application to different targets:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -targets mywar@webserver,myjar@ejbserver -deploy
c:/myapps/myapp.ear
Undeploy application from specified targets:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -undeploy -targets server1,server2..
Redeploy application on current targets:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -redeploy
Redeploy individual module in an application:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -redeploy -targets moduleA@serverA,moduleA@serverB
Partially redeploy, for example, to update a JSP in a exploded webapp:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -redeploy mywar/index.jsp
The path of JSP to be updated is relative to the root of the application. If a directory
is specified the entire subtree is updated.
Multiple servers sharing the same physical deployment:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -targets server1,server2 -nostage -deploy c:/myapps/myapp.ear
The -nostage option indicates that the application is available on all target servers
at the same path and hence server should not copy files to the managed servers.
Deploy the first application version on admin server:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -deploy c:/myapps/myapp_v1.ear
Perform Production Redeployment of a new application version on admin server:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -redeploy -source c:/myapps/myapp_v2.ear
Deploy application to administration mode on admin server:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -deploy c:/myapps/myapp.ear -adminmode
Transition application from administration mode to running on admin server:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -start
Transition application from running to administration mode on admin server:
java weblogic.Deployer -adminurl url -username username -password password
-name myapp -stop -adminmode
Deploy a library on admin server:
java weblogic.Deployer -adminurl url -username username -password password
-name mylib -library -libspecver 1.0 -libimplver 2.0 -deploy c:/myapps/mylib.jar
Deploy an application on admin server with a deployment plan:
java weblogic.Deployer -adminurl url -username username -password password
-plan c:/myapps/myapp/plan/plan.xml -deploy c:/myapps/myapp/app/myapp.jar
Update an application configuration:
java weblogic.Deployer -adminurl url -username username -password password
-plan c:/myapps/myapp/plan/newplan.xml -name myapp -update
Deploy a queue to a specific JMS server
java weblogic.Deployer -adminurl url -username username -password password
-submoduletargets myqueue@myjmsmodule@JMSServer
-deploy c:/myapps/myapp/app/myapp.ear

weblogic.Server :
Syntax

The syntax for invoking weblogic.Server is as follows:

java [options] weblogic.Server [-help]

The java weblogic.Server -help command returns a list of frequently used options.

JMS:
The main components of JMS in weblogic are JMS servers, Store and Forward agents,
JMS Modules and Bridges
JMS Servers:
Management containers for JMS queue and topic destinations in JMS Modules that
are targetted to them. They provide persistence. They can be targetted to weblogic
servers.
Store and Forward Agents:
To send messages to remote subsystems. They have a capability to store the
messages and send them to the remote system when the remote system is not
available
JMS Modules:
They host and store information about several jms resouces such as connection
factory,queue,topic,DD,foriegn server etc.,
Persistent Store:

A persistent store is a physical repository for storing subsystem data, such as persistent JMS
messages. It can be either a JDBC-accessible database or a disk-based file. We can target
Persisent stores to both Admin and managed servers.

JMS Resource

Valid Targets

Queue

JMS server

Topic

JMS server

Connection factory

JMS server(s) | server

instance(s) | cluster

Uniform distributed
queue

JMS server(s) | server

instance(s) | cluster

JMS Resource

Valid Targets

Uniform distributed
topic

JMS server(s) | server

instance(s) | cluster

Foreign server

JMS server(s) | server

instance(s) | cluster

SAF imported
destinations

SAF Agent(s) | server

instance(s) | cluster

configuration files :

config.xml
DefaultAuthenticatorInit.ldift, DefaultRoleMapperInit.ldift, and SerializedSystemIni.dat, which
store basic security-related data.
boot.properties file, which contains the username and password in an encrypted format. This file
enables you to bypass the prompt for username and password when you start the server.

Weblogic Clustering:
A cluster defines groups of WebLogic Server servers that work together to increase
scalability and reliability.

Communications that happens in cluster:

Peer to Peer using sockets: For accessing nonclustered objects deployed to another clusterened
instance on a different machine.
Replicating http session states and stateful session EJB states between primary and secondary
server instance, accessing remote objects etc.
Peer to Peer using Unicast or Multicast: Used for cluster wide JDNI updates and heartbeats.
Performance Tuning:
Java Parameters

For higher performance throughput, set the minimum java heap size equal to the maximum heap
size. For example:
"%JAVA_HOME%\bin\java" -server Xms512m Xmx512m -classpath %CLASSPATH% Configuring On-Demand Deployment

To change the InternalAppsDeployOnDemandEnabled attribute using the Administration

Console, perform the following steps:
Start an edit session with the Lock and Edit button.
Select the domain to bring up the Configuration -> General tab.
Change the setting of the Enable on-demand deployment of internal applications check box.
Click Save and then click Activate Changes to activate the changes that will take effect at the
next restart of WLS.
Configuring On-Demand Deployment Using WLST
To change the InternalAppsDeployOnDemandEnabled attribute using the WLST, perform the
following steps:
connect()
edit()
startEdit()
cmo.setInternalAppsDeployOnDemandEnabled(false)
activate()
Tuning Muxers

With native muxers, you may be able to improve throughput for some cpu-bound applications
(for example, SpecJAppServer) by using the following:
-Dweblogic.socket.SocketMuxer.DELAY_POLL_WAKEUP=xx
Limiting Requests in the Thread Pool
Throttle the thread pool by setting the Shared Capacity For Work Managers field in the
Administration Console
Limiting HTTP Sessions

An administrator can limit the number of active HTTP sessions based on detection of a low
memory condition. This is useful in avoiding out of memory exceptions.
<session-descriptor>
<max-in-memory-sessions>12</max-in-memory-sessions>
</session-descriptor>

Tune connection backlog buffering

Modify the Accept Backlog value as necessary to tune the number of TCP connections the
server instance can buffer in the wait queue.

If many connections are dropped or refused at the client, and no other error
messages are on the server, the Accept Backlog value might be set too low.

If you are getting connection refused messages when you try to access
WebLogic Server, raise the Accept Backlog value from the default by 25
percent. Continue increasing the value by 25 percent until the messages
cease to appear.

Setting Your Compiler Options

You may improve performance by tuning your servers compiler options.

Tuning JDBC:
Tune the Number of Database Connections

A straightforward and easy way to boost performance of JDBC in WebLogic Server applications
is to set the value of Initial Capacity equal to the value for Maximum Capacity when configuring
connection pools in your data source
Use Test Connections on Reserve with Care

Test Frequency is the tunable parameter that allows us to define the number of seconds between
each time weblogic server tests unused connections.
Cache Prepared and Callable Statements

Use Statement Cache to cache statements. We can enable this under connection pool parameters
of JDBC
PinnedToThread
PinnedToThread is an option that can improve performance by enabling execute threads to keep
a pooled database connection even after the application closes the logical connection
The weblogic-cmp-jar.xml fileis WebLogic-specific XML Schema-based (XSD) deployment
descriptor file. Use these definitions to create the WebLogic-specific weblogic-cmp-jar.xml file

that is part of your EJB deployment. Use this deployment descriptor file to specify containermanaged-persistence (CMP) behavior.
Set cluster-invalidation-disabled to disable cluster invalidation.
Increase the number of CPUs only if CPU untilizaion is reaching high levels. Otherwise consider
increasing network and disk bandwidth etc.,
Tuning Chunk Size:
Weblogic JVM divides network data into 4 chunks by default. For network intensive applications
tuning chunk size can sometimes double thoroughput. The chunk size is set via command link in
server and client.
-Dweblogic.chunksize=n
Default is 4 Kb.
Weblogic caches chunks in an internal chunkpool for reuse.
-Dweblogic.utils.io.chunkpoolsize=n.
Default is 512
Using file stores gives more performance over JDBC persistance stores.

Avoiding JVM Delays Caused by Random Number

Generation
Do head -n 1 /dev/random. It it takes more time then change the valute to"
securerandom.source=file:/dev/urandom" in
$JAVA_HOME/jre/lib/security/java.security

Proxy plugin for Apache:

Copy the mod_wl_20.so file from the BEA_HOME\server\plugin\win\32 directory to
the APACHE_HOME\modules directory

Include the weblogic Module and customize according to your needs.

IfModule mod_weblogic.c>
WebLogicCluster node1:node1_port,node2:node2_port

DebugConfigInfo ON
MatchExpression *.jsp
MatchExpression *.xyz
</IfModule>
Official Documentation:

Plugin options:
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/plugins/plugin_params.html#115801
0

SSL Configuration on WebLogic Server 9.2 on solaris

Generate private Key : (Identity Key)

keytool -genkey -keyalg RSA -alias privkey -keystore yourdomain-private.jks
Generate CSR certificate :
keytool -certreq -v -alias privkey -keystore yourdomain-private.jks
Send CSR certificate to the SSL Vendor.
The Server certificate, Root CA, Intermediate certificate and CA Chain certificate will be sent to
you.
Combine three certificates into one certificate in the same order as below :
Public.cert (Server Certificate we received in the name of number.crt)
Intermediate.cert(Intermediate Certificate)
Root.cert ( Root CA Certificate)
Save these three certificates into one file yourdomain.crt
Import yourdomain.crt file into yourdomain-private.jks
keytool -import -alias privkey -file yourdomain.crt -keystore yourdomain-private.jks -trustcacerts
keytool -list -v -keystore yourdomain-private.jks (To check the certificate is imported properly or
not)

Import Trust identity (Trusted Root certificate)

keytool -import -alias yourdomain -file RootCA.crt -keystore yourdomaintrust.jks -trustcacerts
keytool -list -v -keystore yourdomaintrust.jks ( To check the certificate is imported properly or
not)
Login to WebLogic console
Goto Environment and select Servers - (Example Server1).
Click on KeyStores Tab.
Debugging:
Under the debug tab of servers in Admin console all the debug parameters are
available. We can select which ever one we need.

Dweblogic.Debug is the debug parameter that can be added while weblogic server starts using
startup scripts, WLST tools,
Through WLST:

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCJTA','true')
save()
activate()

Through command line / startup Scripts:

Set the appropriate properties on the command line. For example,
-Dweblogic.debug.DebugJDBCJTA=true
-Dweblogic.log.StdoutSeverity="Debug"
Through editing config.xml
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jdbcjta>true</debug-jdbcjta>
</server-debug>
</server>

Weblogic Deployment Plan

Its used to export the deployment configuration parameters into an xml and use the same xml file
to deploy the code in multiple environments making few changes to the parameters without
needing to edit them in the EAR file descriptors or Admin console.
weblogic.PlanGenerator is the utility that can be used to create a deployment plan.
Syntax:
java weblogic.PlanGenerator [options] [path to application]
options include :
-plan : Name of the plan
-dependencies : export all dependency properties that resolve external resource references
(defaultl)

-declarations: export all properties that delcare a resource to other applications and modules.
-configurables : export all editable configurables except dependencies and declarations
-dynamics: export all configurables that be changed on the fly, without needing to redeploy the
application.
-all : export all changable parameters
While deploying the application using the weblogic.Deployer utility we need to use -plan
/pathto_xml_plan to deploy using plan.
WLST
Its a Jython based scripting tool that allows us to monitor and manage weblogic
servers. Almost all administration tasks are possible using wlst. It works is online as
well as offline modes (Interactive script and embedded) Its very interesting and
convenient
Initiate wlst:
D:\Oracle\Middleware\wlserver_10.3\server\bin>java weblogic.WLST

Connect to weblogic server.

connect('USERNAME', 'PASSWORD', 'SERVER_ADDRESS:SERVER_PORT')

wls:/offline> connect('weblogic', 'Moto6666', 'localhost:7001')

We can use the basic commands like ls and pwd once we connect to domain.
wls:/lab/serverConfig> pwd ()
serverConfig:/'

wls:/lab/serverConfig> ls ()
dr-- AdminConsole
dr-- AppDeployments
dr-- BridgeDestinations

To start Editing use the commands below: At any point if we see errors we
can use dumpStack() to see the trace. Use activate () to activate the
changes and exit out of edit mode.

wls:/lab/serverConfig> edit()
Location changed to edit tree. This is a writable tree with
DomainMBean as the root. To make changes you will need to start
an edit session via startEdit().
To check that state of a running server (Admin server in this example) and
take thread dump:
wls:/lab/serverConfig> cd('Servers/AdminServer')
wls:/lab/serverConfig/Servers/AdminServer> state ("AdminServer")
Current state of 'AdminServer' : RUNNING
wls:/lab/serverConfig/Servers/AdminServer> pwd ()
'serverConfig:/Servers/AdminServer'

threadDump("./dumps/threadDumpAdminServer.txt")

To disconnect from Server:

disconnect (

To create a new managed server:

wls:/lab/edit !> cd('/')
wls:/lab/edit !> cmo.createServer('Lab1')
[MBeanServerInvocationHandler]com.bea:Name=Lab1,Type=Server
wls:/lab/edit !> cd('/Servers/Lab1')
wls:/lab/edit/Servers/Lab1 !> cmo.setListenAddress('127.0.0.1')
wls:/lab/edit/Servers/Lab1 !> cmo.setListenPort(7777)
wls:/lab/edit/Servers/Lab1 !> activate ()

Activating all your changes, this may take a while ...

The edit lock associated with this edit session is released
once the activation is completed.
Activation completed

startNodeManager() to start nodemanager to control servers

To enroll a server with nodemanager:
setDomainEnv.cmd
java weblogic.WLST
wls> connect(weblogic,'weblogic, t3://mymachine.mydomain:7001)
wls> nmEnroll(C:\bea\user_projects\domains/<domainName>,
C:\bea\wlserver_<version>/common/nodemanager)

To run a python script: java weblogic.WLST forceGC.py

Migrating services:
wls:/mydomain/edit !> migrate('server1','server2', 'true', 'false', 'all')

Migrating JMS and JTA services from 'server1' to destination 'server2' ...
wls:/mydomain/edit !>
wls:/mydomain/edit !> migrate('server1','machine1', 'true', 'false', 'server')
Migrating singleton server services from 'server1' to machine 'machine1' ...
wls:/mydomain/edit !>

Starting a server with options:

wls:/offline> startServer('demoServer','demoDomain',
't3://localhost:8001','myweblogic','wlstdomain','c://mydomains/wlst',
'false', 60000,jvmArgs='-XX:MaxPermSize=75m, -Xmx512m, -XX:
+UseParallelGC')

Suspending a server:
wls:/mydomain/serverConfig> suspend('managed1')
Server 'managed1' suspended successfully.

wls:/mydomain/serverConfig>

Start a cluster:
ydomain/serverConfig> start('mycluster', 'Cluster')
Starting the following servers in Cluster, mycluster: MS1, MS2, MS3...
......................................................................
All servers in the cluster mycluster are started successfully.
wls:/mydomain/serverConfig>

Resume a server:
wls:/mydomain/serverConfig> resume('managed1', block='true')
Server 'managed1' resumed successfully.
wls:/mydomain/serverConfig>

Garbage collection using wlst:

cd('/ServerRuntimes/'+MGD_SERVER+'/JVMRuntime/'+MGD_SERVER)
cmo.runGC(

Connect to nodemanager and start server:

nmConnect(domainName=my_domain, username=weblogic, password=Password)
nmStart('AdminServer')
Deployment descriptors @ weblogic

Deployment descriptors are xml documents that describe runtime behaviour for the deployment
unit. The XML file contains information such as the context root of the web application and the
mapping of the portable names of an application's resources to the application Server's resources

Web Application - WEB-INF/web.xml ( WEBINF/weblogic.xml )

The WEB-INF directory is a vital component of your web application. Web application wont run
without it.It contains a heirarcy in which youll find the necessary configuration information for
your web application, and all the class files for your servlets and classes that are called up by
your JSPs.

WEB-INF folder contains all the class files for your servlets and classes that are called up by
your JSPs

Enterprise Application - META-INF/application.xml (METAINF/weblogic-application.xml) and META-INF/ejb-jar.xml (

META-INF/weblogic-ejb-jar.xml )
Generally comprises of EJBs. Bussiness Tier of an application and EJB basically handels the
Bussiness logic of application (distributed objects)
META-INF/application.xml containes Mappings and security roles etc.whereas META-INF/ejbjar.xml containes ejb classes , session beans mapping etc.,
The META-INF directory is related to .jar files, It contains the manifest file which has list of
jars.
A context-root setting in application.xml takes precedence over context-root setting in
weblogic.xml (The context root of a web application determines which URLs weblogic will
delegate toyour web application.)

Web Service - WEB-INF/web-services.xml

J2EE specs do not define any deployment descriptors from web services. Weblogic introduced
descriptors from webservices.

Environment Scripts:
<DOMAIN_HOME>/bin/setDomainEnv.cmd (sh) script. This sets up all the environment
variables.
Where DOMAIN_HOME is the complete installation path for the domain.
D:\bea\user_projects\domains\lab

WL_HOME is the installation directory of weblogic. Eg., D:\bea

<DOMAIN_HOME>/bin/setWLSEnv.cmd(sh) is another script that can be run to set class path
for running weblogic tools like WLST etc. Its independent of domain configuration. The changes
made to this script effects all the servers in the environment.
commEnv.cmd/sh adds all the JARs located at WL_HOME/server/lib on the classpath
In common/bin D:\bea\wlserver_10.3\common\bin commEnv.cmd (sh) is the main script that
both the setDomainEnv.cmd (sh) / setWLSEnv.cmd(sh) scripts call.
setDomainEnv.cmd/sh is specific for a domain

ANT
wlserver task is predefined in the version of Ant shipped with WebLogic Server.
ejbjar is one more built in task for working with EJBs
Example build file:
<ejbjar srcdir="build"
descriptordir="descriptor">
<weblogic destdir="build/deploy"
classpath="${weblogic.classpath}:build"
compiler="javac"/>
<include name="**/*-ejb-jar.xml"/>
<exclude name="**/*weblogic*.xml"/>
</ejbjar

If you want to use the task with your own Ant installation, add the following task definition in
your build file:
<taskdef name="wlserver" classname="weblogic.ant.taskdefs.management.WLServer"/
<target name="wlserver-default">
<wlserver/>
</target>

Provide the following details under identitiy.

Keystores: Custom Identity and Custom Trust

Custom Identity Keystore : /Path/to/keystore.jks
Custom Identity Keystore : jks
Custom Identity Keystore Passphrase: <password>
Confirm Custom Identity Keystore Passphrase: <password>
Provide the following details under trust..
Custom Trust Keystore: /Path/to/trustkeystore.jks
Custom Trust Keystore Type: jks
Custom Trust Keystore Passphrase: <password>
Confirm Custom Trust Keystore Passphrase: <password>
Click on SSL tab.

Provide the Private Key Alias (the one we provided while generating private key) and
passphrase.

Click on General Tab.

Check the box named: Enable SSL Listen port.

Your application is SSL ready!