Modes of Deployment

Stage mode—The Administration Server copies the archive files from their source location to a location on each of the targeted Managed Servers that deploy the archive. For example, if you deploy a J2EE Application to three servers in a cluster, the Administration Server copies the application archive files to each of the three servers. Each server then deploys the J2EE Application using its local copy of the archive files.
Stage mode is the default mode when deploying to more than one WebLogic Server instance.

Nostage mode—The Administration Server does not copy the archive files from their source location. Instead, each targeted server must access the archive files from a single source directory for deployment. For example, if you deploy a J2EE Application to three servers in a cluster, each server must be able to access the same application archive files (from a shared or network-mounted directory) to deploy the application.
Nostage mode is the default mode when deploying only to the Administration Server (for example, in a single-server domain). You can also select nostage mode if you run a cluster of server instances on the same machine.

External_stage mode—External_stage mode is similar to stage mode, in that the deployment files must reside locally to each targeted server. However, the Administration Server does not automatically copy the deployment files to targeted servers in external_stage mode; instead, you must manually copy the files, or use a third-party application to copy the files for you

WebLogic Server as a Unix Daemon Process

Start Weblogic Server as a Unix Daemon Process

The following procedure outlines the steps required to start WLS as a Unix daemon

1) Copy the startWebLogic.sh script to the /etc/init.d directory. For the purpose of these instructions, name it "startWLS_daemon.sh".

2) Modify the java command line used to start WLS by adding a path that points to your domain directory. For example:
-Dweblogic.RootDirectory=/opt/bea/user_projects/domains/mydomain

3) Test your startup script by executing it from the /etc/init.d directory.

4) When you have successfully resolved any path issues, add the following command line options:
JAVA_OPTIONS="-Dweblogic.Stdout="outfilename" -Dweblogic.Stderr="errorfilename" -Dweblogic.RootDirectory=/bib00d10/boxi/user_projects/domains/BOXI/ ${SAVE_JAVA_OPTIONS}"

We have to specify a fully qualified fie path instead of outfilename and errorfilename.For example c:\out.txt

5) Next, create a link to startWLS_daemon.sh in the /etc/rc2 directory.
>cd /etc/rc2.d
>ln -s /etc/init.d/startWLS_daemon.sh startWLS

6) Reboot your Unix machine and examine the stdout and stderr output in the file(s) listed in step 4) to ensure that the WLS daemon started successfully.

If your domain is in production mode you have to do the following also:-

Modify the startup script and pass the user name and password like this:-
WLS_USER=
WLS_PW=

Java Client Program to test WLS MultiDatasource Failover/Load Balancing

Client to test Multidatasource Failover/Loadbalancing Feature of WLS

import javax.naming.*;

import java.util.*;

import javax.rmi.*;

import javax.sql.*;

import java.sql.*;

public class MyDsClient

{

public final static String JNDI_FACTORY = "weblogic.jndi.WLInitialContextFactory";

private static String serverUrl ="t3://localhost:7001";

public static void main(String ar[])throws Exception

{

PreparedStatement pr = null;

InitialContext ic=null;

try{

Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);

env.put(Context.PROVIDER_URL, serverUrl);

ic = new InitialContext(env);

}

catch(Exception e){}

try{

Connection con[]=new Connection[1000];

for(int i=0;i<1000;i++)

{

Object obj=ic.lookup("mds");

DataSource ds=(DataSource)obj;

con[i]=ds.getConnection();

System.out.println("\n\nGot the Connection : "+con[i]);

pr = con[i].prepareStatement("insert into test values(?)");

pr.setInt(1,i);

System.out.println(i);

int rs = pr.executeUpdate();

System.out.println("ROWS UPDATED:"+ rs);

try {

Thread.sleep(1000);

} catch(Exception ee)

{

ee.printStackTrace();

}

con[i].close();

}

}

catch(Exception e)

{

System.out.println("\n\n\t jack Exception => "+e);

e.printStackTrace();

}

}

}

Distributed Environment

WebLogic Server Distributed Environment

We would need to install Node Manager on the second physical machine to make it accessible from Admin server (of first physical machine).

The step by step procedure for installing Managed Server on another physical machine and

associating it with admin server are:

1) Install Weblogic server on the physical machine.

2) Install Node Manager and start it.

3) Start the scripting tool.(Start -BEA -Tools -Weblogic Scripting Tool)

4) Connect to the admin server type - connect() and press enter.

5) It would ask for admin server username, password and admin server url. Please give the required

information.

6) NM Enroll - this would connect the two node managers of different physical machine. Command is

nmEnroll(‘the path till nodemanager folder’) e.g. nmEnroll(‘C:\bea\weblogic10\common\nodemanager’)

7) Go to the admin console

8) From the admin server create the managed server. Give listen address of second machine. Make a

machine and in the node manager give the address of remote IP(i.e IP of 2nd Physical machine ).

Associate this machine with the newly created Managed Server. In all we need to give remote IP

address in 2 places- one in node manager and another while creating managed server.

9) This would create the managed server on 2nd physical machine. This would be associated with the

admin server running on 1st physical machine.

Directly connecting to Database without using DataSource

//package _Connect;

import java.sql.*;

import java.sql.Connection;

import java.sql.DatabaseMetaData;

import java.sql.DriverManager;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.util.Calendar;

import java.util.Date;

import java.util.Properties;

public class TryQuery

{

public static void main(String[] args) throws Exception

{

Calendar cal = Calendar.getInstance();

long startMilis = 0;;

long endMilis = 0;

Connection con = null;

try

{

Class.forName("oracle.jdbc.driver.OracleDriver");

//DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());

Properties props = new Properties();

props.put("user", "abcd");

props.put("password", "abcd");

con = DriverManager.getConnection("jdbc:oracle:thin:@IPADDRESS:PORT_NO:SID",props);

DatabaseMetaData dbmd = con.getMetaData();

System.out.println("Connected to : " + dbmd.getDatabaseProductVersion());

System.out.println("JDBC Driver: " + dbmd.getDriverVersion());

System.out.println(dbmd.getURL());

PreparedStatement ps = con.prepareStatement("select slow_query(20) from dual");

ps.setQueryTimeout(5);

cal.setTime(new Date());

startMilis = cal.getTimeInMillis();

System.out.println("start query ");

ps.execute();

ResultSet rs = ps.getResultSet();

int counter = 0;

while (rs.next())

{

counter++;

}

ps.close();

}

catch (Exception e)

{

System.out.println(e);

}

finally

{

cal.setTime(new Date());

endMilis = cal.getTimeInMillis();

System.out.println("end query - Elapsed : " + ((endMilis - startMilis) / 1000) + " seconds");

con.close();

}

}

}

Java Code for Connecting to Database using DataSource

//package _Connect;

import java.sql.Connection;

import java.sql.DatabaseMetaData;

//import java.sql.DriverManager;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

//import java.sql.*;

import java.util.*;

import javax.naming.*;

import java.util.Calendar;

import java.util.Date;

//import java.util.Properties;

public class DataSourceQuery

{

public static void main(String[] args) throws Exception

{

Calendar cal = Calendar.getInstance();

long startMilis = 0;

long endMilis = 0;

Connection con = null;

Context ctx = null;

Hashtable ht = new Hashtable();

ht.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");

ht.put(Context.PROVIDER_URL,"t3://localhost:7001");

try

{

ctx = new InitialContext(ht);

// Enter the JNDI Name here

javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup ("JNDI_Name");

con = ds.getConnection();

DatabaseMetaData dbmd = con.getMetaData();

System.out.println("Connected to : " + dbmd.getDatabaseProductVersion());

System.out.println("JDBC Driver: " + dbmd.getDriverVersion());

System.out.println(dbmd.getURL());

PreparedStatement ps = con.prepareStatement("select * from dual");

ps.setQueryTimeout(5);

cal.setTime(new Date());

startMilis = cal.getTimeInMillis();

System.out.println("start query ");

ps.execute();

ResultSet rs = ps.getResultSet();

int counter = 0;

while (rs.next())

{

counter++;

}

ps.close();

}

catch (Exception e)

{

System.out.println(e);

}

finally

{

cal.setTime(new Date());

endMilis = cal.getTimeInMillis();

System.out.println("end query - Elapsed : " + ((endMilis - startMilis) / 1000) + "seconds");

//con.close();

}

}

}

Presenting the Permanent Generation

Have you ever wondered how the permanent generation fits into our generational system? Ever been curious about what's in the permanent generation. Are objects ever promoted into it? Ever promoted out? We'll you're not alone. Here are some of the answers.

Java objects are instantiations of Java classes. Our JVM has an internal representation of those Java objects and those internal representations are stored in the heap (in the young generation or the tenured generation). Our JVM also has an internal representation of the Java classes and those are stored in the permanent generation. That relationship is shown in the figure below.



The internal representation of a Java object and an internal representation of a Java class are very similar. From this point on let me just call them Java objects and Java classes and you'll understand that I'm referring to their internal representation. The Java objects and Java classes are similar to the extent that during a garbage collection both are viewed just as objects and are collected in exactly the same way. So why store the Java objects in a separate permanent generation? Why not just store the Java classes in the heap along with the Java objects?

Well, there is a philosophical reason and a technical reason. The philosophical reason is that the classes are part of our JVM implementation and we should not fill up the Java heap with our data structures. The application writer has a hard enough time understanding the amount of live data the application needs and we shouldn't confuse the issue with the JVM's needs.

The technical reason comes in parts. Firstly the origins of the permanent generation predate my joining the team so I had to do some code archaeology to get the story straight (thanks Steffen for the history lesson).

Originally there was no permanent generation. Objects and classes were just stored together.

Back in those days classes were mostly static. Custom class loaders were not widely used and so it was observed that not much class unloading occurred. As a performance optimization the permanent generation was created and classes were put into it. The performance improvement was significant back then. With the amount of class unloading that occur with some applications, it's not clear that it's always a win today.

It might be a nice simplification to not have a permanent generation, but the recent implementation of the parallel collector for the tenured generation (aka parallel old collector) has made a separate permanent generation again desirable. The issue with the parallel old collector has to do with the order in which objects and classes are moved. If you're interested, I describe this at the end.

So the Java classes are stored in the permanent generation. What all does that entail? Besides the basic fields of a Java class there are

Methods of a class (including the bytecodes)
Names of the classes (in the form of an object that points to a string also in the permanent generation)
Constant pool information (data read from the class file, see chapter 4 of the JVM specification for all the details).
Object arrays and type arrays associated with a class (e.g., an object array containing references to methods).
Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)
Information used for optimization by the compilers (JITs)

That's it for the most part. There are a few other bits of information that end up in the permanent generation but nothing of consequence in terms of size. All these are allocated in the permanent generation and stay in the permanent generation. So now you know.

This last part is really, really extra credit. During a collection the garbage collector needs to have a description of a Java object (i.e., how big is it and what does it contain). Say I have an object X and X has a class K. I get to X in the collection and I need K to tell me what X looks like. Where's K? Has it been moved already? With a permanent generation during a collection we move the permanent generation first so we know that all the K's are in their new location by the time we're looking at any X's.

How do the classes in the permanent generation get collected while the classes are moving? Classes also have classes that describe their content. To distinguish these classes from those classes we spell the former klasses. The classes of klasses we spell klassKlasses. Yes, conversations around the office can be confusing. Klasses are instantiation of klassKlasses so the klassKlass KZ of klass Z has already been allocated before Z can be allocated. Garbage collections in the permanent generation visit objects in allocation order and that allocation order is always maintained during the collection. That is, if A is allocated before B then A always comes before B in the generation. Therefore if a Z is being moved it's always the case that KZ has already been moved.

And why not use the same knowledge about allocation order to eliminate the permanent generations even in the parallel old collector case? The parallel old collector does maintain allocation order of objects, but objects are moved in parallel. When the collection gets to X, we no longer know if K has been moved. It might be in its new location (which is known) or it might be in its old location (which is also known) or part of it might have been moved (but not all of it). It is possible to keep track of where K is exactly, but it would complicate the collector and the extra work of keeping track of K might make it a performance loser. So we take advantage of the fact that classes are kept in the permanent generation by collecting the permanent generation before collecting the tenured generation. And the permanent generation is currently collected serially.


Reference : http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

Clustered Clients and JMS Distributed Destinations

Recently a customer asked me about a JMS problem they've been experiencing when using Uniform Distributed Topics (UDT). I explain the problem below but essentially the application consuming the JMS messages was itself a clustered client, and thus getting a message per instance of the application across the cluster.

The Problem
The problem was they have a number of applications deployed to a cluster as clients consuming from the distributed topic. Each instance of the application is treated as a consumer and thus getting multiple message instead of the desired one per application across the cluster. Now don't get me wrong, the customer was not complaining that JMS or distributed queues needed to be changed, but how could they get the functionality they wanted while still enjoying the higher availability and scalability a UDT afforded them. One thing to note is if the operations being performed on the messages were idempotent this wouldn't have been as serious even though it was processed multiple times, the result would have been the same (albeit a little ugly!).

The image below describes the situation the customer was trying to solve.
JMSArchitecture%20-%20current.jpg

The Target
The goal was to have a messaging system to the guarantee delivery while also being resilient. Each application, whilst deployed across the cluster should only get one message.

JMSArchitecture-desired.jpg
This diagram shows the proposed messaging architecture.
A message coming into the Uniform Distributed Destination (UDD) is sent, in some load balancing fashion, to only one instance of the application. The load balancing might be multiplexed across application or across cluster nodes and then across the instances of the application on that node.


Proposed Solution

The main problem with the current architecture is the UDT which is directly handling the incoming the messages and from which the applications are directly subscribing to. This naturally broadcasts the messages across all members indiscriminately, irrespective of application.

The UDT can be replaced with a UDQ to which external messages are published. The UDQ will load balance these incoming messages to one and only one of the managed servers. A local Message-driven Bean deployed to the cluster can listen on the UDQ (an instance of which will be deployed to each of the managed servers). Its sole job is to publish to a local-only JMS Topic to which the applications are listening. This is shown logically below.
JMSArchitecture%20-%20proposed.jpg

It is important the MDB is transactional, to ensure it succeeds in putting the message into the local topic, or on failure the transaction is rolled back and thus the message is ready for another attempt. The local Topic must have a unique name and no global JNDI name. Instead a local JNDI name is provided which is the same across the cluster (and thus the MDB publishes the messages to a Topic with the same same name irrespective of its location in the cluster).

I have prototype this solution in WebLogic Server 10gR3 using EJB 3.0 on a two node cluster, and am happy to share the project should someone be interested enough.

Reference : http://blogs.oracle.com/BrettLomas/2009/02/clustered_clients_and_jms_dist_1.html

Difference between Persistence and NonPersistence Messaging

Message persistence is set by Delivery mode attribute of the message producer in the JMS client or it can bet set on a message basis during the send operation. The default value for the delivery mode on the message producer is PERSISTENT.

Weblogic JMS has a feature to override the delivery mode set by the message producer. This is at the Destination configuration where there is an attribute called the Delivery Mode Override which can take the values:

No-Delivery: Delivery mode of the message producer will not be overridden
Persistent: All messages are marked as persistent irrespective of the message producer setting
Non Persistent: All Messages are marked as non persistent irrespective of the message producer setting.

All non persistent messages are stored in memory in normal case. If there is a pile up of messages, weblogic moves the body Messages to disk within what is called as a paging store for the JMS server, only retaining message headers in memory. The characteristic of non persistent messages is that it can't survive server restart. So these messages even when they are on the disk within the paging store wont survive the server restarts

weblogic.Admin utility

Syntax

------

java weblogic.Admin -url localhost:7001 -username usrnm -password passwd COMMAND

Exit Codes Returned by weblogic.Admin

-------------------------------------

--> All weblogic.Admin commands return an exit code of 0 if the command succeeds and an exit code of 1 if the command fails.

in windows - echo %ERRORLEVEL%

in bash shell - echo $?

#TO DISCOVER MANAGE SERVER IS RUNNING OR NOT

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic DISCOVERMANAGEDSERVER -serverName MS1

#TO SHUTDOWN THE MANAGE SERVER FORCEFULLY

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic FORCESHUTDOWN MS1

#TO RESUME THE MANAGE SERVER

java weblogic.Admin -url http://localhost:7001 -username weblogic -password weblogic RESUME MS1

#TO SHUTDOWN MANAGE SERVER GRACEFULLY

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic SHUTDOWN MS1

#TO START THE MANAGE SERVER USING NODEMANAGER (PROVIDED) ADMIN SERVER IS RUNNING

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic START MS1

#TO CONNECT TO A WEBLOGIC INSTANCES

java weblogic.Admin -url managedhost:8001 -username weblogic -password weblogic CONNECT 10

#TO GET CURRENT STATE OF SERVER INSTANCE

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic GETSTATE

#TO LISTS THE BEA LICENSES FOR ALL WEBLOGIC SERVER INSTANCES INSTALLED ON THE SPECIFIED HOST

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic LICENSES

#TO LISTS THE BINDINGS OF A NODE IN THE JNDI NAMING TREE.

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic LIST

#TO PING THE SERVER INSTANCE

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic PING 10

#TO GET SERVER LOGS

java weblogic.Admin -url ManagedHost:8001 -username weblogic -password weblogic SERVERLOG | more

#TO GET THREAD DUMP

java weblogic.Admin -url ManagedHost:8001 -username weblogic -password weblogic THREAD_DUMP

#TO SEE THE VERSION OF WEBLOGIC

java weblogic.Admin -url ManagedHost:8001 -username weblogic -password weblogic VERSION

# TO START THE MANAGED SERVERS IN STANDBY MODE

java weblogic.Admin -url https://localhost:9002 -username weblogic -password weblogic STARTINSTANDBY MS1

# TO CREATE CONNECTION POOL

java weblogic.Admin -url http://ManagedHost:7001 -username weblogic -password weblogic CREATE_POOL demopool url=jdbc:pointbase:server://localhost:9092/demo, driver=com.pointbase.jdbc.jdbcUniversalDriver, testConnsOnReserve=true, testTableName=SYSTABLES, initialCapacity=2, maxCapacity=10, capacityIncrement=2, allowShrinking=true, props=user=examples;password=examples

java weblogic.Admin -url http://localhost:7003 -username weblogic -password weblogic CREATE_POOL demopool url=jdbc:pointbase:server://localhost:9092/demo, driver=com.pointbase.jdbc.jdbcUniversalDriver, props=user=examples;password=examples

#TO CREATE CONNECTION POOL BY USING -mbean(ADMIN MBEANS) AS A ARGUMENT

java weblogic.Admin -url localhost:7003 -username weblogic -password weblogic CREATE -mbean “anup:Type=JDBCConnectionPool,Name=myPool”

#TO GET INFO ABT CONNECTIONPOOL

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic GET -pretty -mbean anup:Name=myPool,Type=JDBCConnectionPool

#TO DISPLAYS ALL INSTANCES OF ALL JDBCConnectionPoolRuntime MBeans FOR ALL SERVERS IN THE DOMAIN.

java weblogic.Admin -adminurl localhost:7001 -username weblogic -password weblogic GET -pretty -type JDBCConnectionPoolRuntime

#TO INVOKE THE PROPERTIES OF A INSTANCES

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic INVOKE -mbean MedRec:Location=MedRecServer,Name=myPool, ServerRuntime=MedRec,Type=JDBCConnectionPoolRuntime -method enable

#TO SEARCH ALL THE RUNTIME Mbeans THAT ARE RUNNING FOR THE SERVER

java weblogic.Admin -url ManagedHost:8001 -username weblogic -password weblogic QUERY -pattern *:Type=JDBCConnectionPoolRuntime,*

#TO SET ANY ATTRIBUTE THAT IS NOT DISPLAYED IN CONSOLE

java weblogic.Admin -url http://ManagedHost:8001 -username weblogic -password weblogic SET -mbean MedRec:Location=MedRecManagedServer,Name=MedRecManagedServer,Type=ServerConfig -property StdoutSeverityLevel 64

#TO EXECUTE THE COMMANDS IN BATCHFILE i.e.,BATCHUPDATE COMMAND

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic BATCHUPDATE -batchFile c:\commands.txt -continueOnError -batchCmdVerbose

#TO GET AN ATTRIBUTE INFO.

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic GET -mbean MedRec:Name=MedRecServer,Type=Server -property ListenPort

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic GET -mbean MedRec:Name=MedRecManagedServer,Type=Server -property ListenPort

#TO KNOW THE STATE OF A CLUSTER

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic CLUSTERSTATE -clustername MedRecCluster

#TO START THE MANAGE SERVERS AT A TIME IN CLUSTER

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic STARTCLUSTER -clustername MedRecCluster

#TO VALIDATE THE CLUSTER CONFIG

java weblogic.Admin -url AdminHost:7001 -username weblogic -password weblogic VALIDATECLUSTERCONFIG -configpath samples\domains\medrec\config.xml

#TO PURGE THE DEPLOYMENTS REQUESTS

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic PURGETASKS

#TO STORE THE USER CREDENTIALS

java weblogic.Admin -username weblogic -password weblogic STOREUSERCONFIG

GENERAL PROPERTIES OF A SERVER IN A DOMAIN

-------------------------------------------

#TO VIEW LISTEN PORT OF PARTICULAR SERVER(ADMIN SERVER OR MANAGED SERVER)

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ListenPort

#TO VIEW LISTEN ADDRESS OF PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ListenAddress

#TO VIEW LISTEN PORT IS ENABLED OR NOT OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ListenPortEnabled

#TO VIEW STARTUPMODE OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property StartupMode

#TO VIEW ADMINISTRATION PORT OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property AdministrationPort

TUNNING PROPERTIES OF A SERVER IN A DOMAIN

-------------------------------------------

#TO VIEW SOCKET READERS OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property SocketReaders

#TO VIEW THE STUCK THREAD MAX. TIME OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property StuckThreadMaxTime

#TO VIEW THE STUCK THREAD TIMER INTERVAL OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property StuckThreadTimerInterval

#TO VIEW THE LOGIN TIMEOUT OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property LoginTimeout

#TO VIEW ACCEPT BACKLOG OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property AcceptBacklog

#TO VIEW REVERSE DNS ALLOWED PROPERTY OF A PARTICULAR SERVER IS ENABLED OR NOT

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ReverseDNSAllowed

#TO VIEW Low Memory GC Threshold OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property LowMemoryGCThreshold

#TO VIEW Low Memory Granularity Level OF A PARTICULAR SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property LowMemoryGranularityLevel

#TO VIEW Low Memory Sample Size OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property LowMemorySampleSize

#TO VIEW Low Memory Time Interval OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property LowMemoryTimeInterval

#TO VIEW Managed Server Independence Enabled OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ManagedServerIndependenceEnabled

#TO VIEW MSI File Replication Enabled OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property MSIFileReplicationEnabled

HEALTH MONITORING PROPERTIES OF A SERVER IN A DOMAIN

-----------------------------------------------------

#TO VIEW Auto Restart OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property AutoRestart

#TO VIEW Auto Kill If Failed OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property AutoKillIfFailed

#TO VIEW Restart Delay Seconds OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property RestartDelaySeconds

CLUSTER PROPERTIES OF A SERVER IN A DOMAIN

-------------------------------------------

#TO VIEW Replication Group OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ReplicationGroup

#TO VIEW Preferred Secondary Group OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property PreferredSecondaryGroup

#TO VIEW Cluster Weight OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property ClusterWeight

#TO VIEW Interface Address OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property InterfaceAddress

DEPLOYMENT PROPERTIES OF A SERVER IN A DOMAIN

---------------------------------------------

#TO VIEW Staging Mode OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property StagingMode

#TO VIEW Staging Directory Name OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property StagingDirectoryName

#TO VIEW Upload Directory Name OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property UploadDirectoryName

#TO VIEW Messaging Bridge Thread Pool Size OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property MessagingBridgeThreadPoolSize

#TO VIEW JMS Thread Pool Size OF A SERVER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Server,Name=admin -property JMSThreadPoolSize

CLUSTER PROPERTIES OF A DOMAIN

------------------------------

GENERAL CLUSTER PROPERTIES OF A DOMAIN

--------------------------------------

#TO VIEW ClusterAddress OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property ClusterAddress

#TO VIEW Default Load Algorithm OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property DefaultLoadAlgorithm

#TO VIEW Client Cert Proxy Enabled OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property ClientCertProxyEnabled

MULTICAST CLUSTER PROPERTIES OF A DOMAIN

----------------------------------------

#TO VIEW Multicast Address OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property MulticastAddress

#TO VIEW Multicast Port OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property MulticastPort

#TO VIEW Multicast Send Delay OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property MulticastSendDelay

#TO VIEW Multicast TTL OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property MulticastTTL

#TO VIEW Multicast Buffer Size OF A CLUSTER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=Cluster,Name=Cluster1 -property MulticastBufferSize

NODEMANAGER PROPERTIES OF A DOMAIN

----------------------------------

#TO VIEW Listen Address OF A NODEMANAGER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=NodeManager,Name=NM -property ListenAddress

#TO VIEW Listen Port OF A NODEMANAGER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=NodeManager,Name=NM -property ListenPort

#TO VIEW Debug Enabled OF A NODEMANAGER

java weblogic.Admin -url localhost:7007 -username weblogic -password weblogic GET -mbean anup:Type=NodeManager,Name=NM -property DebugEnabled

WLST Unplugged

# TO CONNECTING TO A WEBLOGIC SERVER INSTANCE THROUGH AN SSL LISTEN PORT

java -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.WLST

# TO CONNECT TO WEBLOGIC SERVER WITHOUT SSL

java weblogic.WLST

# JYTHON SYNTAX FOR SPECIFYING THE PATH(\)

readTemplate(r'c:\mytemplate.jar')

# TO CONNECT TO RUNNING SERVER IN WLST(on default port(7001))

connect('username','password')

# TO CONNECT TO RUNNING SERVER IN WLST(on user specified port)

connect('username','password','localhost:7007')

# CREATING A DOMAIN (Offline)

We can create a domain by using WLST in 2 ways:

1. Create a new domain using a specified template.

createDomain(domainTemplate,domainDir, user, password)

EX.

createDomain('D:/WLS/WLS922/weblogic92/common/templates/domains/wls.jar','D:/WLS/WLS922/user_projects/domains/base_domain','weblogic','weblogic')

2.

1. Open an existing domain template for domain creation

readTemplate(templateFileName)

2. Modify the domain (optional)

Various commands

3. Set the password for the default user, if it is not already set

cd('/Security/domainname/User/username')

cmo.setPassword('password')

4. Write the domain configuration information to the specified directory

writeDomain(domainDir)

5. Close the current domain template

closeTemplate()

# UPDATING AN EXISTING DOMAIN (Offline)

1. Open an existing domain for update

readDomain(domainDirName)

2. Extend the current domain (optional)

addTemplate(templateFileName)

3. Modify the domain (optional)

Various commands

4. Save the domain

updateDomain()

5. Close the domain

closeDomain()

# BROWSING AND ACCESSING INFORMATION ABOUT THE CONFIGURATION BEAN HIERARCHY (Offline)

EXAMPLES

1. Navigate the hierarchy of configuration beans

cd(path) cd('Servers/MS1')

2. List child attributes or configuration beans for the current configuration bean

ls(['a' | 'c']) ls()

3. Toggle the display of the configuration bean navigation path information at the prompt

prompt(['off'|'on']) prompt('off')

4. Display the current location in the configuration bean hierarchy

pwd() pwd()

5. Display all variables used by WLST

dumpVariables() dumpVariables()

6. Display the stack trace from the last exception that occurred while performing a WLST action

dumpStack() dumpStack()

# EDITING A DOMAIN (Offline)

1. Assign configuration beans

assign(sourceType, sourceName,destinationType, destinationName)

2. Unassign configuration beans

unassign(sourceType, sourceName,destinationType, destinationName)

3. Create and delete configuration beans

create(name, childMBeanType)

delete(name, childMBeanType)

4. Get and set attribute values

get(attrName)

set(attrName, value)

5. Set configuration options

setOption(optionName, value)

6. Load SQL files into a database

loadDB(dbVersion, connectionPoolName)

# EXPORTING DIAGNOSTICS DATA (Offline)

Execute a query against the specified log file

exportDiagnosticData([options])

# CHANGING THE CURRENT MANAGEMENT OBJECT(CMO)

When you navigate to an MBean type, the value of cmo reflects the parent MBean.

When you navigate to an MBean instance, WLST changes the value of cmo to be the currentMBean instance

command cmo

# DISPLAYING CONFIGURATION MBEANS

the ls command lists all the child MBeans and attributes.

command ls()

NOTE:

1. In the ls command output information, d designates an MBean with which you can use the cd

command (analogous to a directory in a file system), r indicates a readable property, w indicates

a writeable property, and x an executable operation.

2. The ls command property information is based on MBeanInfo; it does not reflect user permissions.

To navigate back to a parent MBean

cd(’..’)

To get back to the root MBean after navigating to an MBean that is deep in the hierarchy

cd(’/’)

# BROWSING RUNTIME MBEANS

serverRuntime ----> When connected to a Managed Server, the root of the runtime MBeans is ServerRuntimeMBean.

domainRuntime ----> the domainRuntime command, at the root of the domain-wide runtime management objects, DomainRuntimeMBean.

# NAVIGATING AMONG MBEAN HIERARCHIES

STEPS TO NAVIGATE AMONG MBEAN HIERARCHIES:

1. To navigate to a configuration MBean from the runtime hierarchy, enter the serverConfig or domainConfig.

2. You navigate through directories(which are server directories AdminServers,managedServers)

example: cd('Servers/AdminServers')--->cd('Log/AdminServer')

3. Then you enter serverRuntime() command

4. You navigate through directories(runtime MBeans directories)

example: cd('JVMRuntime/AdminServer')

5. you enter serverConfig() command, it returns previous navigate path(Log/AdminServer path).

6. you enter serverRuntime() command, it returns previous navigate path(JVMRuntime/AdminServer path).

Alternatively, you can use the currentTree command to store your current MBean hierarchy location and to return to that location after navigating away from it.

STEPS:

1. In serverConfig naviagated path enter the following command

myLocation = currentTree()

2. In serverRuntime navigated path enter following command

myLocation()

it returns the serverConfig path which already navigated through it and that is stored in currentTree()

# FINDING MBEANS

To locate a particular MBean and attribute, you use the find command. WLST returns the pathname to the MBean that stores the attribute and its value. You can use the getMBean

command to return the MBean specified by the path.

EXAMPLES:

1. find('logfilename') ---> it returns the paths that where this files are exists.

2. a. bean=getMBean('Servers/myserver')

b. print bean ---> it returns mbean of that particular server with Name and Type

3. a. path=getPath('com.bea:Name=myserver,Type=Server')

b. print path ---> it returns path to specified type(Server)

# ACCESSING CUSTOM MBEANS

WebLogic Server provides hundreds of MBeans, many of which you use to configure and monitor EJBs, Web applications, and other deployable J2EE modules. If you want to use

additional MBeans to configure your applications or resources, you can create and register your own MBeans within the MBean Server subsystem on the Administration Server.

To navigate custom MBeans, enter the custom command when WLST is connected to an

Administration Server or a Managed Server instance.

command() ---> it returns all MBeans that are defined by users...

# EDITING CONFIGURATION MBEANS

STEPS:

1. edit()

2. startEdit()

3. editing commands (create,invoke,delete) EXAMPLE: cmo.createServer('MS1')

4. save()

5. undo() (optional) i.e., You can make additional changes, without re-entering the startEdit command

6. activate() i.e., When you are ready to distribute your changes to the working configuration MBeans

7. stopEdit() or cancelEdit() (optional) i.e., you can abandon your changes

getActivationTask() ---> provides information about the activation request and returns the latest ActivationTaskMBean

# MANAGING SERVERS AND SERVER LIFE CYCLE

During its lifetime, a server can transition through a number of operational states, such as shutdown, starting, standby, admin, resuming, and running. WLST commands such as start,

suspend, resume, and shutdown cause specific changes to the state of a server instance.

# STARTING AND STOPPING SERVERS

# STARTING AN ADMIN SERVER WITHOUT NODE MANAGER

1. open command prompt and navigate to domains directory

EX: cd D:\WLS\WLS922\user_projects\domains\base_domain

2. set the path i.e., setDomainEnv.cmd(in \base_domain\bin)

3. java weblogic.WLST

4. Use the WLST startServer command to start the Administration Server.

SYNTAX:startServer([adminServerName], [domainName], [url], [username],

[password],[domainDir], [block], [timeout], [serverLog],

[systemProperties], [jvmArgs])

EXAMPLE: startServer('AdminServer','base_domain','localhost:7001','weblogic','weblogic','D:/WLS/WLS922user_projects/base_domain','true',60000,'false')

# STARTING MANAGED SERVERS AND CLUSTERS WITH NODE MANAGER

1. FOLLOW ABOVE UPTO 2ND STEPS

2. java weblogic.WLST

3. startNodeManager()

4. TAKE ANOTHER COMMAND PROMPT START ADMIN SERVER

5. TAKE ANOTHER COMMAND PROMPT

java weblogic.WLST

6. start('MS1','Server') or start('MS1','Server','localhost:7003')

7. start('mycluster','Cluster')

# USING WLST AND NODE MANAGER TO MANAGE SERVERS

# START ADMIN SERVER USING NODE MANAGER

The following example uses WLST Node Manager commands to start, monitor, and stop an Administration Server.

1. java weblogic.WLST

2. startNodeManager()

3. connect to the node manager

SYNTAX: nmConnect('username','password','nmHost','nmPort','domainName','domainDir','nmType')

EXAMPLE: nmConnect('weblogic','weblogic','localhost','5556','base_domain','D:/WLS/WLS922user_projects/domains/base_domain') ------> for general

nmConnect('weblogic','weblogic','localhost','5556','base_domain','D:/WLS/WLS922/user_projects/domains/base_domain','ssl')------> for SSL

4. Use the nmStart command to start an Administration Server.

SYNTAX: nmStart('ADMINSERVER_NAME')

EXAMPLE: nmStart('AdminServer')

5. Monitor the status of the server you started by entering the nmServerStatus command

SYNTAX: nmServerStatus('ADMINSERVER_NAME')

EXAMPLE: nmServerStatus('AdminServer')

6. Stop the server by entering the nmKill command.

SYNTAX: nmKill('ADMINSERVER_NAME')

EXAMPLE: nmKill('AdminServer')

# MONITORING SERVER STATE

# TO RETURN THE STATE OF A SERVER or CLUSTER.

state('managed1','Server')

# OVER VIEW OF WSLT COMMAND CATEGORIES

WLST commands are divided into the following categories.

1. Browse Commands ------> • Navigate the hierarchy of configuration or runtime beans

and control the prompt display.

2. Control Commands ------> • Connect to or disconnect from a server.

• Create and configure a WebLogic domain or domain template.

• Exit WLST.

3. Deployment Commands ------> • Deploy, undeploy, and redeploy applications and standalone

modules to a WebLogic Server instance.

• Update an existing deployment plan.

• Interrogate the WebLogic Deployment Manager object.

• Start and stop a deployed application.

4. Diagnostics Commands ------> • Export diagnostic data.

5. Editing Commands ------> • Interrogate and edit configuration beans.

6. Information Commands ------> • Interrogate domains, servers, and variables, and provide configuration bean,

runtime bean, and WLST-related information.

7. Life Cycle Commands ------> • Manage the life cycle of a server instance

8. Node Manager Commands------> • Start, shut down, restart, and monitor WebLogic Server instances using Node Manager.

9. Tree Commands ------> • Navigate among MBean hierarchies.

# BROWSE COMMANDS

1. cd Navigate the hierarchy of configuration or runtime beans. Online or Offline

2. currentTree Return the current location in the hierarchy. Online

3. prompt Toggle the display of path information at the prompt. Online or Offline

4. pwd Display the current location in the hierarchy. Online or Offline

cd

---

cd('..') The character string ..(dot-dot), refers to the directory immediately above the current

directory.

cd('/') To get back to the root bean after navigating to a bean that is deep in the hierarchy.

currentTree

-----------

currentTree() stores the current location in the hierarchy.

prompt

------

prompt(myPrompt)

Toggles the display of path information at the prompt, when entered without an argument.

prompt(off)

When you specify off, WLST hides the WLST prompt and defaults to the Jython prompt.

prompt(on) It displays the path information in prompt.

pwd

----

pwd Displays the current location in the configuration or runtime bean hierarchy.

# CONTROL COMMANDS

Connect to and “connect” Connect WLST to a WebLogic Server instance.

- Online or Offline

disconnect from a “disconnect” Disconnect WLST from a WebLogic Server instance.

WebLogic Server

instance - Online

Create a new domain “createDomain” Create a new domain using the specified template.

from a domain template

- Offline

Read a domain from “readTemplate” Open an existing domain template for domain

domain template

- Offline

Create a domain “writeDomain” Write the domain configurationinformation to the template

- Offline

Close the “closeTemplate” Close the current domain template.

template

- Offline

Update an existing “readDomain” Open an existing domain for updating.

domain - Offline

“addTemplate” Extend the current domain using an

application or service extension template.

“updateDomain” Update and save the current domain.

“closeDomain” Close the current domain.

Write a domain “writeTemplate” Writes the configuration information to the

template specified domain template file.

- Offline

Exit WLST “exit” Exit WLST from the interactive session and close

- Online or Offline the scripting shell.

addTemplate addTemplate Extends the current domain using an application

- Offline or service extension template.

closeDomain closeDomain Closes the current domain. The domain is no

- Offline longer available for editing once it is closed.

closeTemplate closeTemplate Closes the current template. The domain is no

Offline longer available for editing once it is closed.

connect connect Connect WLST to a WebLogic Server instance.

- Online or Offline

EXAMPLE:

1.connect() -------->

a. WLST searches for the default user configuration and key files that contain an encrypted username and password. This information must be valid for your current domain.

b. If the connect command was run from the domain directory in which the server was started, WLST attempts to load the username and password from the boot.properties file.

c. WLST prompts for a username, password, and URL.

2.connect('username','password','url','AdminServerName')

3.connect('username','password','url')

4.connect('username','password') ------> for default server port (7001)

5.connect([userConfigFile, userKeyFile], [adminServerName])

6.connect([userConfigFile, userKeyFile], [url], [adminServerName])

7.connect([userConfigFile, userKeyFile]) ------> for default server port (7001)

8. a. username = 'weblogic'

b. password = 'weblogic'

c. connect(username,password,'t3://myhost:8001')

9. a. username = 'weblogic'

b. password = 'weblogic'

c. connect(username,password) ------> for default server port (7001)