python to start, stop, deploy and undeploy application

import sys
import os
from java.lang import System

import getopt

def usage():
print "Usage:"
print "java weblogic.WLST app_ctl.py [-n] -u user -p password -a url -m moduleName -c command -d sourcedir -t targets -s stagemode"
try:
opts, args = getopt.getopt(sys.argv[1:], "nu:p:a:m:c:d:t:s:",
["user=", "password=", "url=",
"moduleName=", "command=", "soucedir", "targets", "stagemode"])
except getopt.GetoptError, err:
print str(err)
usage()
#sys.exit(2)

reallyDoIt = true
user=None
password=None
url=None
moduleName=None
command=None
sourcedir=None
targets=None
stagemode=None

for opt, arg in opts:
if opt == "-n":
reallyDoIt = false
elif opt == "-u":
user = arg
elif opt == "-p":
password = arg
elif opt == "-a":
url = arg
elif opt == "-m":
moduleName = arg
elif opt == "-c":
command = arg
elif opt == "-d":
sourcedir = arg
elif opt == "-t":
targets = arg
elif opt == "-s":
stagemode = arg

if not user:
print "Missing \"-u user\" parameter."
usage()
#sys.exit(2)
elif not password:
print "Missing \"-p password\" parameter."
usage()
#sys.exit(2)
elif not url:
print "Missing \"-a url\" parameter."
usage()
#sys.exit(2)
elif not moduleName:
print "Missing \"-m moduleName\" parameter."
usage()
#sys.exit(2)
elif not command:
print "Missing \"-c command\" parameter."
usage()
#sys.exit(2)

print "Got all the required parameters."

#######################
if command == 'stop':
connect(user, password, url)
print 'Starting stop of '+moduleName+'...'
progress='null'
try:
cd("/AppDeployments/"+moduleName)
progress=stopApplication(moduleName)
print 'Checking stop status...'
state = progress.getState()
if state == 'completed':
print 'OK: Stop of '+moduleName+' was successful...'
else:
print 'ERROR: Stop of '+moduleName+' was not successful...'
except :
print 'Application '+moduleName+' does not exist.'
elif command == 'start':
connect(user, password, url)
print 'Starting start of '+moduleName+'...'
progress='null'
try:
cd("/AppDeployments/"+moduleName)
progress=startApplication(moduleName)
print 'Checking start status...'
state = progress.getState()
if state == 'completed':
print 'OK: Start of '+moduleName+' was successful...'
else:
print 'ERROR: Start of '+moduleName+' was not successful...'
except :
print 'Application '+moduleName+' does not exist.'
elif command == 'deploy':
connect(user, password, url)
print 'Starting deploy of '+moduleName+'...'
progress='null'
try:
#cd("/AppDeployments/"+moduleName)
progress=deploy(appName=moduleName, path=sourcedir, targets=targets, stageMode=stagemode)
print 'Checking deploy status...'
state = progress.getState()
if state == 'completed':
print 'OK: Deploy of '+moduleName+' was successful...'
else:
print 'ERROR: Deploy of '+moduleName+' was not successful...'
except :
print 'Application '+moduleName+' does not exist.'
elif command == 'undeploy':
connect(user, password, url)
print 'Starting undeploy of '+moduleName+'...'
progress='null'
try:
#cd("/AppDeployments/"+moduleName)
progress=undeploy(moduleName)
print 'Checking undeploy status...'
state = progress.getState()
if state == 'completed':
print 'OK: Undeploy of '+moduleName+' was successful...'
else:
print 'ERROR: Undeploy of '+moduleName+' was not successful...'
except :
print 'Application '+moduleName+' does not exist.'

################################
#
# stopProgress='null'
# stopProgress=stopApplication("spd")
# print 'Checking stop status...'
# stopProgress.getState()
#
#if stopProgress.getState == 'completed':
# print "Stop successful..."
#else:
# print "ERROR: stop spd not successful..."
#
#elif action == "start":
#
# connect(uname, pwd, url)
# startProgress='null'
# startProgress=startApplication('spd')
# print 'Checking start status...'
# startProgress.getState()

Taking thread dumps for weblogic server

A) On Windows machine: cltr + break
On Unix Machine:
get pid using ps -ef grep java
kill -3
B) When weblogic is running as windows service
For Out file add in JAVA_OPTIONS:
-Dweblogic.Stdout=
a) Using beasvc :
beasvc –dump – svcname:”bea Admin_server”
b) Using Weblogic Admin utility
C:\bea\user_projects\domains\rDomain>java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic THREAD_DUMP
Thread Dump has been printed to the servers standard out (by default, the shell in which the server is running).

C) We can also collect thread dumps from the console:
Server > Monitoring > Threads > Dump Thread Stacks

D) Using WLST:
1) java weblogic.WLST
2) connect("weblogic","weblogic","t3:\\localhost:7001")
3) threadDump()

Troubleshooting: HTTP Session Replication Failure Issues

One of the major advantage of weblogic server is 'HTTP session replication'. Sometimes, HTTP session states are not replicated from the primary server to the secondary server. This is the most common issue which is observed.

Symptoms:

1. The application using HTTP session does not function as designed and you see a loss of session data.
2. You might be asked to re-log into the application even when the session has still not timed out.
3. You see errors and warnings related to HTTP session failures in the server's log file.
4. The request is not failed over to another server properly.

There are several reasons as to why session replication fails. We will look at ways to diagnose the issue, possible reasons for it, and the ways to address them.

Types of HTTP Session Replication
There are five different implementations of session persistence:

• Memory (single-server, non-replicated): When you use memory-based storage, all session information is stored in memory and is lost when you stop and restart WebLogic Server.
• File system persistence: Session information is stored in a file under the PersistentStoreDir specified.
• JDBC persistence: Session information is stored in a database table.
• Cookie-based session persistence: Session information is stored in a cookie.
• In-memory replication (across a cluster): Session data is copied from one server instance to another into memory.

Usually observed causes session not getting replicated:

1) All application objects are not serialized
2) Session is not set using set.attribute()
3) Network issue causing the managed server to move out of the cluster.
4) Weblogic server hang resulting to non-responsiveness to replicated session
5) Issue at the webserver end.

Diagnosing the Issue
Consider a scenario with two servers (MyServer-1, MyServer-2) in a cluster. When you enable the debug flags (see the "Enable the Debug Flags to Track Session Replication Failures"section), you will see the messages below when a request from a client is sent the very first time.

On MyServer-1:

<000000>

<000000>

This logging message means that the primary server is MyServer-1 and a secondary has been created on MyServer-2. A message like the one shown below will be logged on MyServer-2 to confirm that.

ExecuteThread: '1' for queue: 'Replication'> <>
<000000>
####

<> <000000>

If you check the JSESSIONID it looks like:

JSESSIONID=1E9Xwn7nLYfOsc1obgRZIwW5s72an7HPPvSD7iaWHMXzpHga5cQj
!-1587343083!-1587348922

JSESSIONID is the default name of the cookie, which could be changed to anything in weblogic.xml. The format of JSESSIONID is

SessionId!PrimaryServer JVM Hash!SecondaryServer JVMHash

Every time data is changed (either set/get or removed) in the session you'll see the logging message.

On MyServer-1:

<000000>

On MyServer-2:

####
<> <000000>

If for any reason session replication fails, you will see the message below in the MyServer-1 log:

<000000>

<000000>

And, the JSESSIONID would appear as

JSESSIONID=1E9Xwn7nLYfOsc1obgRZIwW5s72an7HPPvSD7iaWHMXzpHga5cQj!-1587343083!NONE

The secondary server hash would become NONE

Enable the Debug Flags to Track Session Replication Failures
You can enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails.

Configuration: Diagnostics JDBC store Archive

The Archive component of the WebLogic Diagnostic Framework (WLDF) captures and persists all data events, log records, and metrics collected by WLDF from server instances and applications running on them. You can access archived diagnostic data in online mode (that is, on a running server). You can also access archived data in off-line mode using the WebLogic Scripting Tool (WLST).

Here, I have given steps which have to be followed to configure JDBC store Diagnostics Archive. Database used is: Pointbase

1) Create a Datasource from weblogic console with the JNDI name say: DS1
2) Create the following tables in Database:

a) wls_hvst

DROP TABLE wls_hvst;
CREATE TABLE wls_hvst (
RECORDID INTEGER IDENTITY,
TIMESTAMP NUMERIC default NULL,
DOMAIN varchar(64) default NULL,
SERVER varchar(64) default NULL,
TYPE varchar(64) default NULL,
NAME varchar(250) default NULL,
ATTRNAME varchar(64) default NULL,
ATTRTYPE INTEGER default NULL,
ATTRVALUE VARCHAR(4000)
);
COMMIT;

b) wls_event

DROP TABLE wls_events;
CREATE TABLE wls_events (
RECORDID INTEGER IDENTITY,
TIMESTAMP NUMERIC default NULL,
CONTEXTID varchar(128) default NULL,
TXID varchar(32) default NULL,
USERID varchar(32) default NULL,
TYPE varchar(64) default NULL,
DOMAIN varchar(64) default NULL,
SERVER varchar(64) default NULL,
SCOPE varchar(64) default NULL,
MODULE varchar(64) default NULL,
MONITOR varchar(64) default NULL,
FILENAME varchar(64) default NULL,
LINENUM INTEGER default NULL,
CLASSNAME varchar(250) default NULL,
METHODNAME varchar(64) default NULL,
METHODDSC varchar(4000) default NULL,
DROP TABLE wls_events;
CREATE TABLE wls_events (
RECORDID INTEGER IDENTITY,
TIMESTAMP NUMERIC default NULL,
CONTEXTID varchar(128) default NULL,
TXID varchar(32) default NULL,
USERID varchar(32) default NULL,
TYPE varchar(64) default NULL,
DOMAIN varchar(64) default NULL,
SERVER varchar(64) default NULL,
SCOPE varchar(64) default NULL,
MODULE varchar(64) default NULL,
MONITOR varchar(64) default NULL,
FILENAME varchar(64) default NULL,
LINENUM INTEGER default NULL,
CLASSNAME varchar(250) default NULL,
METHODNAME varchar(64) default NULL,
METHODDSC varchar(4000) default NULL,

3) Create a WLDF Module from Diagnostics > WLDF Module and target to a server

4) For the diagnostics module create a Collection Metrics for JDBCDataSourceRuntimeMBean

5) Click on Diagnostics > Archives and select the server for which we need to collect data.

6) Change the archive type to JDBC instead of File store and select the datasource which has to be used for JDBC store
















7) Deploy any application which used database connection as we have configured the diagnostics module for JDBCRuntimeMbean and access the application.

8) The data will be archived in the table wls_hvst :















References:

http://download.oracle.com/docs/cd/E11035_01/wls100/wldf_configuring/config_diag_archives.html

Use 81 style execute queues

From Weblogic 9.x onwards work managers are used instead of execute queues. Oracle provides a flag that enables you to disable the self-tuning execute pool and provide backward compatibility for upgraded applications to continue to use user-defined execute queues. Following steps can be followed to use 81 execute queues with later weblogic versions

1) Manually add the following in the config.xml:

AdminServer

true

Or we can add the following in JAVA_OPTIONS :

-Dweblogic.Use81StyleExecuteQueues=true

2) Start the server

On adding this parameter we will get queue tab under server > configuration > Queue the console:

Create a new Queue with the name: weblogic.kernel.default

We can edit the queue length and other parameters as in WLS8.1

Reference link:

http://download.oracle.com/docs/cd/E11035_01/wls100/perform/appb_queues.html#wp1048423

Production redeployment of application/ versioning/ side by side deployment

We need versioning for updating the application in production on runtime. The sessions which are already logged in will be using the previous version of the application and the new sessions created will use the new version of application.

1) In the application, Version-1 in MANIFEST.MF we need to add the following:

Manifest-Version: 1.0
Created-By: 1.5.0_04 (Sun Microsystems Inc.)
Weblogic-Application-Version: Version-1

Version-2 MENIFEST-MF
Manifest-Version: 1.0
Created-By: 1.5.0_04 (Sun Microsystems Inc.)
Weblogic-Application-Version: Version-1



2. Open a command window and browse to your domain bin directory.
3. start Admin server using Startweblogic.cmd.
4. Type setdomainenv.cmd to set your weblogic Domain.
5.Now to deploy the first version run the following command (please change as per your specifications):
C:\bea9.1\user_projects\domains\base_domain>java weblogic.Deployer -appversion 1 -adminurl http://127.0.0.1:7001 -username weblogic -password weblogic -deploy -name deployment_name -source c:/.../ -targets AdminServer
6. Now to Redeploy use the following command:
C:\bea9.1\user_projects\domains\base_domain>java weblogic.Deployer -appversion 2 -adminurl http://127.0.0.1:7001 -username weblogic -password weblogic -redeploy -name deployment_name -source c:/.../ -retiretimeout 120

7. We will get the version -1 application in retiring state in the console. The requests which were handled previously by this application will be handled by this version.
8. Version-2 application will have ACTIVE status and will be accepting new requests coming in to the application.

Reference:
http://download.oracle.com/otn_hosted_doc/wls/redeployment/wls-side-by-side-non-annotation_viewlet_swf.html