Updated strategy for WebSphere Application Server v8 : fixpacks, feature packs, fixes and maintenance


WebSphere Application Server Support is delivering this strategy to provide a clear update path which is easier to maintain than managing multiple, individual Application Server fixes.

In response to requests for published collections of fixes that are:

  • Delivered in a timely manner
  • Tested together

WebSphere Application Server V8.0 will provide Fix Packs regularly (approximately every 3-4 months). This provides a consistent maintenance approach you can follow as you manage your products.

Installing preventative maintenance as soon as it becomes available will save you time. As long as you test appropriately, actively applying preventative maintenance can avoid problems that could result in a service call.


Read more @ http://www-01.ibm.com/support/docview.wss?uid=swg27023315

WebSphere Application Server v6.1 Fix pack silent installation notes

This is for all the readers who are using WebSphere Application Server v6.1. Below are the detailed instructions on how to install a fix pack using silent installation method.

Update Installer

Now you’ve downloaded the required fix pack files and update installer.

Installing Update Installer

  • Unpack the downloaded update installer file.
  • It creates a directory with name ‘updateinstaller’
  • Go to update install directory and look for ‘responsefile.updiinstaller.txt’ file. This file is template for silent installation.
  • Now open responsefile.updiinstaller.txt for editing
    • First you need to accept the license by changing below option to true.
      • -OPT silentInstallLicenseAcceptance
    • If you are installing as non-root, Uncomment the following.
      • -OPT allowNonRootSilentInstall=”true”
    • If you want to disable operating system prerequisite checking, uncomment the following line
      • -OPT disableOSPrereqChecking=”true”
    • If you want to disable the checking for existing Update Installer, uncomment the following line
      • -OPT disableEarlyPrereqChecking=”true”
    • Specify the install location of the product [installation directory for update installer]
      • -OPT installLocation=”WebSphere_root/UpdateInstaller”.
  • Now run the following command to install update installer silently [from the unpacked update installer directory]
    • install -silent –options “response_file_name”
  • This will install the update installer in websphere_root/UpdateInstaller

Download the fixpack

Response files

Now we need to create the response files for installing/applying the fix packs

  • Copy the extracted .pak files from the fix packs to websphere_root/UpdateInstaller/maintenance
  • Go to websphere_root/UpdateInstaller/responsefiles
  • Look for install.txt file
  • Copy install.txt as was_response.txt
  • Now open was_response.txt for editing
    • If you like the installer to check the file permissions before proceeding to install, uncomment the following line
      • -OPT checkFilePermissions=”true”
    • Specify the maintenance package to be installed using the option.
      • -W maintenance.package= “websphere_root/UpdateInstaller/maintenance/WAS_FPxxxx.pak
    • If you like to disable checking  of pre-requisites, uncomment the following like.
      • -OPT disableNonBlockingPrereqChecking=”true”
    • Specify where the websphere installation is using the below option.
      • -W product.location=”websphere_root”.
  • Save the changes to the response file

Applying fix pack

  • Now run the following command to apply the fixpack to websphere application server.
  • Go to websphere_root/UpdateInsaller
  • update.sh -silent -options <responsefile/response_file_name>

For installing fix pack for other components, follow the above stop as described for websphere application server fixpack. All you need to change is the location of the product location and maintenance package file path/names.

Important Notes

  1. Before applying fix pack, please stop all the websphere process on that machine, which are going to be affected.
  2. If you apply the fix pack as ‘root’ to a websphere installation which was installed as non-root, post fix pack installation, the entire product will be owned by ‘root’
  3. Before deciding on a fix pack, look for any security fixes released for that fix pack.  For example If you install FP35 for websphere 6.1 , you need to install a security fix pack for JDK.

WebSphere Core Groups

What is a core group?

A core group encapsulates processes in a Network Deployment cell to create high availability domains.

A core group is a grouping of WebSphere Application Server cell processes. A core group can contain standalone servers, cluster members, node agents, and the deployment manager. A core group must contain at least one node agent or the deployment manager.

DefaultCoreGroup is a core group that is created by default at installation time and can be used out-of-the-box; that is, all processes will know about each other.


1. A core group cannot extend beyond a cell

2. All JVMs in a core group must able to communicate (they use heartbeat messages to know each other)Read More »

Class Loader & ClassNotFound exception in WebSphere

A class loader is an object that is responsible for loading classes. The class ClassLoader is an abstract class. Given the name of a class, a class loader should attempt to locate or generate data that constitutes a definition for the class. A typical strategy is to transform the name into a file name and then read a class file of that name from a file system.

When a class loading request is presented to a class loader, it first asks its parent class loader to fulfill the request. The parent class loader, in turn, asks its parent for the class until the request reaches the top of the hierarchy. If the class loader at the top of the hierarchy cannot fulfill the request to load a class, then the child class loader that called it is responsible for loading the class. If the child is also unable to load the class, the request continues back down the hierarchy until a class loader fulfils it or a ClassNotFoundException is produced by the last class loader.



Each class loader is a child of the previous class loader. That is, the application module class loaders are children of the WebSphere extensions class loader, which is a child of the CLASSPATH Java class loader. Design and packaging of an application will determine the behavior of class loading. WebSphere provides the ability to change/modify the class loading behavior.

WebSphere Class Loaders:

WebSphere application server has 3 class loaders.

  • Application server class loader
    The application server class loader policy affects all applications that are deployed on the server.
  • Enterprise application class loader
    An application class loader is the parent class of an Enterprise application (EAR) and all modules within it. An application class loader groups enterprise bean (EJB) modules, shared libraries, and dependency Java archive (JAR) files associated to an application. Dependency JAR files are JAR files that contain code which can be used by both enterprise beans and servlets.
  • Web module class loader
    A web module has its own Web application archive (WAR) class loader to load the contents of the web module, which are in the WEB-INF/classes and WEB-INF/lib directories.

1. Application server class loader

Go to Servers –> Application Servers –> Server name


Look for the above options.

Classloader Policy

Single: Applications are not isolated from each other. Uses a single application class loader to load all of the EJB modules, shared libraries, and JAR files which are contained in all applications installed into the JVM.
Multiple: Applications are isolated from each other. Gives each application its own class loader to load the EJB modules, shared libraries, and JAR files.

Class loading mode

parent first: Sets the loading of classes to its parent class loader before attempting to load the class from its local class path. This is the default value for Class loading mode

parent last: Tells the class loader to start with loading classes from its local class path before asking its parent.

For each application server in the system, you can set the application class-loader policy to Single or Multiple. When the application class-loader policy is set to Single, then a single application class loader loads all EJB modules, dependency JAR files, and shared libraries in the system. When the application class-loader policy is set to Multiple, then each application receives its own class loader that is used for loading the EJB modules, dependency JAR files, and shared libraries for that application.

Note: If you’ve multiple application running on the same server (JVM) and if their classes are conflicting each other or Also some times it can happen that, application classes may conflict with the WebSphere classes. then we change the class loading mode option from default.

2. Application Class Loader

In general Enterprise applications (EAR) will have multiple web, ejbs or sometimes may include application client modules. Enterprise applications can also override settings within the contained
modules deployment descriptors to combine or deploy them. By placing JAR files in the enterprise application instead of the global class path of an application server, they are also within the application and thus they get deployed along with the application. The concept is that an EAR file encapsulates all its required resources and hence it can be pre-configured using some java techniques.

Go to Applications –> Enterprise applications –> Application name –> Class loading and updation


you can see the above options

Class loader order

Classes loaded with parent class loader first
Sets the loading of classes to its parent class loader before attempting to load the class from its local class path.
Classes loaded with application class loader first
Tells the class loader to start with loading classes from its local class path before asking its parent

WAR class loader policy

Class loader for each WAR file in application
A separate class loader is assigned to each WAR file.
Single class loader for application
One class loader is assigned to all WAR files.

An application class loader loads classes from Web modules if the application’s WAR class-loader policy is set to Application. If the application’s WAR class-loader policy is set to Module, then each WAR module receives its own class loader.

3. Web module class loader

Every web module will have 2 folders, WEB-INF/classes and WEB-INF/lib. The classes folder may contain Java classes within the web application. Then we can specify a class loader to looks at this folder to load those classes.  Remember these classes are only for that specific web module.


Class loader order

Specifies whether the class loader searches in the parent class loader or in the application class loader first to load a class. The standard for development kit class loaders and product class loaders is Classes loaded with parent class loader first. By specifying Classes loaded with application class loader first, your application can override classes contained in the parent class loader, but this action can potentially result in ClassCastException or LinkageErrors if you have mixed use of overridden classes and non-overridden classes.

Classes loaded with parent class loader first
If set, the class loader searches the application’s class loader for the class.
Classes loaded with application class loader first
If set, the class loader searches within the WAR class loader first to load a class.

Class-loader isolation

The number and function of the application module class loaders depend on the class-loader policies that are specified in the server configuration. Class loaders provide multiple options for isolating applications and modules to enable different application packaging schemes to run on an application server

Class loader isolation combinations

Type of Isolation Application server Class loader WAR class loader
Full Multiple WAR
Partial Multiple Application
Minimum Single Application

you might be wondering, where is the 4th option (Application server class loader – Single + WAR class loader WAR). Once you set the application class loader to Single, there is only one class loader for entire server. That’s why this option was not mentioned :-)

Tip: check the below link to learn about these policies with an example


The Enigma of WebSphere Application Server Plug-in, Part-2: Parameters that you can tune

In the first part of this series, we learned how the WebSphere application server plugin works and different components involved in its operation. In this second part, let us discuss different parameters that can affect the operation of the plugin and tuning options.

TCP timeout on operating system

This parameter controls when to drop a request when the client is not able to communicate with the server using TCP/IP. In case of the plugin, this parameter controls when the backend application server will be marked as down. For example, you have TCP/IP timeout on your linux operating system as 90sec and the plugin failed to communicate with an application server hosted on that machine, then it waits for the TCP/IP timeout setting and marks the server as down.

It is very important to know that since this parameter is set at operating system level, it will affect all other TCP/IP communications on that machine.

Connect timeout in plugin-cfg.xml

This setting allows plugin to perform a non-blocking connection with the backend server.

<Server CloneID=”abcd123x” LoadBalanceWeight=”2″ Name=”WASNClone1″ ConnectTimeout=”X”>

  • A value of ‘0’ allows plugin to perform non-blocking connection.
  • A value greater than 0 specifies the number of seconds you want the plug-in to wait for a successful connection. If a connection does not occur after that time interval, the plug-in marks the server unavailable and fails over to one of the other servers defined in the server group.
  • If no value is specified, the plugin wait until TCP/IP timeout occurs.

If no clone responds within the specified connect timeout, then a HTTP 500 error will be thrown.

When a clone is marked down, the plugin will retry for connection based on RetryInterval.

Plugin-log entry when connect timeout occurs

ERROR: ws_common: websphereGetStream: Connect timeout fired

ERROR: ws_common: websphereExecute: Failed to create the stream

ERROR: ws_server: serverSetFailoverStatus: Marking WASNClone1 down

ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to ‘WASNClone1’on host ‘test.josephamrithraj.com’; will try another oneRead More »