Generating heap dumps manually

Use this task to generate heap dumps manually. This function is not supported on when using a Sun Java virtual machine (JVM) which includes WebSphere Application Server running on HP-UX and Solaris operating systems.
Before you begin
Although heap dumps are generated only in response to a detected memory leak, you must understand that generating heap dumps can have a severe performance impact on WebSphere Application Server for several minutes. When generating multiple heap dumps manually for memory leak analysis, make sure that significant objects are leaked in between the two heap dumps. This approach enables problem determination tools to identify the source of the memory leak.
About this task
You might want to manually generate heap dumps for the analysis of memory leaks. On a Java virtual machines (JVM) in WebSphere Application Server, you cannot enable automated heap dump generation. You might want to designate certain times to take heap dumps because of the overhead involved. On JVM in WebSphere Application Server, you can manually produce heap dumps by using the generateHeapDump operation on WebSphere Application Server managed beans (MBeans) that are special Java beans.
The WebSphere Application Server wsadmin tool provides the ability to run scripts. You can use the wsadmin tool to manage a WebSphere Application Server installation, as well as configuration, application deployment, and server runtime operations. WebSphere Application Server supports the Jacl and Jython scripting languages only. To learn more about the wsadmin tool, see the Starting the wsadmin scripting client topic.
Procedure
Start the wsadmin scripting client. You have several options to run scripting commands, ranging from running them interactively to running them in a profile.
Invoke the generateHeapDump operation on a JVM MBean, for example,
Finding JVM objectName:
set objectName [$AdminControl queryNames
WebSphere:type=JVM,process=,node=,*]
Invoking the generateHeapDump operation on JVM MBean:
$AdminControl invoke $objectName generateHeapDump
where,
$
is a Jacl operator for substituting a variable name with its value
invoke
is the command
generateHeapDump
is the operation you are invoking

is the name of the server on which you want to generate a heap dump

is the node to which belongs
Important to AMD 64-bit users: You must specify the -Xtrace option to take heap dumps
Locating and analyzing heap dumps
Use this task to locate and analyze heap dumps.
Before you begin
Do not analyze heap dumps on the WebSphere Application Server machine because analysis is very expensive. For analysis, transfer heap dumps to a dedicated problem determination machine.
About this task
When a memory leak is detected and heap dumps are generated, you must analyze heap dumps on a problem determination machine and not on the application server because the analysis is very central processing unit (CPU) and disk I/O intensive.
Perform the following procedure to locate the heap dump files.
Procedure
On the physical application server where a memory leak is detected, go to the WebSphere Application Server home directory. For example, on the Windows operating system, the directory is:
profile_root\myProfile
IBM heap dump files are usually named in the following way:
heapdump....phd
Gather all the .phd files and transfer them to your problem determination machine for analysis.
Many tools are available to analyze heap dumps that include Rational Application Developer 6.0. WebSphere Application Server serviceability released a technology preview called Memory Dump Diagnostic For Java. You can download this preview from the product download Web site.
What to do next
When you have a couple of heap dumps, use a number of memory leak problem determination tools to analyze your problem
Problem(Abstract)
This technote describes one way to manually generate heapdumps from WebSphere® Portal.By default, you get heapdumps only on OutOfMemoryErrors. You do not get heapdumps in crashes or through a signal to the JVM.



Cause
Heapdump is an IBM® JVM facility that generates a dump of all the live objects that are on the Java heap; that is, those that are used by the Java application. It shows the objects that are using large amounts of memory on the Java heap, and what is preventing them from being collected by the Garbage Collector.


Resolving the problem
In order to manually generate a WebSphere Portal heapdump, you must first enable signal-based heapdumps by setting the IBM_HEAPDUMP=TRUE environmental variable to the WebSphere Portal (Java) process.
After enabling signal-based heapdumps, you will get heapdumps on OutOfMemoryErrors, crashes, and through signals to the JVM.
Next, you manually generate a heapdump (Java memory dump) in the same way as you manually generate a javacore (Java thread dump), which is by using a signal. The command to send the correct signal to the JVM is dependant on your operating system.
A heapdump is normally produced immediately before a javacore.
Heapdumps now always trigger a garbage collection that occurs before the dump. This means that all the objects that are in the heapdump are live (reachable) objects.
Although heapdumps are generated only in response to a detected memory leak, you must understand that generating heap dumps can have a severe performance impact on WebSphere Portal for several minutes. When generating multiple heap dumps manually for memory leak analysis, make sure that significant objects are leaked in between the two heap dumps. This approach enables problem determination tools to identify the source of the memory leak.
Setting an environment variable in WebSphere Application Server 6.0In the WebSphere Administrative Console, click Application servers -> WebSphere_Portal -> Process Definition -> Custom Properties and add:
IBM_HEAPDUMP=TRUE
Restart WebSphere_Portal.
Setting an environment variable in WebSphere Application Server 5.1In the WebSphere Administrative Console, click Application servers -> WebSphere_Portal -> Process Definition -> Environment Entries and add:
IBM_HEAPDUMP=TRUE
Restart WebSphere_Portal.
Command to manually generate heapdump/javacore on UNIX (AIX, Linux, Solaris, and HP-UX
kill -3 [PID_of_WebSphere_Portal_JVM]
This signal will not end the Java process.
Commands to manually generate heapdump/javacore on Windows
wsadmin.bat [-host host_name] [-port port_number] [-user userid -password password]wsadmin> set jvm [$AdminControl completeObjectName type=JVM,process=WebSphere_Portal,*]wsadmin>$AdminControl invoke $jvm dumpThreads
Taking manual heapdumps in Solaris JVM 1.4.2 version 26-Apr-2007 08:30 (reply 1 of 2)

Top of Form

Bottom of Form

In 1.4.2 you can use the -XX:+HeapDumpOnOutOfMemoryError option to tell the VM to generate a heap dump if OutOfMemoryError is thrown. Another way is to run the application with the HPROF agent or other profiler. Recent 1.4.2 updates have an undocumented/unsupported option to generate a heap dump when ctrl-\ (SIGQUIT).The jmap utility on Solaris can be used to recover a heap dump from a core file or hung process. This is mostly for post mortem diagnostics and there is no guarantee that the heap dump will be readable. As it attaches to the target process via /proc it can take a long time to read the process memory. Recent releases (jdk6) have most improvements in this area (like jmap -dump which allows you to take a snapshot of the heap at any time
Location of the generated heapdumps and javacores for WebSphere Portal
Problem(Abstract)
This technote describes the location of the generated heapdumps and javacores for WebSphere® Portal.



Symptom



Environment
WebSphere Portal running on WebSphere Application Server 6.0 or 5.1 uses Java™ 1.4.2.


Resolving the problem
This information can be found in the IBM Developer Kit and Runtime Environment, Java 2 Technology Edition, Version 1.4.2 Diagnostics Guide. For your convenience, the relevant excepts and links to the topics are provided below.
HeapdumpsThe JVM checks each of the following locations for existence and write-permission, then stores the Heapdump in the first one that is available:
The location that is specified by the IBM_HEAPDUMPDIR environment variable, if set.
The current working directory of the JVM processes:
For WebSphere Portal running on WebSphere Application Server 6.0, this is directory (for example, /opt/IBM/WebSphere/AppServer/profiles/wp_profile).
For WebSphere Portal running on WebSphere Application Server 5.1, this is directory (for example, /opt/IBM/WebSphere/AppServer).
The location that is specified by the TMPDIR environment variable, if set.
The /tmp directory (X:\tmp for Windows, where X is the current working drive).
Note that enough free disk space (possibly up to 1 GB) must be available for the Heapdump file to be written correctly.On Linux and AIX, a log of Heapdump files is maintained in the file /tmp/javacore_locations.Heapdump filename formats
Windows
heapdump.YYYYMMDD.HHMMSS.PID.phd orheapdump.YYYYMMDD.HHMMSS.PID.txt
Linux & AIX
heapdumpPID.TIME.phd orheapdumpPID.TIME.txt
Solaris
java_pidPID.hprof.TIME
Note: PID is the process ID. TIME is the number of seconds since 1/1/1970.
JavacoresThe JVM checks each of the following locations for existence and write-permission, then stores the Javacore in the first one that is available:
The location specified by the IBM_JAVACOREDIR environment variable if set.
The current working directory of the JVM processes:
For WebSphere Portal running on WebSphere Application Server 6.0, this is directory (for example, /opt/IBM/WebSphere/AppServer/profiles/wp_profile).
For WebSphere Portal running on WebSphere Application Server 5.1, this is directory (for example, /opt/IBM/WebSphere/AppServer).
The location specified by the TMPDIR environment variable, if set.
The /tmp directory or, on Windows only, the location specified by the TEMP environment variable, if set.
Windows only: If the Javacore cannot be stored in any of the above, it is put to STDERR.
Note that enough free disk space (possibly up to 2.5 MB) must be available for the Javacore file to be written correctly.On Linux and AIX, a log of Javacore files is maintained in the file /tmp/javacore_locations.On Solaris, javacore output is not written to a separate file. Rather, it is appended to the existing native_stdout.log, typically in directory /log.Javacore filename formats
Windows and Linux
javacore.YYYYMMDD.HHMMSS.PID.txt
AIX
javacorePID.TIME.txt
Solaris
native_stdout.log
Note: PID is the process ID. TIME is the number of seconds since 1/1/1970.

Location of the generated Heapdump
The JVM checks each of the following locations for existence and write-permission, then stores the Heapdump in the first one that is available.
The location that is specified by the IBM_HEAPDUMPDIR environment variable, if set (_CEE_DMPTARG on z/OS(R))
The current working directory of the JVM processes
The location that is specified by the TMPDIR environment variable, if set
The /tmp directory (X:\tmp for Windows(R), where X is the current working drive)
Note that enough free disk space must be available for the Heapdump file to be written correctly
Heapdumps can be very large with millions of items in them. Here is a small sample:
// Version: J2RE 1.4.2 IBM AIX build ca142-20061124 (SR7)
0x30060200 [388832] byte[]
0x300bf0e0 [304] class OOMTest

0x300bf210 [49800] byte[]
0x300cb498 [88] java/lang/Thread
0x0 0x0 0x300d8198 0x0 0x3010f218 0x0 0x300cb4f0 0x300e04f0 0x0
0x300cb4f0 [128] sun/misc/Launcher$AppClassLoader
0x300f89c0 0x300cb570 0x300f8ad8 0x300f8cc8 0x300f8c58 0x301430b8 0x300f8b20 0x0 0x0 0x300f8be8 0x0 0x300f8b78 0x0 0x0 0x300f8a88 0x300f8a18 0x300f8938 0x300f8fb8 0x300f52d
0 0x300f89a0
0x300cb570 [128] sun/misc/Launcher$ExtClassLoader
0x300f5af0 0x0 0x300f5ca8 0x300f5f08 0x300f5e98 0x0 0x300f5d60 0x300f5238 0x0 0x300f5e28 0x0 0x300f5db8 0x0 0x0 0x300f5c58 0x300f5bc0 0x300fb2f8 0x300f5f38 0x300f52d0 0x300
f5ad0 0x300f4f88
0x300cb5f0 [88] java/lang/Thread
0x0 0x0 0x300d8198 0x0 0x300dfa30 0x0 0x0 0x300e04f0 0x0
0x300cb648 [88] java/lang/Thread
0x0 0x0 0x300d8198 0x0 0x300dfa80 0x0 0x0 0x300e04f0 0x0
.
.
.
..........................(more data)........................

// Breakdown - Classes: 321, Objects: 2403, ObjectArrays: 205, PrimitiveArrays: 1671
// EOF: Total 'Objects',Refs(null) : 4600,5249807(925)
The first line in the Heapdump contains the build identifier of the JVM that produced the dump.
In each line of data of the main part of the dump:


The first hex number is the handle of the object.
The number in square brackets is the size of the object.
The remainder of the line is a description of the object. If an object references other objects, those objects are presented as a series of object handles indented in the following line or lines. In the example above, all possible references are dumped, with nulls being explicitly shown as 0x0.
The last two lines in the Heapdump summarize the heap content

WLM Algorithm?

Sol:
A. WLM algorithm is of two types
1. Round robin
2. Random
1. Example: Server1 has 4 weight and server2 has 1 and here the algorithm works likeThe first request will route to the server2 as it has less weight than server1, then the second request will route to the server1 executes the request and then 3rd request will route to servev2 then the counter decrements to 0, here the note is the requests will not route to that server, then all the requests will route to that server1 until the counter reaches 0 then the weights gets reset.

What is WLM?

Workload management is the process of managing client requests in the most efficient manner. This is achieved by servers running software that manages load distribution on a node and/or across multiple nodes. Any work that is received through client requests is intelligently distributed to an application server or another object that is best able to efficiently process that request

What is Http pluging log?

Sol:
The plug-in runs in the HTTP Web server process and routes requests from the Web server to the application server.

What is FFDC?

Sol:
Preserves the information generated from a processing failure
• Captured data is saved in log files for use in analysis
• This tool is meant to be used by IBM support
• Capturing FFDC data does not affect performance
• FFDC data is collected on the \logs\ffdc directory
• There are no administrative tasks to manage FFDC
The First Failure Data Capture tool preserves the information generated from a processing failure and returns control to the affected engines. The captured data is saved in a log file for use in analyzing the problem.
The First Failure Data Capture tool is intended primarily for use by IBM Service. It runs as part of the IBM WebSphere Application Server, and you cannot start or stop it. It is recommended that you not attempt to configure the First Failure Data Capture tool. If you experience conditions requiring you to contact IBM Service, your IBM Service representative will assist you in reading and analyzing the First Failure Data Capture log.
The First Failure Data Capture tool does not affect the performance of the IBM WebSphere Application Server

WebSphere Architecture?

HTTP Server:
The HTTP server, more typically known as the Web server, accepts page requests from Web browsers and returns Web page content to Web browsers using the HTTP protocol.
• Requests for Java servlets and JavaServer Pages (JSPs) are passed by the
Web server to WebSphere for execution.
• WebSphere executes the servlet or JSP and returns the response to the Web
server, which in turn forwards the response to the Web browser for display.
• WebSphere V5 supports numerous Web servers such as Apache, Microsoft
IIS, Netscape and Domino.




• However, WebSphere has the tightest integration with Domino because IBM provides single sign-on capabilities between WebSphere and Domino.

WebSphere plug-in:
The WebSphere plug-in integrates with the HTTP Server and directs requests for WebSphere resources (servlets, JSPs, etc.) to the embedded HTTP server (see below).
• The WebSphere plug-in uses a configuration file called plugin-cfg.xml file to determine which requests are to be handled by WebSphere.
• As applications are deployed to the WebSphere configuration, this file must be regenerated (typically using the Administration Console) and distributed to all Web servers, so that they know which URL requests to direct to WebSphere.
• This is one of the few manual processes that a WebSphere administrator must do to maintain the WebSphere environment.

Embedded HTTP Server:
The embedded HTTP server receives requests for WebSphere assets from the WebSphere plug-in and passes them to an application server for processing.
• Any response from the application server is passed back to the WebSphere
plug-in for display.
• The embedded HTTP server supports both HTTP and secure HTTP (HTTPS) protocols for connecting Web servers to application servers. By default, the embedded HTTP server listens for requests on TCP/IP port 9080 but this is configurable.
• For example: http://server-name:9080/servlet/snoop
• You can also use the embedded HTTP server to test your WebSphere
applications, but it should never be used as a production Web server.






Application Server:
The application server provides a run-time environment for J2EE applications (supporting servlets, JSPs, Enterprise JavaBeans, etc.).
• A node can have one or more application server processes. Each application server runs in its own runtime environment called a Java Virtual Machine (JVM).
• The JVM provides complete isolation (crash protection) for individual
applications servers.

Application Database:
WebSphere applications such as IBM's commerce and portal products, as well as applications you create yourself, use a relational database for storing configuration information and data.
• WebSphere V5 ships with the Cloudscape database and supports a wide range of database product, including the following:
• IBM DB2
• Informix
• Oracle
• SQL Server
• Sybase

Administration Service:
Each application server contains an administration service that is responsible for reading and maintaining the configuration information and run-time status of the application server. The administration service runs in the same JVM as the application server.








Configuration Repository:
The configuration repository is a collection of XML files that contains the configuration information for all application servers on a given node.
• The administration service reads the configuration information for its
application server from the configuration repository.
• Nodes that are part of a cell contain a subset of a centralized configuration
repository.
• The centralized configuration repository contains configuration information for all nodes in the cell.
• This enables the administrator to centrally manage the configuration of all of these nodes.
• Configuration changes are automatically distributed to the specific node to
which the changes pertain.
• Multiple configuration repositories can be created to support environments
that require multiple WebSphere cells.
• This is particularly useful when separate domains are required for
development, testing and production purposes. Each node is configured to
use a separate configuration repository.

Administration Console:
The administration console provides a Web-based interface for managing a WebSphere cell from a central location.
• The administration console can be used to change the configuration of any
node within the cell at run-time.
• Configuration changes are automatically distributed to other nodes in the cell.

What is Garbage collection and how do you diagnose it?

A. Enabling verbose garbage collection (verbosegc) in WebSphere Application Server
Example: After deploying the new application suppose some class is creating some
objects then by heap dump can find which class is creating the objects then we can
inform the developers regarding this class.
Enabling verbose garbage collection (verbosegc) logging is often required when
tuning and debugging many issues. This technote describes how to do this for the
various versions of IBM® WebSphere® Application Server
Enabling verbosegc on releases of Version 6.0 and 6.1
• In the Administrative Console, expand Servers and then click on Application
Servers.
• Click on the server that is encountering the "OutOfMemory" condition.
• On the Configuration tab, under Server Infrastructure, expand Java and
Process Management, and click Process Definition.
• Under the Additional Properties section, click Java Virtual Machine.
• Select the Verbose garbage collection check box
• Click Apply.
• At the top of the Administrative Client, click Save to apply changes to the
master configuration.
• Stop and restart the Application Server.
• The verbose garbage collection output is written to either native_stderr.log or
native_stdout.log for the Application Server, depending on the SDK operating
system as follows:
For AIX®, Microsoft® Windows®, or Linux®:
native_stderr.log
For Solaris™ or HP-UX:
native_stdout.log

What is cluster? What are the types of Clusters and their advantages?

A.Cluster is set of App servers .
Types:
Horizontal Clustering:
• Here In two different Nodes ( diff blades) you have 2 cluster members where
all the requests gets routed to the cluster members, When ever one blade or
Node crashes then automatically the requests gets routed to the other Node
or Blade.
• Here the advantage is Failover
Vertical Clustering:
• Here In Single Node you have two cluster members where all the requests get
routed to the two cluster members.
• Here the advantage is Performance.

How do you analyze Heap Dump? How to create it in WebSphere?

A. Through Heap Analyzer Tool you can analyze Heap Dump and the extension of
Heap Dump will be .phd ( portable heap dump)
• From here you can suspect the memory leaks of the packages and class files.
• First you need to create a variable called IBM_HEAPDUMP = TRUE….
• In App servers -> server -> Java Process Mgmt -> Process Definition ->
Custom Properties---Click New -> then Give the value as :
IBM_HEAPDUMP = TRUE
• You can create Heap Dump by: kill -3 server process ID.
Here Heap dump is created only when there is App memory leak, then only
the Heap Dump is going to create.

How to generate Java heap dump in WebSphere?

􀂃 IBM Java Heap dump can be generated in either of two ways
􀀗Explicit generation
􀀗Java Virtual Machine triggered generation
􀂃 When the Java heap is exhausted, Java Virtual Machine triggered generation is enabled by default.
􀂃 To enable signal-based Java Heap dumps, the
IBM_HEAPDUMP=TRUE environmental variable or the appropriate
JAVA_DUMP_OPTS must be set.
Explicit generation
􀂃 IBM Java Heap dump can be explicitly generated in either of the
following ways
􀀗By sending a signal to the JVM from the operating system
􀀗By using the HeapDump() method inside Java code that is being executed
􀂃 For Linux and AIX, send the JVM the signal SIGQUIT (kill -3, or CTRL+\ in the console window).
􀂃 For Windows, generate a SIGINT (press the Ctrl+Break keys
simultaneously).


Java Virtual Machine triggered generation
􀂃 The following events automatically trigger the JVM to produce a Java Heap dump
􀀗A fatal native exception occurs in the JVM (not a Java Exception)
􀀗An OutOfMemoryError or heap exhaustion condition occurs (optional)
􀂃 If Java Heap dumps are enabled, they are normally produced immediately before a thread dump. They are produced also if the JVM terminates unexpectedly (a crash).

Location of IBM Java Heap dump
􀂃 The JVM checks each of the following locations for existence and write-permission, then stores the Heap dump in the first one that is available.
􀀗The location that is specified by the IBM_HEAPDUMPDIR environment variable, if set
􀀗The current working directory of the JVM processes
􀀗The location that is specified by the TMPDIR environment variable, if set
􀀗The /tmp directory (X:\tmp for Windows, where X is the current working drive)
􀂃 Note that enough free disk space must be available for the Heap dump file to be written correctly.

Diagnosing out-of-memory errors and Java heap memory leaks in WebSphere?

Memory Dump Diagnostic for Java™ is an offline tool for diagnosing root causes behind memory leaks in the Java heap. The tool analyzes common formats of memory dumps (heap dumps) from the Java virtual machine (JVM) in which the WebSphere® Application Server runs. The analysis of memory dumps is targeted toward identifying data structures within the Java heap that might be root causes of memory leaks. The analysis also identifies a summarized set of object groups that contribute significantly to the Java heap footprint of the application. The tool is capable of analyzing very large memory dumps from production-environment application servers that exhibit out-of-memory issues.
Before you begin
This tool works with the memory dumps that are generated from WebSphere Application Server, not from the Memory Dump Diagnostic for Java tool. The following dump formats are supported:
IBM® Portable Heap Dump (.phd), for WebSphere Application Server versions 5.1.x and later on most platforms
IBM Text, for WebSphere Application Server versions 4.x and 5.0.x on most platforms
HPROF, for WebSphere Application Server installations on the HP-UX and Solaris platforms
About this task
Memory leaks can occur in Java applications when object references are unintentionally held onto after the references are no longer needed. This problem prevents the Java garbage collection process from freeing memory, even though the Java language has a built-in garbage collection mechanism that frees the programmer from explicit object deallocation responsibilities. Memory leaks are hard to diagnose in large complex Java applications, because of the large number of objects in the Java heap and because of the complex relationships between these objects.
Two types of analysis mechanisms are available: single-dump analysis and the comparative analysis of two dumps. The tool lists suspected data structures and data types and displays contents of the memory dump in an interactive browser-based Web application. The tool shows footprint analysis results in a graphical layout of significant sets of data types that have similar ownership structures. The tool shows the contents of the memory dump in an interactive tree view for browsing and in two table views of objects and data types, respectively. The tree view enables you to look for all incoming and outgoing references for each object and to see the location of a container object within each data structure with a suspected memory leak.
Analyzing memory dumps in an offline fashion provides a low-overhead mechanism for identifying root causes behind memory leaks. This mechanism is particularly suitable for large applications that are running in production or in stress-test environments, where memory leaks are often detected first.






Procedure
Install IBM Support Assistant on a computer that is separate from the application server installation to be analyzed. Use a non-production computer with at least 5 gigabytes (GB) of free disk space, at least 1.5 GB of RAM, and an Intel® processor that runs at 2 GHz or faster, preferably on the Linux® platform.
Enable verbose garbage collection on the application server installation to be analyzed.
Verbose garbage collection information helps to rule out basic configuration issues and memory-leak issues from fragmentation or native memory leaks. For more information about how to enable verbose garbage collection on IBM platforms, see IBM developer kits: Diagnosis documentation.
Optional: Enable lightweight memory-leak detection in WebSphere Application Server.
Enabling lightweight memory-leak detection can help with early detection of abnormal memory usage behavior and for automatically triggering heap dumps.
Enable the JVM heap dump feature for WebSphere Application Server.
Refer to the documentation that is supplied with the tool when you start from IBM Support Assistant.
When the heap dump is available, run the Memory Dump Diagnostic for Java tool.
Start IBM Support Assistant.
In IBM Support Assistant, select the Tools tab.
On the left side, click WebSphere 6.1.
On the right side, click Memory Dump Diagnostic for Java.
Results
The possible root causes of memory leaks are identified.
Memory leaks in the Java heap produce java.lang.OutOfMemoryError exceptions in log files. However, not all out-of-memory errors are caused by Java heap memory leaks. Out-of-memory errors can also be caused by the following conditions:
Java heap fragmentation. This fragmentation occurs when no contiguous chunk of free Java heap space is available from which to allocate Java objects. Various causes for this problem exist, including the presence of pinned or dosed objects or because of the repeated allocation of large objects.
Memory leaks in native heap. This problem occurs when a native component, like DB2® connections, is leaking.
For both of these conditions, the out-of-memory error can occur in spite of large amounts of free Java heap space. Consequently, the Memory Dump Diagnostic for Java tool might not be effective in determining root causes in these cases.

How to troubleshoot “out of stack exception in WebSphere?

Stack Overflows are almost
always caused by either infinte looping or infinite recursion. So, check
your loops, and if you have any recursive functions, check them too.

What is virtual Host and how to configure it in WebSphere?

A virtual host is a configuration enabling a single host machine to resemble multiple host machines. Resources associated with one virtual host cannot share data with resources associated with another virtual host, even if the virtual hosts share the same physical machine.
Each virtual host has a logical name and a list of one or more DNS aliases by which it is known. A DNS alias is the TCP/IP host name and port number used to request the servlet, for example yourHostName:80. When no port number is specified, 80 is assumed.
When a servlet request is made, the server name and port number entered into the browser are compared to a list of all known aliases in an effort to locate the correct virtual host and serve the servlet. If no match is found, an error is returned to the browser. Use unique name as described in Warning: no string named [ccws_vhost_alias] found..
If more than one match is found and the matches are not for the same Application Server, an error is returned if the application is not on the Application Server with the first matching entry.
An Application Server provides a default virtual host with some common aliases, such as the machine IP address, short host name, and fully qualified host name. The alias comprises the first part of the path for accessing a resource such as a servlet. For example, it is localhost:80 in the request http://localhost:80/myServlet.
A virtual host is not associated with a particular node (machine). It is a configuration, rather than a "live object," explaining why you can create it, but cannot start or stop it. For many users, creating virtual hosts is unnecessary because the default_host is provided.
Adding a local host to the virtual hosts adds the host name and IP address of the local host machine to the alias table. This allows a remote user to access the administrative console.
Configure it:
Create a virtual host using the Virtual Hosts page of the administrative console. Click Environment > Virtual Hosts from the navigation tree of the console, click New and, on the settings page for a virtual host that displays, specify an administrative name for the virtual host.
When you create a virtual host, a default set of 90 MIME entries is created for the virtual host.
Determine whether you need a virtual host alias for each HTTP transport port. There must be a virtual host alias corresponding to each port used by an HTTP transport. There is one HTTP transport in each Web container, with one Web container in each application server.
You must create a virtual host for each HTTP port in the following cases:
You are using the internal HTTP transport with a port other than the default of 9080, or for some reason the virtual host does not contain the usual entry for port 9080.
You have created multiple application servers (either stand-alone or in a cluster) that are using the same virtual host. Because each server must be listening on a different HTTP transport port, you need a virtual host alias for each one's transport port.
If you determine that you need one or more virtual host aliases, on the HTTP Transports page, note the Port values, such as 9080 or 9082.
If necessary, create a virtual host alias for each HTTP transport port.
From the Virtual Hosts page, click on your virtual host and, on the settings page for a virtual host, click Host Aliases. For each virtual host alias that you need, on the Host Aliases page, click New; then, on the settings page for a virtual host alias, specify a host name and port. Configure the virtual host to contain an alias for the port number. For example, specify an alias of *:9082 if 9082 is the port number in use by the transport.
When you enter the URL for the application into a Web browser, include the port number in the URL.
For example, if 9082 is the port number, specify a URL such as http://localhost:9082/wlm/SimpleServlet
If MIME entries are not specified at the Web module level, define MIME object types and their file name extensions. For each needed MIME entry, on the MIME Types page, click New; then, on the settings page for a MIME type, specify a MIME type and extension.
After you configure a virtual host alias or change a configuration, you must regenerate the Web server plug-in configuration and restart WebSphere Application Server.

What is Javacore and heap dump with diff in WebSphere?

Heap dumps anytime you wish to see what is being held in memory Out-of-memory errorsHeap dumps - picture of in memory objects - used for memory analysisJava cores - also known as thread dumps or java dumps, used for viewing the thread activity inside the JVM at a given time. IBM javacores should a lotof additional information besides just the threads and stacks -- used to determine hangs, deadlocks, and reasons for performance degredationSystem cores
Heap dumps are taken by issuing a "kill -3" against the JVM pid. There is a cost associated with producing heap dumps. The writtingof the heap dump can be cpu and i/o intensive depending on the size of the configured heap, you can take heap dumps anytime you wish to see what is being held in memory. Out-of-memory errors or a good time to view heap dumps. In fact,in most cases heap dumps should be created when an OOM is triggered. Unless you're an administrator or root - you'll need to own the process you want to kill in order for the command to work.Depends on the OS.
Java cores also known as thread dumps or java dumps, used for viewing the thread activity inside the JVM at a given time. javacores should a lotof additional information besides just the threads and stacks used to determine hangs, deadlocks, and reasons for performance degredation.The kill -3 command captures JVM signals and dumps the requested diagnostic material.There are options available to dump the heap in .txt format this files can be huge and unless you're a genius with lots of time on your hands - don't try to read the text dump with vi or something.. Use MDD4J or HeapAnalyzer.
For taking heap dumps you need set these environment entries for that JVM using admin consle(this is one way of doing taking heap dumps, u can also go with jacl or jython scripts)IBM_HEAPDUMP TRUEIBM_HEAPDUMP_OUTOFMEMORY true(if a OOM outofmemory(OOM)occurs, a dump is saved to /tmpIBM_HEAPDUMPDIR appropriate directory.Now, if you run kill -3 pid, then a heap dump is taken in the specified directory and also a core dump will be taken. If you didn't specify any environment entries then only a core dump is taken.

How to add a node through command line in WebSphere?

The addNode command incorporates a WebSphere Application Server installation into a cell. You must run this command from the install_root/bin directory of a WebSphere Application Server installation. Depending on the size and location of the new node you incorporate into the cell, this command can take a few minutes to complete.
The node agent server is automatically started as part of the addNode command. If you recycle the system that hosts an application server node, and did not set up the node agent to act as an operating system daemon, you must issue a startNode command to start the node agent before stating any application servers.
Syntax
The command syntax is as follows:

addNode [options]

The argument is required. The default port number is 8879 for the default Simple Object Access Protocol (SOAP) port of the deployment manager. SOAP is the default Java Management Extensions (JMX) connector type for the command. If you install the deployment manager using coexistence ports, the default SOAP port is 8889.

What is Deployment Descriptors? How many types of Deployment Descriptors are available? What are they?

According to war file
1. web.xml
2. ibm-web-bnd.xml
3. ibm-web-ext.xml

(or)
Deployment descriptor is an XML file that describes how to deploy a module or application by specifying configuration and container options. For example, an EJB deployment descriptor passes information to an EJB container about how to manage and control an enterprise bean

(Or)

This file is web.xml
This is an xml file. It tells to the server about the application.
Each web appication contain one deployment descriptor.

How to implement JDBC-ODBC bridge driver (Type 1) in Websphere?

If you use jdbc type (i) Driver so you no need to add any driver in websphare , you simply create DSN and use it locally , same we use java class, if you use Type (2) and Type (4) so first go to admin consol then go to connection then add driver there fill other information like connection size , user name password , max connection and connect it to your applications.

What is session caching?

The IBM WebSphere Application Server session support maintains a list of the most recently used sessions in memory. It avoids using the database to read in or access the session when it is determined that the cache entry is still the most recently updated. To determine if the cached session is still valid, WebSphere reads the session's last access time field from the database and compares it to the last access time of the cached session.

What is EJB?

Enterprise JavaBeans (EJB) technology is the server-side component architecture for the Java 2 Platform, Enterprise Edition (J2EE) platform. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.

What is JDBC?

JDBC technology is an API (included in both J2SE and J2EE releases) that provides cross-DBMS connectivity to a wide range of SQL databases and access to other tabular data sources, such as spreadsheets or flat files. With a JDBC technology-enabled driver, you can connect all corporate data even in a heterogeneous environment.

How to trouble shoot “Out of memory exception:

Here is how it works:
JVM Heap: The size you specify via -Xmx flag. This is the Memory that JVM uses to allocate objects created from your Application
Native Memory: This is outside of JVM Heap. And the Maximum limit is enforced only by the OS. This is the memory that JVM uses for it's internal operations.
So, when you find out the Memory used by your JVM process from the OS level (using TOP or ps), the amount you see is "JVM Heap + Native Memory". That's why this number is always higher than the Heap Usage.
So, when the JVM quits stating "out of memory" error, it does not necessarily mean it has run out of Heap (in your case it definitely is not running out of Heap). But it could mean it runs out of Native Memory.
Now, as I mentioned earlier Native Memory is limited by the OS itself. We'll need to find out what is the maximum size a process can grow in Solaris 10 64bit (In 32 Bit OSs, it cannot grow beyond 2GB). With Solaris 10, I know you can set this "Maxsize" for individual processes/projects.
So, find out what is the memory utilized by the process itself (Not JVM heap). Use TOP to find out what's the "SIZE" of the process. Let's see if it always break after reaching certain size.
As far -Xms and -Xmx, I normally wouldn't recommend setting this to all the Apps. It makes the JVM work harder during GCs because it needs to go through the entire 2.5GB. Generally I recommend setting this to half of the Max heap initially. If your memory utilization is always lingering close to 2GB,then you can set both -Xms and -Xmx the same.

How to setup log file rotation from admin console in WAS

Here is procedure Application servers > xyzserver > Process Definition > Logging and Tracing > JVM LogsFile Name: ${SERVER_LOG_ROOT}/SystemOut.logFile Formatting Basic (Compatible) Advanced Log File Rotation File Size -> check boxeMaximum Size ->10 MBTime -> check boxe 24 Start Time ->24 Repeat Time ->24 hours Maximum Number of Historical Log Files. Number in range 1 through 50. 2

How to change administrative console session timeout in WAS:

Here is the procedure:
Through Unix box:
Edit the /systemApps/adminconsole.ear/deployment.xml file in a text editor.
Locate the xml statement, as shown below:
maxInMemorySessionCount="1000" allowOverflow="true"
writeFrequency="TIME_BASED_WRITE" writeInterval="10"
writeContents="ONLY_UPDATED_ATTRIBUTES" invalidationTimeout="30">
b. Change the invalidationTimeout value to the desired session timeout and save the file.
2. Restart the console.
Through Admin console:
Go to: Server -> Application Server -> Your Server -> Web Container -> Session Management
In Session time out section of the window, you can select No time-out or Set time-out by clicking the appropriate radio button. If you choose to set the time-out, type the desired value in minutes in the box.

What is a deployment descriptor in WAS?

A deployment descriptor (DD) refers to a configuration file for an artifact that is deployed to some container/engine.
In the Java Platform, Enterprise Edition, a deployment descriptor describes how a web application or enterprise application should be deployed. It directs a deployment tool to deploy a module or application with specific container options, security settings and describes specific configuration requirements. XML is used for the syntax of these deployment descriptor files.
For web applications, the deployment descriptor must be called web.xml and must reside in a WEB-INF subdirectory at the web application root.
For Java EE applications, the deployment descriptor must be named application.xml and must be placed directly in the META-INF directory at the top level of the application .ear file.

What is WebSphere Portal?

WebSphere Portal is a framework--including a runtime server, services, tools, and many other features--that you can use to integrate your enterprise into a single, customizable interface called a portal (a website). An enterprise portal combines components, applications, processes, and content from a wide variety of sources into a unified presentation, which your users can access from a wide variety of devices.
You can customize the portal based on user or job roles, security needs, device settings, personal preferences, and administrative settings. You can also define workflows to support your business processes. You can manage your portal's content using IBM's Web Content Management, which is integrated with WebSphere Portal. Figure 1 shows an example company portal
A portal can be best described as a web site that acts as a "point of entry" or a gate to a larger system. While it seems pretty difficult to define a portal in the strictest sense, these are some of the common features of portals:
Content aggregation:
Portals tend to aggregate content from multiple, disparate sources and provide one unified view of the same.
Personalization:
This refers to the ability of the portal to tailor the content/services that it offers according to the user of the portal.
Search:
Most if not all portals, offer some form of searching of it's content and sometimes even content from external sources.
Single Sign On:
Allows users to authenticate once to the portal and thereby allows access to many other systems without the need for re authentication.

Detecting hung threads in J2EE applications

A common error in J2EE applications is a hung thread. A hung thread can result from a simple software defect (such as an infinite loop) or a more complex cause (for example, a resource deadlock). System resources, such as CPU time, might be consumed by this hung transaction when threads run unbounded code paths, such as when the code is running in an infinite loop. Alternately, a system can become unresponsive even though all resources are idle, as in a deadlock scenario. Unless an end user or a monitoring tool reports the problem, the system may remain in this degraded state indefinitely.
The hang detection option for WebSphere Application Server is turned on by default. You can configure a hang detection policy to accommodate your applications and environment so that potential hangs can be reported, providing earlier detection of failing servers. When a hung thread is detected, WebSphere Application Server notifies you so that you can troubleshoot the problem.
Using the hang detection policy, you can specify a time that is too long for a unit of work to complete. The thread monitor checks all managed threads in the system (for example, Web container threads and object request broker (ORB) threads) . Unmanaged threads, which are threads created by applications, are not monitored.
When WebSphere Application Server detects that a thread has been active longer than the time defined by the thread monitor threshold, the application server takes the following actions:
Logs a warning in the WebSphere Application Server System.Out log file that indicates the name of the thread that is hung and how long it has already been active. The following message is written to the log: WSVR0605W: Thread threadname has been active for hangtime and may be hung. There are totalthreads threads in total in the server that may be hung.
where: threadname is the name that appears in a JVM thread dump, hangtime gives an approximation of how long the thread has been active and totalthreads gives an overall assessment of the system threads.
Issues a Java Management Extensions (JMX) notification. This notification enables third-party tools to catch the event and take appropriate action, such as triggering a JVM thread dump of the server, or issuing an electronic page or e-mail. The following JMX notification events are defined in the com.ibm.websphere.management.NotificationConstants class:
TYPE_THREAD_MONITOR_THREAD_HUNG: This event is triggered by the detection of a (potentially) hung thread.
TYPE_THREAD_MONITOR_THREAD_CLEAR: This event is triggered if a thread that was previously reported as hung completes its work.
Triggers changes in the performance monitoring infrastructure (PMI) data counters. These PMI data counters are used by various tools, such as the Tivoli Performance Viewer, to provide a performance analysis.
False Alarms
If the work actually completes, a second set of messages, notifications and PMI events is produced to identify the false alarm. The following message is written to the System.out log: WSVR0606W: Thread threadname was previously reported to be hung but has completed. It was active for approximately hangtime. There are totalthreads threads in total in the server that still may be hung.
where threadname is the name that appears in a JVM thread dump, hangtime gives an approximation of how long the thread has been active and totalthreads gives an overall assessment of the system threads.
Automatic adjustment of the hang time threshold
If the thread monitor determines that too many false alarms are issued (determined by the number of pairs of hang and clear messages), it can automatically adjust the threshold. When this adjustment occurs, the following message is written to the System.out log: WSVR0607W: Too many thread hangs have been falsely reported. The hang threshold is now being set to thresholdtime.
where: thresholdtime is the time (in seconds) in which a thread can be active before it is considered hung.
You can prevent WebSphere Application Server from automatically adjusting the hang time threshold.

How to configure JDBC and datasource in WAS

Configuration:
à AdminConsoleà Resourcesà JDBCprovidersÃ
à Select the scope (cell level or node level)
à click new
à select the Database type (Sybase,oracle,etc)
à select the provider type (oracle jbdc driver)
à select the implementation type (connection pool)
à click on the driver
à select the DataSource
à Click on new
à give a name to the datasource
à oracleDatasourceProperties(URL:jdbc:oracle:thin:@192.168.1.14:1521:XE)
à click on J2EE Connector Architecture (J2C) authentication data entries
à Give username and password and
à give the component-managed authentication aliases
à and set the environment variable
à go to Environmentà websphere variablesà click on the level-à click on
newà Oracle_jdbc_driver_path and give the address of the 14.jar
-Ã Test the connection

Changing the administrator password in WAS

The user ID and password that you enter during installation are considered the administrator ID and password for the site. You can change the password to better secure your environment.
Follow this procedure, in the event that you must change the password of the user account for which your LDAP is connecting to IBM® Workplace™ Services Express. Note that there are four distinct possible user passwords: WebSphere® admin, WebSphere Portal admin, LDAP bind, LDAP admin. They can be all the same user or different users.
Preparation:
Shut down the HTTP servers to help prevent unauthorized accesses and interference.
Back up the following files:
/was_home/config/cells/cellname/security.xml
/was_home/properties/soap.client.props
/wps_home/shared/app/wmm/wmm.xml
Remove user credential information from WAS_HOME/properties/soap.client.props. These values allow you to stop the WebSphere servers without a user name and password. Once you have cleared these, you will need to issue a stopServer command with '-username' and '-password' switches.
Start just enough to use the console: WebSphere_Portal and the NetworkServer (Cloudscapeâ„¢ database) should be running. Shut down other WebSphere applications.
If you are using LDAP, continue to step 2. If you are not using LDAP, follow this procedure to change the password for the Portal administrator:
Log in to the site as the Portal administrator.
Click Edit my profile.
Change your password in the appropriate box.
Save, exit and logoff.
At the WebSphere Application Server administrative console (http://yourServer:9091/admin ), log in as the WebSphere Application Server administrator. Click Security > Global Security, and deselect Enabled. Change nothing else at this time. Click OK and Save.
Restart WebSphere_Portal:
/was_home/bin/stopServer.sh WebSphere_Portal -username wpsadmin -password wpsadmin
/was_home/bin/startServer.sh WebSphere_Portal
If you are not using LDAP, skip to step 4. Otherwise, change the passwords for WAS admin, WebSphere Portal admin, LDAP admin, and LDAP bind as necessary on the LDAP server using your LDAP vendor's instructions.
Update WebSphere Application Server security settings. At the WebSphere Application Server administrative console (http://yourServer:9091/admin ), log in as the WebSphere Application Server administrator. There will be no password challenge.
Update the server user password. Click Security > User Registries > LDAP. In the Server User Password field, enter the new WebSphere Application Server admin password. Make sure 'Custom' directory type is selected (this will prevent the Advanced LDAP settings from being reset to defaults). Select Custom if necessary. Click OK and Save.
Update the LDAP Bind password. Click Security > User Registries > LDAP In the Bind password field, enter the new LDAP bind password. Make sure 'Custom' directory type is selected (this will prevent the Advanced LDAP settings from being reset to defaults). Select Custom if necessary. Click OK and Save.
Update the custom user password. Click Security > User Registries > Custom. In the Bind password field, enter the new WSE/Portal admin user password. Click OK and Save.
Click Security > Global Security. Select Enabled and then deselect Enforce Java 2 Security. Change nothing else at this time. Click OK and Save.
Restart the WebSphere Portal server.
Restart WebSphere Portal using the following commands:
/was_home/bin/stopServer.sh WebSphere_Portal
/was_home/bin/startServer.sh WebSphere_Portal
Repopulate soap.client.props. (This step is optional. But if you choose to skip this step, you must enter the stopServer command with the -username and -password arguments.) Populating soap.client.props user credential allows you to stop secured WebSphere applications without entering a password on the command line. The WebSphere Application Server provides a property encoding script with which you may encode the passwords contained within the /was_home/properties/soap.client.props.
Open /was_home/properties/soap.client.props.
Enter your WSE/Portal admin user for com.ibm.SOAP.loginUserid and password for the com.ibm.SOAP.loginPassword properties. For example: apricot:/opt/IBM/Workplace Services Express/AppServer/properties # ../bin/PropFilePasswordEncoder.sh soap.client.props com.ibm.SOAP.loginPassword
where
/opt/IBM/WorkplaceServicesExpress/AppServer/properties is the directory from which this command is initiated
../bin/PropFilePasswordEncoder.sh is the script executed
soap.client.props is the file containing the strings to be encoded
SOAP.loginPassword is the property to encode
Set this password value for each of the specified Enterprise Applications listed below by using the specified sequence of steps.
For each of these applications:
LWP_CAI
LWP_Discussion_Service
LWP_Security
LWP_Team_Task_List
LWP_Template_Infrastructure
Repeat these steps:
In the WebSphere Application Server administrative console, select an Enterprise Application.
Click Additional Properties > Map security roles to users/groups > Select wpsRunAsAdmin role.
Click Lookup groups and in Search, type the name of the group in which the admin user is defined. Click Search. In the list labeled Available, select the WSE/Portal admin user and click >> to add to Selected. Click OK, and OK again.
Click Additional Properties > Map RunAs roles to users. Select the wpsRunAsAdmin role.
At the user prompt, type the short name of your WSE admin user. At the password prompt, type the new password.
Click Apply --> OK --> OK. It is essential that you use this exact progression. Otherwise the process may fail.
When you have finished, click Save - Save to the Master Configuration.
If you are not using LDAP, skip to step 10. Otherwise, configure WMM for a new LDAP admin password.
On the Application server file system, open the directory /was_home/wmm/bin and run the wmm_encrypt.sh or wmm_encrypt.bat script, using the password of the LDAP admin user (for example: /wmm_encrypt.sh newpassword). Copy the output value as the 'ASCII encrypted string.'
Open wps_home/shared/app/wmm/wmm.xml with your favorite editor. Replace the value of adminPassword with the ASCII encrypted string. Save it.
Restart the servers.
Restart NetworkServer (Cloudscape database), using the following commands:
/install_root/PortalServer/rootscripts/subtasks/stopNetworkServer.sh
/install_root/PortalServer/rootscripts/subtasks/startNetworkServer.sh
Restart WebSphere_Portal, using the following commands:
/was_home/bin/stopServer.sh WebSphere_Portal (if soap.client.props has not been populated within the new info, -username and -password switches are necessary)
/was_home/bin/startServer.sh WebSphere_Portal
Within IBM Workplace Services Express, update your credential vault password: http://yourServer/lwp/workplace.
Log in as the Portal administrator.
Click Administration >Access > Credential Vault and select Manage System Vault Slots.
Click Modify for deployment.user.
Enter the password for that user and confirm. Click OK to accept. The credential vault change takes effect upon the next server restart.

JDBC types and drivers:

Type 1: JDBC-ODBC Bridge
The type 1 driver JDBC-ODBC Bridge translates all JDBC calls into ODBC (Open
DataBase Connectivity) calls and sends them to the ODBC driver. As such the
ODBC driver as well as in many cases the client database code must be
present on the client machine.
Type 2: Native-API/partly Java driver
JDBC driver type 2 -- the native-API/partly Java driver -- converts JDBC
calls into database-specific calls for databases such as SQL Server Informix
Oracle or Sybase. The type 2 driver communicates directly with the database
server; therefore it requires that some binary code be present on the client
machine.
Type 3: Net-protocol/all-Java driver
JDBC driver type 3 -- the net-protocol/all-Java driver -- follows a
three-tiered approach whereby the JDBC database requests are passed through the
network to the middle-tier server. The middle-tier server then translates the
request (directly or indirectly) to the database-specific native-connectivity
interface to further the request to the database server. If the middle-tier
server is written in Java it can use a type 1 or type 2 JDBC driver to do this.
Type 4 Pure Java Driver
Type 4 JDBC drivers are direct-to-database pure Java drivers ("thin"
drivers). A Type 4 driver takes JDBC calls and translates them into the network
protocol (proprietary protocol) used directly by the DBMS. Thus client machines
or application servers can make direct calls to the DBMS server. Each DBMS
requires its own Type 4 driver; therefore there are more drivers to manage in a
heterogeneous computing environment but this is outweighed by the fact that
Type 4 drivers provide faster performance and direct access to DBMS features.

Root causes for HTTP 404 errors:

Based on symptoms that customers report, we can usually narrow the problem down to one of two types:
1) Page cannot be displayed or JSP/JSF error
2) WebGroup/virtual host not defined
STEP 1. Page cannot be displayed or JSP/JSF error
When we have a “Page cannot be displayed” error and the resource is a JSP page, JSF page, or servlet, or the browser is displaying a JSP error, initiate the following actions:
a. Verify that the Web server plug-in is working correctly
b. Verify that the URL that is causing the error is specified correctly
c. Verify that the Web server is responding
d. Verify that the application is running

HTTP 404 errors:

HTTP 404 errors can have different underlying causes. Some examples of these causes are:
Ø External factors, such as a problem in the Web server
Ø Configuration problems, such as an incorrect Web server plug-in or virtual host configuration
Ø Runtime problems, such as an application or application server not started
Ø User or application problems, such as an incorrectly specified URL
The first thing to check is the integrity of the following system components:
1) Web server à Resolve Web server problems
2) Application server à Verify that App srvr is started
3) Application à Verify that App is started
If these are all working properly or you are not sure which application and server are involved, collecting more information like: Error messages, Logs and try to analyze them.
Ø Errors displayed by the user browser, including the URL that failed
Ø SystemOut log data for the app server
Ø If application is deployed to a cluster, you might need to collect the logs from each active server in the cluster
Ø Web server access and error logs

Session Persistence

1. Session object cached in memory by server.
2. Session object will be lost if server fails.
3. Two methods to enable persistence and overcome this problem.
· Database.
· Session objects persisted using JDBC data source.
4. DB2 included in WebSphere Application Server package for session persistence.
5. Memory-to-Memory replication.
6. Sessions copied to another server using WebSphere Internal Messaging.
7. Multiple topology models possible:
· Single Replica
· N-way peer-to-peer
· Client/server (Dedicated replication server)
· Can specify when replication performed
· Data transfer between JVMs can be encrypted
· Better performance than database persistence
To support failover, a mechanism is required that enables another server to access the session object if the primary server handling the session fails. WebSphere Application Server V5 supports two methods of persistence:
Database - a database can be configured for session persistence. You can define a JDBC provider and data source and configure this for session persistence in the session manager configuration. Various options are provided to balance performance and recovery in this configuration. Database access is relatively slow, and could slow down activities, but caching helps ease that problem by reducing the number of reads to the database.
Memory to Memory replication is a process whereby in-memory session data can be copied over to another server’s memory. Memory-to-memory replication can use one of three basic topologies - Single replica, peer-to-peer, and client/server. Each has advantages depending on the scenario. When to persist is also configurable - at the end of each request, at a timer interval, or when directed by the application code - which is to say, when the synch() method is called. Memory to memory session replication has all the features that database persistence has (except the database-specific options, like row size) and the traffic can be encrypted. It is available in WebSphere Application Server Network Deployment and editions above this. Session persistence to memory has some performance advantages over database persistence, and scales well.

Connection pool settings

This administrative console page is common to a range of resource types: for example, JDBC data sources and JMS queue connection factories. To view this page, the path depends on the type of resource, but generally you select an instance of the resource provider, then an instance of the resource type, then click Connection Pool.

For example, click Resources > JDBC Providers > JDBC_provider > Data Sources > data_source > Connection Pool. The path for JMS queue connection factories is: Resources > JMS Providers > Default Messaging > JMS Queue Connection Factory > JMS_queue_connection_factory > Connection Pool Properties.
Configuration tab
Connection Timeout
Specifies the interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown.
This value indicates the number of seconds a request for a connection waits when there are no connections available in the free pool and no new connections can be created, usually because the maximum value of connections in the particular connection pool has been reached. For example, if Connection Timeout is set to 300, and the maximum number of connections are all in use, the pool manager waits for 300 seconds for a physical connection to become available. If a physical connection is not available within this time, the pool manager initiates a ConnectionWaitTimeout exception. It usually does not make sense to retry the getConnection() method; if a longer wait time is required you should increase the Connection Timeout setting value. If a ConnectionWaitTimeout exception is caught by the application, the administrator should review the expected connection pool usage of the application and tune the connection pool and database accordingly.

If the Connection Timeout is set to 0, the pool manager waits as long as necessary until a connection becomes available. This happens when the application completes a transaction and returns a connection to the pool, or when the number of connections falls below the value of Maximum Connections, allowing a new physical connection to be created.
If Maximum Connections is set to 0, which enables an infinite number of physical connections, then the Connection Timeout value is ignored.
Data type
Integer
Units
Seconds
Default
180
Range
0 to max int
Maximum Connections
Specifies the maximum number of physical connections that you can create in this pool.
These are the physical connections to the backend resource. Once this number is reached, no new physical connections are created and the requester waits until a physical connection that is currently in use returns to the pool, or a ConnectionWaitTimeoutException is thrown. For example: If the Max Connections value is set to 5, and there are five physical connections in use, the pool manager waits for the amount of time specified in Connection Timeout for a physical connection to become free.
Knowing the number of connection pools that can potentially request connections from the backend (such as a DB2 database or a CICS server) helps you determine a value for the Maximum Connections property.
For multiple standalone application servers that use the same data source configuration, or J2C connection factory configuration, a separate physical connection pool exists for each server. If you clone these same application servers, WebSphere Application Server implements a separate connection pool for each clone.

All of these connection pools correspond to the same data source or connection factory configuration. Therefore all of these connection pools can potentially request connections from the same backend resource, at the same time. The single Maximum Connections value that you set on this console panel applies to every one of these connection pools. Consequently, setting a high Maximum Connections value can result in a load of connection requests that overwhelms your backend resource.
Data type
Integer
Default
10
Range
0 to maximum integer
If Max Connections is set to 0, the Connection Timeout value is ignored.
Tip: For better performance, set the value for the connection pool lower than the value for the Max Connections option in the Web container. Lower settings, such as 10-30 connections, perform better than higher settings, such as 100.
You can use the Tivoli Performance Viewer to find the optimal number of connections in a pool. If the number of concurrent waiters is greater than 0, but the CPU load is not close to 100%, consider increasing the connection pool size. If the Percent Used value is consistently low under normal workload, consider decreasing the number of connections in the pool.
Minimum Connections
Specifies the minimum number of physical connections to maintain.
If the size of the connection pool is at or below the minimum connection pool size, the Unused Timeout thread does not discard physical connections. However, the pool does not create connections solely to ensure that the minimum connection pool size is maintained. Also, if you set a value for Aged Timeout, connections with an expired age are discarded, regardless of the minimum pool size setting.
For example, if the Minimum Connections value is set to 3, and one physical connection is created, the Unused Timeout thread does not discard that connection. By the same token, the thread does not automatically create two additional physical connections to reach the Minimum Connections setting.
Data type
Integer
Default
1
Range
0 to max int
Reap Time
Specifies the interval, in seconds, between runs of the pool maintenance thread.
For example, if Reap Time is set to 60, the pool maintenance thread runs every 60 seconds. The Reap Time interval affects the accuracy of the Unused Timeout and Aged Timeout settings. The smaller the interval, the greater the accuracy. If the pool maintenance thread is enabled, set the Reap Time value less than the values of Unused Timeout and Aged Timeout. When the pool maintenance thread runs, it discards any connections remaining unused for longer than the time value specified in Unused Timeout, until it reaches the number of connections specified in Minimum Connections. The pool maintenance thread also discards any connections that remain active longer than the time value specified in Aged Timeout.
The Reap Time interval also affects performance. Smaller intervals mean that the pool maintenance thread runs more often and degrades performance.
To disable the pool maintenance thread set Reap Time to 0, or set both Unused Timeout and Aged Timeout to 0. The recommended way to disable the pool maintenance thread is to set Reap Time to 0, in which case Unused Timeout and Aged Timeout are ignored. However, if Unused Timeout and Aged Timeout are set to 0, the pool maintenance thread runs, but only physical connections which timeout due to non-zero timeout values are discarded.

When to use connection pooling

Use WebSphere connection pooling in an application that meets any of the following criteria:
It cannot tolerate the overhead of obtaining and releasing connections whenever a connection is used.
It requires Java Transaction API (JTA) transactions within the Application Server.
It needs to share connections among multiple users within the same transaction.
It needs to take advantage of product features for managing local transactions within the application server.
It does not manage the pooling of its own connections.
It does not manage the specifics of creating a connection, such as the database name, user name, or password

Benefits of connection pooling

Connection pooling can improve the response time of any application that requires connections, especially Web-based applications. When a user makes a request over the Web to a resource, the resource accesses a data source. Because users connect and disconnect frequently with applications on the Internet, the application requests for data access can surge to considerable volume. Consequently, the total datastore overhead quickly becomes high for Web-based applications, and performance deteriorates. When connection pooling capabilities are used, however, Web applications can realize performance improvements of up to 20 times the normal results.
With connection pooling, most user requests do not incur the overhead of creating a new connection because the data source can locate and use an existing connection from the pool of connections. When the request is satisfied and the response is returned to the user, the resource returns the connection to the connection pool for reuse. The overhead of a disconnection is avoided. Each user request incurs a fraction of the cost for connecting or disconnecting. After the initial resources are used to produce the connections in the pool, additional overhead is insignificant because the existing connections are reused.

What are the benefits of Connection pooling?

Using connection pools helps to both alleviate connection management overhead and decrease development tasks for data access.

Each time an application attempts to access a backend store (such as a database), it requires resources to create, maintain, and release a connection to that datastore. To mitigate the strain this process can place on overall application resources, the Application Server enables administrators to establish a pool of backend connections that applications can share on an application server. Connection pooling spreads the connection overhead across several user requests, thereby conserving application resources for future requests.

The Application Server supports JDBC 3.0 APIs for connection pooling and connection reuse. The connection pool is used to direct JDBC calls within the application, as well as for enterprise beans using the database.

Typical WebSphere security scenario

A typical user interaction with a secure application running under WebSphere might look something like this:
1. The user requests a protected resource in an enterprise application.
2. If security is enabled and properly configured, WebSphere intercepts the request to the protected resource. In this case, we are using Form-based Custom Login as the mode of authentication.
3. WebSphere presents the user with the custom login form page (in this case, login.jsp).
4. The user supplies credentials, typically in the form of user ID and password.
5. WebSphere authenticates using j_security_check, the default login servlet provided by WebSphere. Authentication can be based on either local operating system, LDAP or a custom registry.
6. If authentication is successful, the user gains access to the protected resource, provided that the user has the correct access rights, or roles, for the resource. If the authentication and authorization process is not successful, the user is unable to log in.

What is the difference between Web Server and Application Server?

Webserver:

A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Application Server:

As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object.

Difference between WAS 5.x and WAS 6.x.?

Latest Answer: WAS 6.x has all the features of WAS 5.x along with some additional features. Some of the features are:
1. Multiple profile creations with single installation.
2. Introduction of Service Integration Bus (SIB) for messaging.
3. Web servers and Generic servers.

Virtual host collection:

To view this administrative console page, click Environment > Virtual Hosts.
Each virtual host has a logical name (which you define on this panel) and is known by its list of one or more domain name system (DNS) aliases. A DNS alias is the TCP/IP host name and port number used to request the servlet, for example your Hostname: 80. (Port 80 is the default.)

You define one or more alias associations by clicking an existing virtual host or by adding a new virtual host. When a servlet request is made, the server name and port number entered into the browser are compared to a list of all known aliases in an effort to locate the correct virtual host to serve the servlet. No match returns an error to the browser.
An application server profile provides a default virtual host with some common aliases, such as the internet protocol (IP) address, the DNS short host name, and the DNS fully qualified host name. The alias comprises the first part of the path for accessing a resource such as a servlet.

Profiles, profile managers, and targets:

A profile is a collection of specific information about a Tivoli software product. Each item in a profile contains system configuration information. The information in a profile is specific to the particular profile type. Profile records are stored in a platform-independent format that allows the same profile records to be distributed across an environment that contains multiple platforms.
A profile manager is a container for individual profiles. It provides a place to create and organize groups of profiles and to link subscribers, or recipients, to them. A profile manager can contain multiple profiles of the same type, or it can contain profiles of more than one type. Profile managers control the distribution of profiles to subscribers. Profile managers are created within a policy region. Subscribers to a profile manager can be in the same policy region as their profile manager or in other policy regions.

Edge Server Load Balancer :

The load balancer distributes workload among HTTP servers in a cluster. The load balancer is also known as a network dispatcher.

Cluster:

A cluster is a logical collection of application server processes that are grouped together solely for the purpose of providing workload distribution and failover. Servers which are members of a cluster must all have identical application components deployed on them.
The servers that are members of a cluster can be on located on the same host computer and node, which is called vertical clustering, or on different host computers and nodes, which is called horizontal clustering.

A cluster is not the same as a cell. A WebSphere Application Server Network Deployment cell can have zero clusters, one cluster, or multiple clusters.

Deployment Manager:

Deployment Manager is a special application server which manages the configuration of multiple application servers across multiple nodes in a cell. Deployment Manager includes an Administrative Console for implementing the configuration management.
Deployment Manager is available with the Network Deployment edition of WebSphere Application Server, version 6

Node and node agent:

A node is a logical grouping of WebSphere Application Server managed server processes that share common configuration control. A node usually corresponds to a physical computer with a distinct IP address. A node is normally associated with one physical installation of WebSphere Application Server. The node name is typically identical to the host name of the computer.
A node contains one or more application servers, XML configuration files, and an activated node agent. The node agent communicates with the cell's Deployment Manager to manage that set of servers on the node.

Node and node agent:

A node is a logical grouping of WebSphere Application Server managed server processes that share common configuration control. A node usually corresponds to a physical computer with a distinct IP address. A node is normally associated with one physical installation of WebSphere Application Server. The node name is typically identical to the host name of the computer.
A node contains one or more application servers, XML configuration files, and an activated node agent. The node agent communicates with the cell's Deployment Manager to manage that set of servers on the node.

Cell:

A group of related nodes and their node agents constitute a cell. Administrators define the nodes that make up a cell according to criteria that is appropriate in their environment.

A cell contains a Deployment Manager from which all the administrative tasks for the nodes in that cell are handled. Deployment Manager for the cell has a master configuration repository that contains the configuration data for the nodes and servers within the cell. Configuration changes made at the cell level are propagated to the nodes and servers the next time synchronization occurs. Therefore, all configuration changes must be made at the cell level.

Although each node and server in a cell have their own local configuration files, configuration changes made at the node or server level are temporary and will be overlaid with the data from the cell repository maintained by the Deployment Manager.

Application server:

An application server extends the ability of an HTTP server to handle Web application requests, and allows a server to generate dynamic, customized responses to client requests.