IBM Support

PM52119: Fail-Fast support for dynamic cache


You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • If a WAS server containing a cache that is using the WXS
    dynamic cache provider is started before the WXS grid is
    on-line the WAS server will default to the WAS dynacache
    provider.   This can cause serious problems because the user
    may not see the error message in the log and go along happily
    until the cache grows to a point where memory is exhausted.
    Also,  if the WXS grid goes down during runtime, each
    dynacache request will time-out  (usually after 30 seconds).
     Since dynacache is used as a side cache this is unnecessary
    and will cause serious problems.

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of the WebSphere eXtreme Scale    *
    *                  Dynamic Cache Provider                      *
    * PROBLEM DESCRIPTION: WebSphere Application Server            *
    *                      will use the default dynamic            *
    *                      cache provider when the                 *
    *                      eXtreme Scale provider is specified     *
    *                      but                                     *
    *                      the grid is unavailable.                *
    * RECOMMENDATION:                                              *
    If WebSphere Application Server cache is configured to use the
    eXtreme Scale dynamic cache provider, but when the application
    server is started the grid is not yet available, then the
    application server will use the default and create a local
    cache using the WebSphere Application Server dynamic cache
    provider. This can cause severe problems since you expect for
    an eXtreme Scale grid to be used for the cache.
    Also, the local cache that is created will affect the
    available heap for the application server and can result in
    OutOfMemoryError errors.  Also, during run time, if the grid
    becomes unavailable, all dynamic cache invocations (get, put,
    invalidate, and so on) will hang until the request timeout
    is met, which is typically 30 seconds. This makes
    throughput much slower than running without a cache.

Problem conclusion

  • When the eXtreme Scale grid is not yet available, or becomes
    unavailable during run time, exceptions will be placed in the
    logs and the cache wrapper will return from invocations
    until the grid becomes available again.  Also, a thread will
    continually attempt to reconnect with the grid until it is
    successful. At which time, normal operations will continue.

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention


  • Submitted date


  • Closed date


  • Last modified date


  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name


  • Fixed component ID


Applicable component levels

  • R711 PSY


Document information

More support for: WebSphere eXtreme Scale

Software version: 711

Reference #: PM52119

Modified date: 18 November 2011

Translate this page: