Interview Questions
Short Description
Interview Questions...
Description
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 send ing 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 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. 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 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. 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). Note: 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 applicationspecific 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 java.lang.OutOfMemoryError 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 Server’s 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 domain’s 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:
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 o
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 WLST provides a command-line interface for: Creating new WLS domains Retrieving and updating WLS domain configurations Deploying applications Obtaining run-time server statistics
o
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 Offline mode: Domain not running Access to only persisted domain configuration (config.xml) Create or update domains similar to using the Configuration Wizard
o
18). What is the Node Manager (NM)? Explain briefly? Node Manager (NM):
o o o o o
Starts and stops Managed Servers remotely: server, domain, and cluster Available as either a Java-based or (for UNIX or Linux) a script-based process Monitors and acts on server health Runs on the same computers as the Managed Servers 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 Java-based Node Manager runs within a Java Virtual Machine (JVM) process. 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).
o o
20). How Node Manager will work with the Weblogic Server? How will you configure Node Manager in WLS?
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. o
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 hi gh 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 Developer’s Kit (JDK) and Java Ru ntime 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 mach ine then you should use the serial collector (default for some configurations, can be enabled ex plicitly 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 you’d 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 som e 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 bo ot.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 doesn’t 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-inweblogic/ 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 e xternal connections to the servers. The T3 protocol often is used in WebLogic’s 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 server’s 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.
View more...
Comments