13.3 Configuring cache settings

You can use the Caching page to display and change cache configuration settings for a clustered or non-clustered application server environment. Your changes are saved immediately, but they don’t take effect until the next user-application restart.

HINT:To restart the user application, you can do one of the following: reboot the application server; redeploy the application (if the WAR has been changed in some way); or force the application to restart (as described in your application server’s documentation).

To configure cache settings, you need to know about:

13.3.1 How caching is implemented

In the Identity Manager user application, caching is implemented via JBoss Cache. JBoss Cache is an open-source caching architecture that’s included with the JBoss Application Server but also runs on other application servers.

To learn more about JBoss Cache, go to www.jboss.org/.

13.3.2 How cache settings are stored

There are two levels of settings available for you to control cache configuration. You can use them in concert to tailor the caching behavior of the Identity Manager user application.

Level

Description

Global settings

Global settings are stored in a central location (the identity vault) so that multiple application servers can use the same setting values. For example, someone with a cluster of application servers would typically use global settings for the cluster configuration values.

To find the global settings in your identity vault, look for the following object under your Identity Manager user application driver:


configuration.AppDefs.AppConfig

For example:


configuration.AppDefs.AppConfig.MyUserApplicationDriver.MyDriverSet.MyOrg

The XmlData attribute of the configuration object contains the global settings data.

Local settings

Local settings are stored separately on each application server so that an individual server can override the value of one or more global settings. For example, you might want to specify a local setting to remove an application server from the cluster specified in the global settings, or maybe to reassign a server to a different cluster.

To find the local settings on your application server, look for the following file under your JBoss server configuration’s conf directory:


sys-configuration-xmldata.xml

For example:


jboss/server/IDM/conf/sys-configuration-xmldata.xml

If your server has local settings, that data is contained in this file. (If no local settings have been specified, the file won’t exist.)

You should think of global settings as the default values for every application server that uses a particular instance of the user application driver. When you change a global setting, you are affecting each of those servers (at the next user-application restart), except for those cases where an individual server specifies a local override.

13.3.3 How cache settings are displayed

The Caching page displays the current cache settings (from the latest user-application restart). It also displays the corresponding global and local values of those settings, and lets you change them (for use at the next user-application restart).

Description: Description: Illustration

Note that the global settings always have values. The local settings are optional.

13.3.4 Basic cache settings

These cache settings apply to both clustered and non-clustered application servers.

To configure basic cache settings:

  1. Go to the Caching page.

  2. In the Cache Configuration section of the page, specify global or local values for the following settings, as appropriate:

    Setting

    What to do

    Lock Acquisition Timeout

    Specify the time interval (in milliseconds) that the cache waits for a lock to be acquired on an object. You may want to increase this setting if the user application gets a lot of lock timeout exceptions in the application log. The default is 15000 ms.

    Eviction Policy Class

    Specify the classname for the cache eviction policy that you want to use. The default is the LRU eviction policy that JBoss Cache provides:

    
    org.jboss.cache.eviction.LRUPolicy
    

    If appropriate, you can change this to another eviction policy that JBoss Cache supports.

    To learn about supported eviction policies, go to www.jboss.org/.

    Wake Up Interval Seconds

    Specify the time interval (in seconds) that the cache eviction policy waits before waking up to do the following:

    • Process the evicted node events

    • Clean up the size limit and age-out nodes

    Max Nodes

    Specify the maximum number of nodes allowed in the cache. For no limit, specify:

    
    0
    

    Time To Live Seconds

    Specify the time to idle (in seconds) before the node is swept away. For no limit, specify:

    
    0
    

    These settings are required, which means that there must be a global value for each, and optionally a local value too.

    If you want to override the global value of a setting with a local value, select the Enable Local check box for that setting. Then specify the local value. (Make sure that all of your local values are valid. Otherwise, you won’t be able to save your changes.)

    NOTE:For those settings where Enable Local is unselected, any existing local values are deleted when you save.

  3. Click Save.

  4. When you’re ready for your saved settings to take effect, restart the user application on the applicable application server(s).

13.3.5 Cache settings for clusters

This section discusses how to configure caching when you run the Identity Manager user application across a cluster of application servers. You need to know about:

How clustering is implemented

In the Identity Manager user application, cluster support for caching is implemented via JGroups. JGroups is an open-source clustering architecture that’s included with the JBoss Application Server but also runs on other application servers.

The user application’s cluster consists of nodes on a network that run JGroups and use a common Group ID. By default, the Group ID provided for the user application’s cluster is a UUID that looks like this:

c373e901aba5e8ee9966444553544200

The UUID helps ensure uniqueness, so that the Group ID of the user application’s cluster doesn’t conflict with the Group IDs of other clusters in your environment. For instance, the JBoss Application Server itself uses two JGroups clusters and reserves the Group IDs DefaultPartition and TreeCache for them.

To learn more about JGroups, go to www.jboss.org/.

How caching works with a cluster

When you start the user application, the application’s cache configuration settings determine whether to participate in a cluster and replicate cache changes to the other nodes in that cluster. If clustering is enabled, the user application accomplishes this replication by sending cache entry invalidation messages to each node as changes occur.

Preparing to use a cluster

There are two major steps required to use caching across a cluster:

  1. Setting up your JGroups cluster

    This involves installing the JBoss Application Server to use the all configuration, and then distributing the Identity Manager user application (IDM.war) to every server in the cluster, typically by putting it in the farm directory.

  2. Enabling the use of that cluster in the user application’s cache configuration settings

    See Configuring cache settings for clusters (below).

Configuring cache settings for clusters

Once you have a cluster ready to use, you can specify settings for the support of caching across that cluster.

To configure cache settings for clusters:

  1. Go to the Caching page.

  2. In the Cluster Configuration section of the page, specify global or local values for the following settings, as appropriate:

    Setting

    What to do

    Cluster Enabled

    Select True to replicate cache changes to the other nodes in the cluster specified by Group ID. If you don’t want to participate in a cluster, select False.

    Group ID

    Specify the Group ID of the JGroups cluster in which you want to participate. There’s no need to change the default Group ID that’s provided for the user application’s cluster, unless you want to use a different cluster.

    Remember that the following Group IDs are reserved for use by the JBoss Application Server: DefaultPartition and TreeCache.

    HINT:To see the Group ID in logging messages, make sure that the level of the caching log (com.sssw.fw.cachemgr) is set to Info or higher.

    Cluster Properties

    Specify the JGroups protocol stack for the cluster specified by Group ID. Note that this setting is for experienced administrators who may need to adjust the cluster properties. Otherwise, you should not change the default protocol stack.

    To see the current cluster properties, click view.

    For details on the JGroups protocol stack, go to www.joss.org/wiki/Wiki.jsp?page=JGroups.

    If you want to override the global value of a setting with a local value, select the Enable Local check box for that setting. Then specify the local value.

    NOTE:For those settings where Enable Local is unselected, any existing local values are deleted when you save.

    Make sure that all nodes in your cluster specify the same Group ID and Cluster Properties. (To see these settings for a particular node, you must access the Identity Manager user interface running on that node — by browsing to the URL of the user interface on that server — and then display the Caching page there.)

  3. Click Save.

  4. When you’re ready for your saved settings to take effect, restart the user application on the applicable application server(s).