What is new for troubleshooters
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.
Deprecated and removed features describes features that are being replaced or removed in this or future releases.
Tools and data capture
Improved ability to manage recovery from failure To prevent the assignment of new work to an appserver that is going through its transaction recovery process, restart the appserver 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 debug problems related to the components. You can detect problems faster and access more information for determining and solving problems.
- Some logged messages contain diagnostic provider IDs (DPIDs), enabling administrators or administrative programs to target requests for information to the components that logged a message.
- Use the administration console, administrators can work with diagnostic providers to...
- dump configuration data
- dump state information
- execute any self diagnostic tests that the corresponding component offers
- Diagnostic provider management APIs are provided to enable programmatic access to diagnostic provider function.
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:
- Search multiple IBM and non-IBM locations for the most pertinent support information
- Find and run serviceability tools easily.
- Obtain quick access to appropriate IBM resources such as product pages, support pages and news groups
- Open a service request electronically if you end up needing one.
- Submit IBM service requests by collecting and adding the system data IBM Support needs to analyze the software problem
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 Examine classes loaded by each class loader.
For a deployed application to run properly, class loaders must be configured so applications can find required files and resources. The Class Loader Viewer simplifies the diagnosis of problems, which can be complicated and time-consuming.
Messages
Improved message text, new message IDs Messages for key product components used during...
- installation
- migration
- initial configuration
...have been improved. Additional components have messages now.
Message IDs will be changing in a future release. You can configure the appserver to use the new message IDs.
The message reference provides a mapping of V5.1.x to V6.0.x message IDs.
For migration of older message IDs you can convert log files to use IBM unique Message IDs.
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.
Events
Common Base Events describe system situations Data structures used to describe situations that occur in the system. Common Base Events are used for representing things such as...
- business events
- configuration events
- error events
WAS 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 not programmed to the Common Base Event specification will also be able to consume these events as CommonBaseEventLogRecords.
- Handlers 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).
Memory leak detection
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.
WAS 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, WAS 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 WAS 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.
Logging
JRAS is deprecated The JRAS API is deprecated. Users are directed to use the JSR47 logging infrastructure instead. Support for Jakarta Commons Logging is added Jakarta Commons Logging provides a simple logging interface and thin wrappers for several logging systems. WAS version 6.0.2 supports Jakarta Commons Logging by providing a logger, a thin wrapper for the WAS logging facility. The logger can handle both Java Logging (JSR47) and Common Base Event logging objects. The WAS support for Jakarta Commons Logging does not change interfaces defined by 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. Java logging framework from JSR47 is exploited In J2SE 1.4, the Java logging framework was introduced via JSR47. In WAS, 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 WAS log content. JSR47 and JRAS Logger levels can be controlled via the admin console troubleshooting section. WAS 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 WAS's logged events, and events logged to Loggers instantiated by your applications.