Q.How many types of weblogic installation ?
Ans:- There are 3 types of weblogic installation.
(a) Grapical Mode (interactive GUI based)
(b) Console Mode (interactive Text Based)
(c) Silent Mode ( Non Interactive method using .xml properties file (-mode =console -silent_xml =properties_xml_file).
Q. Difference between Unicast and Multicast?
Ans:- Unicast:- Unicast is a one-to one connection between the client and the server.
In cluster, In this concept one server 1st called server always acts like leader, every member interact with leader, 1st server when brings up it is a Leader.
The main difference between Unicast and Multicast is as follows
Unicast:
Say you have three servers (MS-1,MS-2,MS-3) in a cluster now if they have to communicate with each other they have to ping (i.e. heartbeats ) the cluster master for informing him that he is alive.
If MS-1 is the master then MS-2 and MS-3 would send the ping to MS-1
Multicast:
Here there is no cluster master each server has to ping each other to inform everyone that I am alive.
So MS-1 would send the ping to MS-2 & MS-3 same way MS-2 would send the ping to MS-1 & MS-3 and MS-3 would ping MS-1 & MS-3.
Thus if you see in multicast the congestion in sending the pings are more compared to unicast which makes multicast much heavier, thus WLS recommends using Unicast of less congestion in the network.
Multicast is a very old concept in this concept all managed server talks to eachother in every fraction of seond to show that they are alive.
Q. What is Cluster and Advantages of clustering?
Cluster:- “cluster is nothing but group or set of managed server so that we can handle tha task to avoid overloading. “Group of weblogic managed server instance that work together to provide Scalablity and High Availability”.
A WebLogic Server cluster provides these benefits:
- Scalability
The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service—the application continues to run without impact to clients and end users.
- High-Availability
In a WebLogic Server cluster, application processing can continue when a server instance fails. You “cluster” application components by deploying them on multiple server instances in the cluster—so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.
The choice to cluster WebLogic Server instances is transparent to application developers and clients. However, understanding the technical infrastructure that enables clustering will help programmers and administrators maximize the scalability and availability of their applications.
5.Different between stage and no stage deployment?
Stage Deployment:- Admin server Having the physical copy and it will distribute to remaining instances.
Staged deployment will copy your deployment units onto the deployment servers, place them into the $WL_HOME/servers/SERVER_NAME/stage directory and deploy them from there.
In stage mode, the Administration Server copies the deployment files from their original location on the Administration Server machine to the staging directories of each target server. For example, if you deploy a Java EE Application to three servers in a cluster using stage mode, the Administration Server copies the deployment files to directories on each of the three server machines. Each server then deploys the Java EE Application using its local copy of the archive files.
When copying files to the staging directory, the Administration Server creates a subdirectory with the same name as the deployment name. So if you deployed using the command:
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mytestear -stage -targets mycluster -deploy c:\bea\wlserver_10.0\samples\server\medrecd\dist\physicianEar
a new directory,
mytestear, would be created in the staging directory of each server in mycluster. If you do not specify a deployment name, a default deployment name (and staging subdirectory) is used:- For exploded archive deployments, the deployment name and staging subdirectory are the name of the directory you deployed (
physicianEarin the example above). - For archived deployments, the default deployment name is the name of the archive file without the extension. For example, if you deploy
physicianEar.ear, the deployment name and staging subdirectory arephysicianEar.
The Administration Console uses stage mode as the default mode when deploying to more than one WebLogic Server instance.
weblogic.Deployer uses the target server’s staging mode as the default, and Managed Servers use stage mode by default.
Stage mode ensures that each server has a local copy of the deployment files on hand, even if a network outage makes the Administration Server unreachable. However, if you are deploying very large applications to multiple servers or to a cluster, the time required to copy files to target servers can be considerable. Consider nostage mode to avoid the overhead of copying large files to multiple servers.
Syntax for Stage Mode
To use stage mode, specify
-stage as an option to weblogic.Deployer, as in:java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mydeploymentname -targets myserver1,myserver2,myserver3 -stage -deploy c:\localfiles\myapp.ear No Stage Deployment:- Using Nostage Mode Deployment
In nostage mode, the Administration Server does not copy the archive files from their source location. Instead, each target server must access the archive files from a single source directory for deployment. The staging directory of target servers is ignored for nostage deployments.
For example, if you deploy a Java EE 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.
| Note: | The source for the deployment files in nostage mode is the path provided by the user at deployment time (as opposed to stage mode, where the source is the path in each server’s staging directory). However, even in nostage mode, WebLogic Server copies out parts of the deployment to temporary directories. This enables users to update entire archived deployments or parts of archived deployments. |
In nostage mode, the Web application container automatically detects changes to JSPs and servlets. Nostage also allows you to later update only parts of an application by updating those parts in one file system location and then redeploying.
The Administration Console uses nostage mode as the default when deploying only to the Administration Server (for example, in a single-server domain).
weblogic.Deployer uses the target server’s staging mode, and Administration Servers use nostage mode by default. You can also select nostage mode if you run a cluster of server instances on the same machine, or if you are deploying very large applications to multiple machines that have access to a shared directory. Deploying very large applications in nostage mode saves time during deployment because no files are copied.Syntax for Nostage Mode
To use nostage mode, specify
-nostage as an option to weblogic.Deployer, as in:java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic -password weblogic -name mydeploymentname -targets myserver1,myserver2,myserver3 -nostage -deploy c:\localfiles\myapp.ear
6.Use of heap:-
JVM Heap Size and Garbage Collection
Garbage collection is the JVM’s process of freeing up unused Java objects in the Java heap.The Java heap is where the objects of a Java program live. It is a repository for live objects, dead objects, and free memory. When an object can no longer be reached from any pointer in the running program, it is considered “garbage” and ready for collection.
The JVM heap size determines how often and how long the VM spends collecting garbage. An acceptable rate for garbage collection is application-specific and should be adjusted after analyzing the actual time and frequency of garbage collections. If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap size in accordance with your memory needs, full garbage collection is faster, but occurs more frequently.
The goal of tuning your heap size is to minimize the time that your JVM spends doing garbage collection while maximizing the number of clients that WebLogic Server can handle at a given time. To ensure maximum performance during benchmarking, you might set high heap size values to ensure that garbage collection does not occur during the entire run of the benchmark.
You might see the following Java error if you are running out of heap space:
java.lang.OutOfMemoryError <<no stack trace available>>java.lang.OutOfMemoryError <<no stack trace available>>Exception in thread "main"
To configure WebLogic Server to detect automatically when you are running out of heap space and to address low memory conditions in the server, see Automatically Logging Low Memory Conditions.
9.States of the Server?
Ans:-There are 9 states of server:-
- Shutdown
- Starting
- Standby
- Resuming
- Running
- Suspending
- Shutting down
- Failed
- Unknown
The series of states through which a WebLogic Server instance can transition is called the server life cycle.
The Server Life Cycle:-
Q.Use of Stub?
Ans:-
|
Q. How to check port number?
Ans:- netstat -na |grep connected (to find the ports connected in Linux box.)
netstat -na |grep listen (to find the listening ports in HP-UX,Solaris)
Q. Check the version of java.
Ans:- [root@h1vm /]# java -version run this command in linux to know the java version.
No comments:
Post a Comment