PM52119: Fail-Fast support for dynamic cache

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

Comments

APAR Information

• 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

  WS EXTREME SCAL

• Fixed component ID

  5724X6702

Applicable component levels

• R711 PSY

     UP