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:
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/.
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.
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.
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).
Note that the global settings always have values. The local settings are optional.
These cache settings apply to both clustered and non-clustered application servers.
Go to the Caching page.
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:
|
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.
Click Save.
When you’re ready for your saved settings to take effect, restart the user application on the applicable application server(s).
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:
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/.
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.
There are two major steps required to use caching across a cluster:
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.
Enabling the use of that cluster in the user application’s cache configuration settings
See Configuring cache settings for clusters (below).
Once you have a cluster ready to use, you can specify settings for the support of caching across that cluster.
Go to the Caching page.
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.)
Click Save.
When you’re ready for your saved settings to take effect, restart the user application on the applicable application server(s).