r9 - 2013-05-14 - 11:46:50 - Main.sbeardYou are here: TWiki >  Deployment Web > DeploymentTroubleshooting > PerformanceTroubleshooting > PotentialFixesForCommonIssues

new.png Potential fixes for common issues

Authors: DanToczala, MichaelAfshar
Build basis: CLM 2012, Rational Team Concert 4.0.1, Rational Quality Manager 4.0.1, Rational Requirements Composer 4.0.1

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.


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:



  • -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:

  1. Stop WebSphere
  2. Remove the LTPA key at WAS_HOME/profiles/profileName/config/cells/cellName/nodes/nodeName/ltpa
  3. Restart WebSphere

Approach #2 – Adjust LTPA Timeout

You can also adjust the timeout for the LTPA, by following the procedure below:
  1. Click Launch WebSphere Admin Console to start the WebSphere Application Server console.
  2. In the WebSphere Application Server console navigation pane, click Security > Global security.
  3. In the Authentication area of the Global security page, click the LTPA link.
  4. 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.
  5. 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:

  • None

Additional contributors: None

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r9 < r8 < r7 < r6 < r5 | More topic actions
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.