This version provides many new features for troubleshooting and servicing the product, with a focus on the ability to automatically detect and recover from problems.
Many serviceability improvements are described in the IBM Education Assistant presentation: Serviceability enhancements.
Deprecated and removed features describes features that are being replaced or removed in this or future releases.
Improved ability to manage recovery from failure | To prevent the assignment of new work to an application server that is going through its transaction recovery process, restart the application server in recovery mode. |
IBM Support Assistant | The IBM Support Assistant (ISA) provides a
natural, look-here-first facility for issue resolution. It provides a single
point of access to problem determination tools and externally available Support
resources for the products you choose. It guides you through exploring and
resolving your immediate issue. You can:
|
New troubleshooting technology on the Support site | |
More diagnostic data is captured when failures occur | The first failure data capture (FFDC) feature preserves the information that is generated from a processing failure and returns control to the affected engines. The captured data is saved in a log file for analyzing the problem. FFDC is intended primarily for use by IBM Service. |
Class Loader Viewer | Class loaders find and load class files. For
a deployed application to run properly, the class loaders that affect the
application and its modules must be configured so that the application can
find the files and resources that it needs. Diagnosing problems with class
loaders can be complicated and time-consuming. To help you diagnose and fix
problems more quickly, use the administrative console Class Loader Viewer
to examine class loaders and the classes loaded by each class loader. Restriction: The Class Loader Viewer is not available
on the J9 Java virtual machine, which includes the AMD 64-bit platforms.
|
The troubleshooting documentation includes extensive support information, including the ability to search live, Web-based support resources by using the customized query fields in the "Web search" page.
Improved message text, new message IDs | Messages for key product components used during installation, migration, and initial configuration have been improved. Additional components have messages now. Message IDs will be changing in a future release. In the meantime, you can configure the application server to use the new message IDs to help prepare any tooling you may have that is reliant on message IDs. The Message Reference, which is available under Reference > Messages, provides a mapping of Version 5.1.x to Version 6.0.x message IDs. |
Common Base Events describe system situations | Common Base Events are data structures used
to describe situations that occur in the system. Common Base Events are used
for various purposes, including representing things such as business events,
configuration events, error events, and so on. The WebSphere Application Server
now uses Common Base Events as the internal representation of logged messages. Common Base Events are logged via JSR47 and as such can be received and operated on from JSR47 Handlers. Handlers which are not programmed to the Common Base Event specification will also be able to consume these events as CommonBaseEventLogRecords. Handlers which are programmed to the Common Base Event specification can take advantage of fields within the Common Base Events. |
More support for troubleshooting memory leak problems | To help you analyze memory leak problems when memory leak detection occurs, some automated heap dump generation support is available. See Enabling automated heap dump generation. WebSphere Application Server has implemented a lightweight memory leak detection mechanism that runs within the WebSphere Runtime Performance Advisor framework. This mechanism is designed to provide early detection of memory problems in test and production environments. This framework is not designed to provide analysis of the source of the problem, but rather to provide notification and help generating the information that is required to use analysis tools. The mechanism only detects memory leaks in the Java heap and does not detect native leaks. |
JRAS is deprecated | The JRAS API is deprecated. Users are directed
to use the JSR47 logging infrastructure instead. See Deprecated and removed features for more information about this and other deprecated items. |
Support for Jakarta Commons Logging is added | Jakarta Commons Logging provides a simple
logging interface and thin wrappers for several logging systems. WebSphere
Application Server version 6.0.2 supports Jakarta Commons Logging by providing a logger, a thin
wrapper for the WebSphere Application Server logging facility. The logger
can handle both Java
Logging (JSR47) and Common Base Event logging objects. The WebSphere Application Server support for Jakarta Commons Logging does not change interfaces defined by Jakarta Commons Logging. See Configuring applications to use Jakarta Commons Logging. |
Thread names can be included in logs | Thread name has been added to the Advanced
log format and Log analyzer trace format. The Log analyzer trace format preserves
trace information in the same format as produced by Showlog tool. The advanced
log format is available as an output format for the trace log and system out
log. The thread name is now included in this format to enable easier correlation
with other types of diagnostic data. The log analyzer format is available
as an output format for the trace log. The thread name is now included in
this format to enable easier correlation with other types of diagnostic data. See Trace output. |
Java logging framework from JSR47 is exploited | In J2SE 1.4, the Java logging framework was
introduced via JSR47. In WebSphere Application Server, messages and trace
logged to both JRAS and JSR47 logging APIs are passed into the JSR47 logging
infrastructure. This allows JSR47 Handlers connected to the root JSR47 Logger
to receive all WebSphere Application Server log content. JSR47 and JRAS Logger
levels can be controlled via the admin console troubleshooting section. WebSphere
Application Server also builds its logs from the JSR47 framework by connecting
its Handlers to the root Logger. The JSR47 Logging infrastructure allows for flexible pluggability of custom Handlers into the logging infrastructure to enable custom logs. By appropriate configuration, the Handlers can receive WebSphere Application Server's logged events, and events logged to Loggers instantiated by your applications. See Configuring Java logging using the administrative console. |