Serviceability Enhancements:
The WebSphere Application Server team is committed to improving the serviceability, usability, and installability of the product in each fixpack release. Our goal is to continuously make sure you, the customer, have a trouble-free user experience and are in a better position to easily diagnose any problem that may occur as you use the product.

"Serviceability" enhancements are improvements to the product that can help prevent a service call or speed up diagnostics either by you the customer or IBM support technicians.

Examples include:

• improved diagnostic messages
• more timely messages
• changed behavior to be more user-friendly
• improved traces (used by IBM support)
• improved documentation
  
  

These enhancements can help you avoid opening support ticket in the first place or collaboratively speed the resolution of cases that are opened.

This blog itemizes the Top 5 recent serviceability enhancements that have been implemented to meet this serviceability goal:

Top 5 Serviceability Enhancements in recent releases

1. Collector tool default heap size increased to 1 GB
Collector tool output is the most important resource for the WebSphere Application Server support team when debugging customer issues. Prior to this change, the default Java heap size was too small for some environments, and in a large environment, the tool could fail with an OutOfMemoryError. To resolve the error, customers needed to hand-edit the collector tool’s script in order to increase its allotted heap size.

With this serviceability enhancement, the default heap size of the collector tool was increased to 1 GB to ensure a more efficient and expedient use of the tool and ultimately a quicker response to your needs.

This serviceability enhancement is available in 9.0.5.7 and 8.5.5.19.
https://www.ibm.com/support/pages/apar/PH30984

2. Unshared connection behavior is changed in Liberty to avoid application connection leaks
Connection leaks are one of the top WebSphere Application Server connection pool issues. The application must follow a serial reuse (get/use/close) pattern to avoid connection leak problems, but unfortunately many customer applications are not following this pattern.  In WAS traditional, the WebSphere application server closes the orphaned connections at the end of the transaction boundary; however, in Liberty, these orphaned connections are not automatically closed.

We noticed this connection leak was a common condition for customers who are migrating from WAS traditional to Liberty. Even though this connection leak condition is an application issue, we have enhanced Liberty to close the orphaned connections at the end of the transaction boundary as well.

REMEMBER: Always close the connection after it has been used. WebSphere Application Server only closes these connections at the end of the transaction boundary.

This serviceability enhancement is available in Liberty 21.0.0.4.
https://github.com/OpenLiberty/open-liberty/issues/10907

3. Nodeagent to generate 3 javacores before restarting unresponsive application server
Is your application server not responding, or is it hung? Collecting a javacore from the unresponsive server is often necessary to identify the root cause. A server hang is a common issue, and it is often difficult to collect the data exactly when the server hang occurs, especially in production. This serviceability enhancement allows the nodeagent to dump 3 javacores (one every 15 seconds) automatically before restarting the hung app server. 

This serviceability enhancement is available in 8.5.5.19 and 9.0.5.6.
https://www.ibm.com/support/pages/apar/PH24396

4. Create javacore and stack dumps automatically when server stops or crashes unexpectedly
WebSphere application server provides a diagnostic property (-Dcom.ibm.ws.runtime.dumpShutdown) to produce additional data to debug unexpected server shutdowns. This diagnostic property must be specifically enabled to produce this additional data, requiring that you anticipate the issue in order to collect the necessary data. This serviceability enhancement attempts to detect unexpected shutdowns and produce the diagnostic data by default in those cases, allowing IBM support to debug the stop or crash condition without requiring you to enable the property and recreate the problem.

This serviceability enhancement is available in 8.5.5.19 and 9.0.5.7.
https://www.ibm.com/support/pages/apar/PH32612


5. Diagnostic plans to diagnose intermittent issues or remedy “difficult to recreate” scenarios
There are certain error conditions that can occur every few weeks or months where tracing has been left on to hopefully gather important data when the problem happens again. Leaving the tracing on for a long time can impact server performance, especially in production.

This serviceability enhancement helps you dump trace or core files automatically when a particular system issue or condition occurs. For example, you can capture an error code (e.g. “J2CA0045E”), any exception with a keyword (i.e., “ClassNotFound”,  "Initialization successful"), a hung thread (WSVR0605W), or any other error condition that is intermittent, using a diagnostic plan.

This serviceability enhancement is available in 9.0.0.8 and 8.5.5.15.
https://www.ibm.com/docs/en/was-nd/9.0.5?topic=tools-collecting-troubleshooting-data-diagnostic-plans

Please let us know in the comments if you have any feedback or questions.