This section will highlight some commonly seen issues in Jazz environments, and the steps to take when encountering these issues. As more issues are encountered, it is strongly suggested that this section be updated, in order to preserve “institutional knowledge” about how to address these issues.
WebSphere
JVM Garbage Collection Pauses
The JVM in which the Jazz applications run uses JVM memory for the creation of objects in memory. Since this JVM allocates and deallocates memory on an continuous basis, at some point the JVM must stop and do “garbage collection”, where it goes through its allocated memory and marks areas that have been deallocated as being available. These “garbage collection” periods essentially halt application processing when they occur.
Since applications have a variety of needs and requirements for memory, a number of “garbage collection” algorithms are available to an application running within WebSphere. For more information on algorithms available, and their benefits, read
Java technology, IBM style: Garbage collection policies, Part 1 on the IBM Support website.
In most Jazz implementations, IBM suggests use of the following settings:
-Xmx4G
-Xms4G
-Xmn512M
-Xgcpolicy:gencon
-Xcompressedrefs
-Xgc:preferredHeapBase=0x100000000
Explanation:
-
-Xmx
sets the maximum memory size for the JVM. In this case, it is 4GB.
-
-Xms
sets the initial JVM heap size. In this case, it is also 4GB. It is strongly suggested that this should ALWAYS be equal to the –Xmx
parameter.
-
-XMn
sets the initial size of the new area (or nursery) in the JVM when using a “gencon” garbage collection policy. In this case it is 512M. For Jazz applications, a suggested ratio of 1:8 is suggested, with this value being 1/8 of the value specified for the maximum memory size.
-
-Xgcpolicy:gencon
sets the garbage collection policy. In this case I suggest the “gencon” policy. Note that some customers have seen improved performance when using the “optthruput” option. For more information on the relative merits of the various garbage collection algorithms, read Java technology, IBM style: Garbage collection policies, Part 1 on the IBM Support website.
-
-Xcompressedrefs
sets the JVM to use 32-bit values for references.
-
Xgc:preferredHeapBase=0x100000000
sets the base starting point for the JVM heap at the 1GB boundary.
LTPA Timeout errors in the WAS Logs (systemOut.log)
This is caused by the LTPA (which provides SSO authentication capabilities) tokens being either expired, or corrupted. These errors can be addressed in three ways. The first approach is to force the token to be reestablished, the second is to adjust the LTPA timeout, and the third is to just ignore these errors. For more information on this, see the
LTPA Token Expired error in WebSphere Logs with Rational Team Concert article on the IBM Support website. A nasty side effect of this error is that the
WebSphere logs grow quite large, as multiple entries are produced every second.
Approach #1 – Force Token
You can remove the LTPA Tokens which should eliminate the duplicate messages. To do this, do the following:
- Stop WebSphere
- Remove the LTPA key at
WAS_HOME/profiles/profileName/config/cells/cellName/nodes/nodeName/ltpa
- Restart WebSphere
Approach #2 – Adjust LTPA Timeout
You can also adjust the timeout for the LTPA, by following the procedure below:
- Click Launch WebSphere Admin Console to start the WebSphere Application Server console.
- In the WebSphere Application Server console navigation pane, click Security > Global security.
- In the Authentication area of the Global security page, click the LTPA link.
- In the LTPA timeout area of the LTPA page, edit the value for the LTPA timeout (make it an arbitrarily large number) and click OK.
- In the Messages area at the top of the Global security page, click the Save link and log out of the WebSphere Application Server console.
Follow these steps only on the application nodes. I have found that nodes fail to come up if jceks is removed from the deployment manager and proxy node.
Related topics: None
External links:
Additional contributors: None