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.
| New in V6.1! indicates new features or changes implemented at the V6.1 level. Unmarked items are V6.0 improvements that apply also to V6.1, which should interest anyone migrating to V6.1 from V5.x. |
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. |
| Easier and faster problem determination with diagnostic providers | New in V6.1! Diagnostic Providers
expose information about running components, enabling administrators to more
easily debug problems related to the components. You can detect problems faster
and access more information for determining and solving problems.
|
| 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. |
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 provides a mapping of V5.1.x to V6.0.x message IDs. The article Changing the message IDs used in log files explains how to make your application server use the new message IDs. In addition, the article Converting log files to use IBM unique Message IDs explains a command to create a log file with new message IDs based on a log file with the older message IDs. This command is provided to ease migration to the new message IDs, New in V6.1! Further work was performed to ensure messages and their component message IDs now correspond to IBM software standards, enabling better results when you use problem determination tools. Message documentation is improved to ensure messages are meaningful and explanatory. |
| 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. |
| Programming to Common Base Event infrastructure | New in V6.1! Developers can make use of the Common Base Event infrastructure for logging and to ensure that the events generated are consistent with events generated by the WebSphere runtime, whether or not the developer has chosen to use templates (event factory template or event templates). |
| 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. 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. |
| Memory leak detection enhancements |
Recreating memory leaks in a test environment is often difficult. To alleviate the problems associated with reproducing memory leaks in test environments, WebSphere Application Server uses light weight memory leak detection that is designed to run in production systems with minimal performance overhead. This functionality provides early notification of memory leaks, allowing time to diagnose the problem or arrange contingencies before it becomes critical. New in V6.1! Memory leak detection has been improved with new features that provide better support for memory leak diagnosis and troubleshooting. The Diagnostic Provider Interface provides users with the ability to perform a self diagnostic test that checks for any suspicious memory leaks. This self diagnostic allows problem determination tools to check the status of a memory leak without constantly monitoring WebSphere Application Server for notifications. In addition, new memory leak detection logic has been added to support detection with unbounded heaps. This feature provides more robust early notification for all platforms, even while the Java heap is still expanding. |
| 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. |