Sie sind auf Seite 1von 14

http://weblogic-wonders.

com/weblogic/oracleweblogicserver/
wlserver
Weblogic Tutorial and Unix Commands
Skip to content
Home
About
Weblogic Interview Questions And Answer
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 1
st
called server always acts like
leader, every member interact with leader, 1
st
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 the task to avoid overloading. Group of weblogic managed server
instance that work together to provide Scalability 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 servicethe 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 clusterso, 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. Difference 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 (physicianEar in 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 are physicianEar.
The Administration Console uses stage mode as the default mode when
deploying to more than one WebLogic Server
instance. weblogic.Deployer uses the target servers 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 servers 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 servers 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 JVMs 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 modify heap space values, see Specifying Heap Size Values.
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:-
Clients that connect to a WebLogic Server cluster and look up a clustered
object obtain a replica-aware stub for the object. This stub contains the
list of available server instances that host implementations of the
object. The stub also contains the load balancing logic for
distributing the load among its host servers.
Q.What happens when a failure occurs and
the stub cannot connect to a WebLogic
Server instance?
Ans:-When the failure occurs, the stub removes the failed server
instance from its list. If there are no servers left in its list, the stubb
uses DNS again to find a running server and obtain a current list of
running instances. Also, the stub periodically refreshes its list of
available server instances in the cluster; this allows the stub to take
advantage of new servers as they are added to the cluster.
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.
About these ads
11). How will you enable and disable the domain configuration lock?
The Administration Console Change Center provides a way to lock a domain
configuration so you can make changes to the configuration while preventing other
accounts from making changes during your edit session.
The domain configuration locking feature is always enabled in production domains. It
can be enabled or disabled in development domains. It is disabled by default when you
create a new development domain.
To enable or disable the domain configuration locking feature in a development
domain:
In the banner toolbar region at the top of the right pane of the Console, click
Preferences.
Click User Preferences.
Select or clear Automatically Acquire Lock and Activate Changes to enable or
disable the feature.
Click Save.
After you finish
When you enable domain configuration locking, you must use the Change Center to
lock and edit for the domain configuration.
12). What are Dynamic and Non-Dynamic Changes in the Weblogic Console?
What is the difference?
Some changes you make in the Administration Console take place immediately when
you activate them. Other changes require you to restart the server or module affected
by the change. These latter changes are called non-dynamic changes. Non-dynamic
changes are indicated in the Administration Console with this warning icon,.
Changes to dynamic configuration attributes become available once they are activated,
without restarting the affected server or system restart. These changes are made
available to the server and run-time hierarchies once they are activated. Changes to
non-dynamic configuration attributes require that the affected servers or system
resources be restarted before they become effective.
If a change is made to a non-dynamic configuration setting, no changes to dynamic
configuration settings will take effect until after restart. This is to assure that a batch of
updates having a combination of dynamic and non-dynamic attribute edits will not be
partially activated.
Note that WebLogic Servers change management process applies to changes in domain
and server configuration data, not to security or application data.
13). What is the information is going to store in the security folder of the
Domain directory contents?
This directory holds the security-related files that are the same for every WebLogic
Server instance in the domain:
SerializedSystemIni.dat
This directory also holds security-related files that are only needed by the domains
Administration Server:
DefaultAuthorizerInit.ldift
DefaultAuthenticatorInit.ldift
DefaultRoleMapperInit.ldift
14). What is the use of SerializedSystemIni.dat file in Weblogic?
It is important to protect passwords that are used to access resources in a WebLogic
Server domain. In the past, usernames and passwords were stored in clear text in a
WebLogic security realm. Now all the passwords in a WebLogic Server domain are
hashed. The SerializedSystemIni.dat file contains the hashes for the passwords. It is
associated with a specific WebLogic Server domain so it cannot be moved from domain
to domain.
If the SerializedSystemIni.dat file is destroyed or corrupted, you must reconfigure the
WebLogic Server domain. Therefore, you should take the following precautions:
Make a backup copy of the SerializedSystemIni.dat file and put it in a safe location.
Set permissions on the SerializedSystemIni.dat file such that the system administrator
of a WebLogic Server deployment has write and read privileges and no other users have
any privileges.
15). How many ways you can change the configuration changes?
The change management features of WLS:

o Enable you to distribute configuration changes throughout a domain
securely, consistently, and predictably
o Are the same, regardless of whether you are using:
The WLS Administration Console
The WebLogic Scripting Tool (WLST)
The Java Management Extension (JMX) APIs
16). What is the uses of WLST in Weblogic?

o The WLS command-line tools are useful:
For automating common administration activities
As an alternative to the Administration Console
When graphical tools are not supported
o WLST provides a command-line interface for:
Creating new WLS domains
Retrieving and updating WLS domain configurations
Deploying applications
Obtaining run-time server statistics
17). How many WLST modules are there? Explain?

o Online mode:
Connected to a running server
Access to all WLS configuration and run-time attributes
Create and activate change sessions similar to the WLS console
o Offline mode:
Domain not running
Access to only persisted domain configuration (config.xml)
Create or update domains similar to using the Configuration Wizard
18). What is the Node Manager (NM)? Explain briefly?
Node Manager (NM):

o Starts and stops Managed Servers remotely: server, domain, and cluster
o Available as either a Java-based or (for UNIX or Linux) a script-based
process
o Monitors and acts on server health
o Runs on the same computers as the Managed Servers
o Can be run automatically in the background, as a Windows service or a
UNIX daemon
19). How many versions of Node Managers are available?

o There are two versions of Node Manager:
Java-based Node Manager
Script-based Node Manager
o Java-based Node Manager runs within a Java Virtual Machine (JVM)
process.
o Script-based Node Manager (used only for UNIX and Linux systems) does
not have as much security, but provides the ability to remotely manage
servers over a network using Secure Shell (SSH).
20). How Node Manager will work with the Weblogic Server? How will you
configure Node Manager in WLS?

o Node Manager must run on each computer that hosts the WLS instances
that you want to control with Node Manager.
o You should configure each computer as a machine in Oracle WebLogic
Server, and assign each server instance, which is to be controlled by Node
Manager, to the machine that the server instance runs on.
o Node Manager should run as an operating system service, so that it
automatically restarts upon system failure or reboot.
1. How do you differentiate between a server hang and server crash issue?

When a Server crahes, the JAVA process no longer exists. When the Server is hung, it
stops responding.
We can use the weblogic.ADMIN utilty to ping the server. In case of a hang situation we
can take multiple thread dumps and analyze the cause of hang.
2. What can be the various reasons for a server crash?
a) Native IO
b) SSL Native Libraries
c) JVM
d) Supported Configuration
e) JDBC Driver issue
3. How do you troubleshoot a crash?
JVM crash generates a hs_err_pid file. We need to look into the stack trace of the
hs_err_pid file .
If the thread is from a native io, we need to disable native io.
if the stack trace is from the driver, we need to get in touch with the drive team.
Quite possibly its a problem with driver. Changing the type of driver can be a
workaround.
If the thread shows it coming from an optimzed code, we can turn of optimization.
If the stack is from native calls of application, its a bug with the application and it has to
b modified.
4. Ho do you troubleshoot Server Hang?
We can use java weblogic.Admin PING to check if we get a normal response.
We need to take multiple thread dumps with kill -3 pid on unix and CTLR Break on
Windows.
Analyze the thread dump to find the root cause.
5. What can be the reasons of Server hang?
Memory leak, databse query taking a long time to return, Deadlock.
6. What is memory leak?
Memory leak is when objects are not removed from the heap even when they are not
required.
7. What are the various causes for OUT OF MEMORY?
a) Insufficient heap size, not able to match the extra load.
b) Objects licing too long, like HTTP Sessions.
c) Memory leak in application code.
d) Full GC not happening due to JVM Bug.
8. How to troubleshoot and overcome such issues?
Gather memory data by enabling GC verbose.
If its due to Http Session, timing out http session after certain interval might help.
Look into the code for jdbc connection handling.
Optimizing the heap size according to the load.
9. When does High CPU Usage occur?
It occurs when one process or one thread utilizes unexpectedly high proportion of CPU.
10. How to troubleshoot it?
In Solaris environment, we need to take pstack and prstack and see what the threads are
doing.
In Windows we need to use pslist and process explorer.
11. What is Clustering and what is achieved through it?
Clustering is the grouping together of servers for the purpose of high availability and
scalability.
Load balancing and Failover is achieved.
12. How does Cluster Communication Happen?
Members of the Cluster communicate over the Cluster Multicast IP and Port by sending
periodic heart beat messages.
13. What is the difference between the Sun JVM and BEA JRockit JVM?
The most well know JVM is the implementation from Sun. The Sun JVM is called
HotSpot. The Sun JVM is shipped in the Java Developers Kit (JDK) and Java Runtime
Environment (JRE) from Sun.
The BEA JRockit JVM from BEA systems is optimized for reliability and performance
for server side applications. To achieve this, BEA JRockit JVM uses technologies such as
code generation, hot spot detection, code optimization, advanced garbage collection
algorithms and tight operating system integration.
14. TUning JVM Parameters.
If you have a single processor, single thread machine then you should use the serial
collector (default for some configurations, can be enabled explicitly for with -
XX:+UseSerialGC). For multiprocessor machines where your workload is basically CPU
bound, use the parallel collector. This is enabled by default if you use the -server flag, or
you can enable it explicitly with -XX:+UseParallelGC. If youd rather keep the GC
pauses shorter at the expense of using more total CPU time for GC, and you have more
than one CPU, you can use the concurrent collector (-XX:+UseConcMarkSweepGC).
Note that the concurrent collector tends to require more RAM allocated to the JVM than
the serial or parallel collectors for a given workload because some memory fragmentation
can occur.
15. How do you do performance tuning of WLS?
It can be categorized in 4 parts.
a. Application Tuning.
jsp precompilation, ejb pool size cache..
b. OS Tuning
Setting tcp ip parameter.
tcp_time_wait_interval
tcp_conn_req_max_q
c. Core Server Tuning.
tune workmanager, tune chuck size and chunck pool size, using performance packs,
conenction backlog buffering.
d. JVM Tuning
tuning gc strategy, monitoring garbage collection..
16. What is the difference between Development mode and Production mode of
Weblogic Server?
Development Mode:
1. The default JDK for development domain is Sun Hotspot.
2. You can use the demo certificates for SSL.
3. Auto deployment(to admin server only) is enabled.
4. Server instances rotate their log files on start-up.
5. Admin Server uses an automatically created boot.properties during start-up.
6. The default maximum capacity for JDBC Datasource is 15.
7. The debugFlag which is used to start the WebLogic Workshop Debugger is enabled.
8. In Development Mode any configuration change being done by a user doesnt need
him to take a Lock and Edit session.
9. Availability of web service test client.
10. Nodemanger username and password: Default Admin credentials.
11. Availability of Classloader Analysis Tool: Yes.
12. Default start parameters when using Sun JDK and the default startWebLogic script :
java -client -Xms256m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=128m
-XX:MaxPermSize=256m.
Production Mode:
1. The default JDK for production domain is JRockit.
2. If you use the demo certificates for SSL a warning is displayed.
3. Auto deployment(to admin server only) is disabled.
4. Server instances rotate their log files when it reaches 5MB.
5. Admin Server prompts for username and password during start-up.
6. The default maximum capacity for JDBC Datasource is 25.
7. The debugFlag which is used to start the WebLogic Workshop Debugger is disabled.
8. In Production Mode the user needs to procure a Lock and Edit session before trying to
make any configurational changes.
9. No Availability of web service test client.
10. Nodemanger username and password: Randomly generated
11. Availability of Classloader Analysis Tool: No.
12. Default start parameters when using Sun JDK and the default startWebLogic script :
java -server -Xms256m -Xmx512m -XX:MaxPermSize=256m.
Ref :- http://impradeep.com/difference-between-production-and-development-mode-in-
weblogic/
17. What is HTTP tunneling? How can we configure it on Weblogic?
HTTP tunneling provides a way to simulate a stateful socket connection between
WebLogic Server and a Java client when your only option is to use the HTTP protocol. It
is generally used to tunnel through an HTTP port in a security firewall. HTTP is a
stateless protocol, but WebLogic Server provides tunneling functionality to make the
connection appear to be a regular T3Connection.
Steps to configure Http tunneling.
Login into the Admin Console, click on the server on which you want to enable he Http
Tunneling feature
Click on the Protocols tab ? General ? check the Enable Tunneling check box.
Now you can communicate with the JVMs (Server Instances) using protocols other than
t3
18. What is the difference between T3 and HTTP protocol?
WebLogic uses the T3 protocols for internal and external connections to the servers. The
T3 protocol often is used in WebLogics implementation of RMI. Proprietary of
WebLogic Server.
Http protocols are used primarily for HTTP communication between the browser and the
web server. Standard follows the W3C (World Wide Web Consortium).
Note: All of these protocols are, by default, multiplexed over the same connection to the
servers address and port. So you can access a web page hosted by the server using a
URL such as http://host:port/page.jsp. An external client can set up an initial JNDI
context to a server using the URL t3://host:port/. All that has changed is the protocol over
which the client must communicate with the server.

Das könnte Ihnen auch gefallen