Friday 26 February 2016

Pack and unpack

WLS_HOME  is an environment variable maps to your “wlserver<version>” directory 


Dir:
opt/middleware/bea10.3/wlserver_10.3/

Execute Following command:

$WL_HOME/common/bin dir 

pack.sh  –managed=true –domain=<domain name> -template=<domain_name.jar> -template_name=”<description>”

pack.sh  –managed=true –domain=mydomain -template=mydomain.jar -template_name=”mydomain template”
Now copy the jar file into another machine 

Unpacking :
command under $WL_HOME/common/bin location
unpack.sh –domain=<domain name> -template=<jar file name>
unpack.sh –domain=mydomain  -template=mydomain.jar


Default  template:
pack-domain=path_of_domain-template=path_of_jara_file_to_create -template_name=”template_name”[-template_author=”author”][-template_desc=”description”] [-managed=true|false][-log=log_file] [-log_priority=log_priority]
unpack-template=path_of_jara_file-domain=path_of_domain_to_be_created[-user_name=username] [-password=password] [-app_dir=application_directory][-java_home=java_home_directory] [-server_start_mode=dev|prod] [-log=log_file][-log_priority=log_priority]


JVM Crash and Native OutOfMemory Exception

JVM Crash Investigation

JVM Core Dump is the most important File to investigate the JVM Crash. By default the Core Dump will be generated. But Just in case if JVM is not able to generate the Core Dump then there may be the following reasons: 

  • If there is not enough disk space or quota to write the file in your File System.  
  • If JVM is not having to create or write a file in the directory. 
  • If another file exists in the same directory with that is read-only or write-protected. Unix/Linux-specific: Use the limit or ulimit commands to determine if core dumps are disabled.  

Example, on Linux, the command “ulimit -c unlimited” enables core dumps to be written, no matter what their size. Core dump sizes can be restricted if disk space limitations are a concern. 
It may be possible to get a thread dump before the process exits. HotSpot supports the Java_Option -XX:+ShowMessageBoxOnError; the corresponding JRockit option is -Djrockit.waitonerror. When the JVM is crashing, it may prompt the user :::Do you want to debug the problem?::: This pauses the process, thereby creating an opportunity to generate a thread dump (a stack trace of every thread in the JVM), attach a debugger, or perform some other debugging activity. However, this does not work in all cases (for eg., in case of stack overflow). 

Crash Because of OutOfMemory: Please apply the Following Flag in your JAVA_OPTIONS in the start Script of your Server: 
-XX:+HeapDumpOnOutOfMemoryError 

 Details: 

1) -XX:+HeapDumpOnOutOfMemoryError option available in 1.5.0_07 and 1.4.2_12, producing an hprof binary format heap dump (By default the DUMP will be generated in your Systems TEMP directory….In Window machine we can easily findout the TEMP directory by running the command “echo %TEMP%”) 

 2) Analyse hprof heap dumps using HAT, or jhat or YourKit (has an hprof import option) hprof heap dumps are platform independent and so you don’t need to analyze the dump on the same system that produced it. 

3) running with -XX:+HeapDumpOnOutOfMemoryError does not impact performance – it is simply a flag to indicate that a heap dump should be generated when the first thread throws OutOfMemoryError. 

 4) -XX:+HeapDumpOnOutOfMemoryError does not work with -XX:+UseConcMarkSweepGC in 1.5.0_07 

TestCase: 

public class TestXss
{
public static void main(final String[] args) throws Exception
{
 // start the given number of threads
 for (int i = 1; i <= Integer.parseInt(args[0]); i++)
  {
    System.out.println("Starting Thread " + i);
    final Thread t = new Thread("T[" + i + "]")
     {
       public void run()
        { 
          try
            {
              while (true)
                {
                  Thread.sleep(1000);
                }
            }
          catch (Exception e)
           {
             e.printStackTrace();
           }
       }
    };
  t.setDaemon(true);
  t.start();
  Thread.sleep(5);
 }
// wait 22 Thread.sleep(1000000);
}
}
Output:

NOTE:   java -Xmx1496m -Xss1m TestXss 5000
Starting Thread 411
Starting Thread 412
Starting Thread 413
Starting Thread 414
Starting Thread 415
Starting Thread 416
Starting Thread 417
Exception in thread “main” java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:574)
at TestXss.main(TestXss.java:18)


Note: If you see OOM in the Native Space  ( unable to create new native thread) Then Please first of all Try to decrease the -Xss size. It’s default value is -Xss512K   ———>Reduce it to ——–>  -Xss256K

Like this you will see that JVm is able to create more Native Threads…But beware that if u will decrease it more than a certain limit …u may start getting “java.lang.StackOverflowError”

To Create & Test a Virtual Host

1. Edit your hosts file and map your domain / DNS name to the server ip address. 
Unix - /etc/hosts
Window - C:\WINDOWS\system32\drivers\etc\hosts

In Window entry should be like below -
127.0.0.1       localhost lakshmiweblogicadmin.blogspot.com


2.Create a virtual host, Click on Virtual Hosts, New, Enter name for virtual host.

3.Click on name of virtual host and in "Virtual Hosts Names" field enter your domain name like here,lakshmiweblogicadmin.blogspot.com, if you more then one domain name mapped enter each separated by comma

4.
Click on target tab and select managed or admin server wherever you want to target,
5. Deploy your application on virtual host ( select deployment to deploy and target should be virtual host )
6.
Create a channel
Click on managed or admin server on which you you targeted to virtual host, select channels under protocols on right hand side
Click on new
Enter channel name & select protocol http, select next
Enter port 80, select next
Select default options and click next
Select default option and click next
Click on finish

Now, you can see below lines in the server log file on which you targeted the virtual host -

<Oct 18, 2010 10:52:18 PM IST> <Notice> <Server> <BEA-002613> <Channel "Channel-
0" is now listening on 127.0.0.1:80 for protocols http.>

7.
Now instead of http://<server>:<port>/your_apps_url, access it like http://mukeshnegi.com/your_apps_url

For example - 

if you access your apps like http://localhost:7002/shoppingcart/welcome.jsp then access it like    http://lakshmiweblogicadmin.blogspot.com/shoppingcart/welcome.jsp


Virtual Host


Virtual hosting allows you to define host names that servers or clusters respond to.

When you use virtual hosting you use DNS to specify one or more host names that map to the IP address of a WebLogic Server instance or cluster, and you specify which Web Applications are served by the virtual host.

When used in a cluster, load balancing allows the most efficient use of your hardware, even if one of the DNS host names processes more requests than the others.
For example :-

you can specify that a Web Application called books responds to requests for the virtual host name www.books.com, and that these requests are targeted to WebLogic Servers A,B and C, while a Web Application called cars responds to the virtual host namewww.autos.com and these requests are targeted to WebLogic Servers D and E.

WLST ( Weblogic Scripting Tool )

Go to your_domain/bin and run below command

C:\Oracle\Middleware\user_projects\domains\base_domain\bin>java weblogic.WLST

What if you are getting below error just after invoking WLST
Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/WLST
Caused by: java.lang.ClassNotFoundException: weblogic.WLST
Run C:\Oracle\Middleware\user_projects\domains\base_domain\bin>setDomainEnv.cmd
Now you would able to connect with java weblogic.WLST command
Commands -

Node Manager Commands for WLST Configuration 

Command Enables you to… Use with WLST...
nm Determine whether WLST is connected to Node Manager. Online
nmConnect Connect WLST to Node Manager to establish a session. Online or Offline
nmDisconnect Disconnect WLST from a Node Manager session. Online or Offline
nmEnroll Enables the Node Manager on the current computer to manage servers in a specified WebLogic domain. Online
nmGenBootStartupProps Generates the Node Manager property files, boot.properties and startup.properties, for the specified server. Online
nmKill Kill the specified server instance that was started with Node Manager. Online or Offline
nmLog Return the Node Manager log. Online or Offline
nmServerLog Return the server output log of the server that was started with Node Manager. Online or Offline
nmServerStatus Return the status of the server that was started with Node Manager. Online or Offline
nmStart Start a server in the current WebLogic domain using Node Manager. Online or Offline
nmVersion Return the Node Manager version. Online or Offline
startNodeManager Starts Node Manager on the same computer that is running WLST. Online or Offline
stopNodeManager Stops Node Manager. Online or Offline

wls:/offline>
Take help on online or offline commands 
help("online")
help("offline")
Start Node Manager
startNodeManager(verbose="true",NodeManagerHome="D:/Oracle/Middleware/wlserver_10.3/common/nodemanager",ListenPort="5557",ListenAddress="localhost")
where -
Node Manager Home - D:/Oracle/Middleware/wlserver_10.3/common/nodemanager
Node Manager Host host - localhost
Node Manager port - 5557

Connect with node manager
nmConnect("weblogic","webl0gic","localhost","5557","base_domain","D:/Oracle/Middleware/user_projects/domains/base_domain","plain")
To check if you already connect with node manager or not
nm()
Output
wls:/Bank_Domain1/serverConfig> nm()
Currently connected to Node Manager to monitor the domain JJTU_Domain1.
Start Admin server using node manager
nmStart("AdminServer")
where "AdminServer" is the name of your admin server.
Check Admin Server Status unsing nodemanager
nmServerStatus('AdminServer')
where "AdminServer" is the name of your admin server.
Connect to Admin Server
connect("weblogic","webl0gic","localhost:7001")
where -
admin user - weblogic
admin password=webl0gic
weblogic host - localhost
admin port - 7001
Start Managed Server using nodemanager
nmStart('server_name')
Output
wls:/Bank_Domain1/serverConfig> nmStart('C_Server1')
Starting server C_Server1 ...
Successfully started server C_Server1 ...
Start Managed Server
Start(“MS1”)
Where MS1 is the name of your managed server
To kill server using node manager
nmKill('server_name')

Output

wls:/Bank_Domain1/serverConfig> nmKill('C_Server1')
Killing server C_Server1 ...
Successfully killed server C_Server1 ...
To check node manager status
nmVersion()

Output
wls:/Bank_Domain1/serverConfig> nmVersion()
The Node Manager version that you are currently connected to is 10.3.
Domain enrollment with nmEnroll()
nmEnroll()
NmEnroll is used to enroll a machine or you can say to enroll a domain with the node manager because if you have multiple domains ( of different installer ) running on a host then you can handle all with a single node manager but you have have to enroll each domain with the same node manager.
   This is applicable if you have domains from different oracle_home or you can say from different installer on same host ( means you have more than one installation of weblogic on same host with each installer having its different host ).
If you are creating multiple domains from single installer then no need to enroll because it will enroll automatically.

So to enroll a machine or domain with a particular node manager, follow below steps

1. Start Admin server of domain which you want to enroll with node manager

2. Go to wlst prompt ( go to your_domain, run setDomainEnv and then "java weblogic.WLST")

3. Connect with admin server
    connect("user","password","host:admin_port")

4. Run nmEnroll command
 nmEnroll('C:/Oracle/Middleware/wlserver_12.1/common/nodemanager')
  Where "C:/Oracle/Middleware/wlserver_12.1/common/nodemanager" is the node manager  
   home of node manager with which you want to enroll your domain
5. Update nodemanager.domains under node manager home and add your domain path in    
    same format as earlier domains path there, like below i have added domain in red
JJTU_Domain1=C\:\\Oracle\\Middleware2\\user_projects\\domains\\JJTU_Domain1
 base_domain=C\:\\Oracle\\Middleware2\\user_projects\\domains\\base_domain  
6. Update node manager password ( username also if not correct there ) from admin console
    ( login to admin console > click on your domain name on left hand side > click on security tab
     on right hand side > click on Advance link > update node manager password ( username
     also if not correct there )

Now you can able to connect with node manager
wls:/base_domain/serverConfig> nmConnect("weblogic","weblogic123","localhost","40046","base_domain","C:/Oracle/Middleware2/user_projects/domains/base_domain","plain")
Connecting to Node Manager ...
Successfully Connected to Node Manager.
Note 1 - 
If you are getting below error during connect with node manager, then it means you haven't changed username,password for nodemanager from admin console ( above step 6 )
WLSTException: Error occured while performing nmConnect : Cannot connect to Node Manager. : Access to domain 'base_domain' for user 'weblogic' denied
Note 2 - 
If you are getting below error during connect of node manager then it mean you haven't followed above defined steps OR haven't added your domain on nodemanager.domains
WLSTException: Error occured while performing nmConnect : Cannot connect to Node Manager. : Configuration error while reading domain directory
Disconnect from node manager
nmDisconnect()
Output()
wls:/Bank_Domain1/serverConfig> nmDisconnect()
Successfully disconnected from Node Manager.
Stop Node Manager
StopNodeManager()

Output
wls:/Bank_Domain1/serverConfig> stopNodeManager()
Stopped NodeManager successfully

COMPARISON BETWEEN CLUSTER MULTICAST MESSAGING AND UNICAST MESSAGING MODE

When servers are in a cluster, these member servers communicate with each other by sending heartbeats and indicating that they are alive. For this communication between the servers, either unicast or multicast messaging is used. This is chosen from the admin console in Cluster -> Configuration -> Messaging -> Messaging Mode.
To use multicast messaging, hardware configuration and support for multicast packets is required. Unicast does not have this requirement, which is why using unicast in latest versions is recommended.
When multicast messaging is used, it is a one-to-many communication, every server sends the notification/heartbeat/multicast packet to each other. This causes a heavy load on the application’s multicast buffer, so if the buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are dropped. So there is a possibility that the server instances miss the messages. This might lead in the cluster throwing out the server instances out of the cluster.
Unicast configuration is much easier because it does not require cross network configuration that multicast requires. Additionally, it reduces potential network errors that can occur from multicast address conflicts.
Mode of Communication:
Multicast – A multicast address and multicast port is used for listening to the messages.
Unicast – A network channel is used for communication between the servers. If no channel is specified, default network channel is used.

Method of communication between servers:
Multicast – Each server communicates with every member server in the cluster. Which means heartbeats are sent to every server.
Unicast - For the member servers in the cluster, group leaders are chosen and only those group leaders communicate with the servers among the group and these leaders notify each other about the availability of all the other servers.
For example : Suppose there are 6 servers in the cluster. 2 groups are made and there are 2 group leaders. Other 2 servers of the group will notify their leader that they are alive and the group leader will send this information to the leader of other group.
The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.
For new server versions, using unicast is recommended because it is a simplified communication mode. But for backward compatibility with the previous versions, you will need to use multicast if there is a communication requirement between clusters of versions prior to WLS 10.0.
Whenever the messaging mode of the cluster is changed, all the servers in the cluster need a restart because the changes are not dynamic.
If you have any questions regarding unicast and multicast messaging mode, please let us know about it.

Configure, Start & Stop Node Manager : Step by Step

To configure Node Manager -

Log in to weblogic Admin Console

Click on Environments -> Machines tab on left hand side


Click on new tab on right hand side



Enter name of machine and select Machine OS as unix if you are on unix machine otherwise default, click ok

Noe click on created machine

Select type plain, enter listen address and port 
To check status :-

Start node manager, click on  machine name, click on Monitoring -> Node Manager Status

click on node manager tab, Status should be Reachable.
How to start Node Manager ?


$WL_HOME\server\bin\startNodeManager.sh  (startNodeManager.cmd on Windows)
$WL_HOME\server\bin  called NM_HOME, For Example - D:\Oracle\Middleware\wlserver_10.3\server\bin
To Stop Node Manager 

In Unix/Linux, kill the process - 


kill -9 `ps -ef | grep -i nodemanager.javahome | grep -v grep | awk {'print $2'} | head -1`

On window machine, close the window on which Node Manager started.

Node Manager Log Files

$WL_HOME/common/nodemanager/nodemanager.log


Important configuration file for node manager 

$WL_HOME/common/nodemanager/nodemanager.properties- used by java based node manager. This file is created on first time start of nodemanager (startNodeManager.sh)


$WL_HOME/common/nodemanager/nodemanager.domains - contains mappings between the names of domains managed by Node Manager and their corresponding directories.
entry like
base_domain=D:\Oracle\Middleware\user_projects\domains\base_domain
soa_domain=D:\Oracle\Middleware\user_projects\domains\soa_domain


$WL_HOME/common/nodemanager/nm_data.properties- This file stores the encryption data the Node Manager uses as asymmetric encryption key. This file is created on first time start of nodemanager (startNodeManager.sh)


$DOMAIN_HOME/config/nodemanager/nm_password.properties- This file stores the Node Manager username and password used by Admin Server to connect to Node Manager.

Few other configuration files are boot.properties, startup.properties,server_name.addr, server_name.lck, server_name.pid, server_name.state




Horizontal Clustering : Step by Step

Cluster across multiple physical machines

Horizontal clustering involves running multiple Java application servers that are run on two or more separate physical machines.


Like shown below where all the managed servers are in a cluster -


Machine-1

- Admin Server
- MS-1
- MS-2Machine-2
- MS-3
- MS-4

How to do Horizontal Clustering ?


1. Install weblogic server on both machines with same installation directories.

2. Create domain on primary machine where you want your Admin server and copy domain to second machine.

Step by Step -


1. Install weblogic server on both machines with same installation directories. 


2. Start domain wizard on primary & select option "create a new weblogic domain".



3. Select default first option




4. Enter a name for your domain



5. Enter Admin Server credentials, username & password


6. Select your mode ( development or production ) and jdk 


you want to use


7.Select below two options


Admin Server Name, listen address, port & enable ssl if 

required


9.  Add the number of managed servers you want for your 

domain, enter listen address, port & ssl information if 

required.


10. Create cluster


11. Assign all managed servers to the cluster ( click on each 

server one by one and click on right arrow )



12. This is the turning point for horizontal clustering -

Create two machines ( usually create it with the name of 

machines, suppose you ant clustering between to machines 

with hostname like hostname1.something.com & 

 hostname2.something.com, then create machine names like 

hostname1 & hostname2 )

Enter listen address of particular machine ( server ), like for 

mac1 enter listen address of      hostname1.something.com & 

for mac2, enter listen address of hostname2.something.com )

Enter port for nodemanager


13. Assign MS1 & MS2 to mac1 & MS3 & MS4 to Mac2, this

 will allow nodemanager to start managed  server 1 & 2 on

 machine1 ( hostname1.something.com ) and start managed

 server 3 & 4 on machine 2 (  hostname2.something.com )

14. Select create button.

Now go to Middleware Directory,  D:\Oracle\Middleware, 

make a copy of user_projects, copy it under same folder on 

another machine ( D:\Oracle\Middleware on machine 2 ).

Now start your managed servers

MSI mode in weblogic

When a Managed Server starts, it tries to contact the Administration Server to retrieve its configuration information. If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading configuration and security files directly. A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode. By default, MSI mode is enabled.
In Managed Server Independence mode, a Managed Server looks in its root directory for the following files:
      msi-config.xml—a replica of the domain’s config.xml
      SerializedSystemIni.dat
      boot.properties—an optional file that contains an encrypted version of your username
configuration files for managed server in MSI mode

If you enable replication of configuration data and if you have started the Managed Server at least once while the Administration Server was running, msi-config.xml and SerializedSystemIni.dat will already be in the server’s root directory. The boot.properties file is not replicated. If it is not already in the Managed Server’s root directory, you must create one.
If msi-config.xml and SerializedSystemIni.dat are not in the root directory, you can either:
      Copy config.xml and SerializedSystemIni.dat from the Administration Server’s root directory (or from a backup) to the Managed Server’s root directory. Then, rename the configuration file to msi-config.xml, or
      Use the -Dweblogic.RootDirectory=path startup option to specify a directory that already contains these files
  you may have noticed password values that look like "{3DES}bOH6MEd8S82sxg2Nk=" in config.xml file . This is how WebLogic stores passwords encrypted with the "Triple DES" algorithm (see here for a description of 3DES).

When WebLogic stores or retrieves one of these passwords, it uses a hash key which is stored in the SerializedSystemIni.dat file.


MSI Mode and the Domain Log File

Each WebLogic Server instance writes log messages to its local log file and a domain-wide log file. The domain log file provides a central location from which to view messages from all servers in a domain.

Usually, a Managed Server forwards messages to the Administration Server, and the Administration Server writes the messages to the domain log file. However, when a Managed Server runs in MSI mode, it assumes the role of writing to the domain log file.

By default, the pathnames for local log files and domain log files are relative to the Manged Server’s root directory. 
       With these default settings, if a Managed Server is located in its own root directory (and it does not share its root directory with the Administration Server), when it runs in MSI mode the Managed Server will create its own domain log file in its root directory. If a Managed Server shares its root directory with the Administration Server, or if you specified an absolute pathname to the domain log, the Managed Server in MSI mode will write to the domain log file that the Administration Server created.

Note: The Managed Server must have permission to write to the existing file. If you run the Administration Server and Managed Servers under different operating system accounts, you must modify the file permissions of the domain log file so that both user accounts have write permission.

MSI Mode and the Security Realm:
A Managed Server must have access to a security realm to complete its startup process. If you use the security realm that WebLogic Server installs, then the Administration Server maintains an LDAP server to store the domain’s security data. All Managed Servers replicate this LDAP server. If the Administration Server fails, Managed Servers running in MSI mode use the replicated LDAP server for security services. If you use a third party security provider, then the Managed Server must be able to access the security data before it can complete its startup process.
MSI Mode and SSL
If you set up SSL for your servers, each server requires its own set of certificate files, key files, and other SSL-related files. Managed Servers do not retrieve SSL-related files from the Administration Server (though the domain’s configuration file does store the pathnames to those files for each server). Starting in MSI Mode does not require you to copy or move the SSL-related files unless they are located on a machine that is inaccessible.   
MSI Mode and Deployment
A Managed Server that starts in MSI mode deploys its applications from its staging directory: serverroot/stage/appName.
MSI Mode and Managed Server Configuration Changes
If you start a Managed Server in MSI mode, you cannot change its configuration until it restores communication with the Administration Server.

MSI Mode and Node Manager

You cannot use Node Manager to start a server instance in MSI mode, only to restart it. For a routine startup, Node Manager requires access to the Administration Server. If the Administration Server is unavailable, you must log onto Managed Server’s host machine to start the Managed Server.

MSI Mode and Configuration File Replication

Managed Server Independence mode includes an option that copies the required configuration files into the Managed Server's root directory every 5 minutes. This option does not replicate a boot identity file.

By default, a Managed Server does not replicate these files. Depending on your backup schemes and the frequency with which you update your domain's configuration, this option might not be worth the performance cost of copying potentially large files across a network.


MSI Mode and Restored Communication with an Administration Server

When the Administration Server starts, it can detect the presence of running Managed Servers (if -Dweblogic.management.discover=true, which is the default setting for this property). Upon startup, the Administration Server looks at a persisted copy of the file running-managed-servers.xml and notifies all the Managed Servers listed in the file of its
presence.

Managed Servers that were started in Managed Server Independence Mode while the Administration Server was unavailable will not appear in running-managed-servers.xml. To re-establish a connection between the Administration Server and such Managed Servers, use the weblogic.Admin DISCOVERMANAGEDSERVER command.


When an Administration Server starts up and contacts a Managed Server running in MSI mode, the Managed Server deactivates MSI mode and registers itself to the Administration Server for future configuration change notifications


Starting a Managed Server When the Administration Server Is Not Accessible

If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading locally cached configuration data. A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode.

Note: If the Managed Server that failed was a clustered Managed Server that was the active server for a migratable service at the time of failure, perform the steps described in “Migrating When the Currently Active Host is Unavailable”

Clusters. Do not start the Managed Server in MSI mode.
To start up a Managed Server in MSI mode:
1. Ensure that the following files are available in the Managed Server’s root directory:
      msi-config.xml.
       SerializedSystemIni.dat
     boot.properties
If these files are not in the Managed Server’s root directory:
a. Copy the config.xml and SerializedSystemIni.dat file from the Administration Server’s root directory (or from a backup) to the Managed Server’s root directory.
b. Rename the configuration file to msi-config.xml. When you start the server, it will use the copied configuration files.
Note: Alternatively, you can use the -Dweblogic.RootDirectory=path startup option to specify a root directory that already contains these files.
2. Start the Managed Server at the command line or using a script.
Note:The Managed Server will run in MSI mode until it is contacted by its Administration Server.
         Starting from version 7 WebLogic managed servers can be started in the absence of an administration server. The feature that will enable a managed server to come up in the absence of administration server (MSI mode) is enabled by default. But some of the files required for MSI mode are only sent to the managed server only when another option (MSI file replication enabled) is ON.
         This feature is same in version 8 except that the config.xml being copied and cached in the managed server is stored as msi-config.xml.
         In version 9 the feature is still the same except that the complete config directory that contains the configuration file is copied by default to the managed servers. But some other files like the security (*.dat) file is not copied until the MSI file replication enabled option is ON.
         Version 10 alleviate all the pains by making MSI mode and MSI file replication as a default option. So out of the box a managed server is enabled to run in independence mode. And all the files required to start a managed server by itself (/config dir and *.dat file) will be automatically copied to the managed server during startup and will be synced (automatically) with the master copy (in Admin Server).

Deployment

Steps for java command line deployment
1)set the class path to execute java commands - setDomainEnvcmd
2)execute java command for deployment – java weblogicDeployer
Java weblogicDeployer  –adminurl  t3://localhost:7001   –username  weblogic  –password  weblogic       –name  benefits  –source  path\benefitswar  –targets ms1,ms2  –deploy

Modes of deployment:

Staging mode:  The admin server copies the deployment unit files to the staging directories of target servers and they are deployed using the local copy
This mode is useful when deploying  small or moderate size applications
This is default staging mode for managed servers 
No stage mode:   The deployment units are deployed using the same physical copy  which must accessible by the admin server and target servers
This mode is useful when deploying large  applications to multiple targets
This is default staging mode for adminservers
External stage: we must copy the deployments units manually to the correct staging directories  before deployment
We will use this mode for deployments when we want to manually control the distribution of deployment files to target servers.

Need to clear weblogic cache

  • shut down the server
  • delete the contents of the folder:
  • Path of ur \servers\server_name\tmp\wl_user
  • Restart the server.

What is jar,war and ear files:
Jar:  
java archive files intended to hold generic libraries of java classes ,Resources,Auxillary,files 
It  is Used for J2ee for packaging EJB’s  & client side java applications.

War : 
Web archive files intended to contain complete web applications
Mainly  for web applications made from servlets , jsp’s supporting classes.

Ear : 
Enterprise archive files intended to contain complete enterprise applications

Describe two phase deployment:
Mainly two states in two phase deployment:

1)prepare state
2)active state

Deployment first prepares the application across all the target servers and then activates the application in a separate phase
If  deployment of an application fails in either of the two phases then the cluster deployment is failed

Define  deployment descriptors? 


  •  It is a configuration file for web application or EJB application which is to be deployed to web or EJB container
  • Deployment descriptors describes the deployment settings of an application or module or component
  • Where it contains meta data describing the contents and structure of the enterprise beans, and runtime transaction and security information for EJB container.
  • It directs a deployment tool to deploy a module or application with specific container options and describes specific configuration requirements that a deployer must resolve.

What are the Deployment issues

  • Code issues
  • Out of memory issues
  • Connection pool issues
  • Clear cache issues
  • Library class path issues
  • Applications are not deployed