19.5 Configuring Caching and Cluster Settings

Caching allows you to manage various caches maintained by Identity Applications. These caches store the reusable data temporarily on the application server to optimize the system performance.

This page displays the cache settings (latest to your application restart). You can manage the cache collection mechanism by changing their configuration settings. You can also flush the cache contents, if necessary.

19.5.1 Flushing Caches

The caches are named according to the subsystems that use them in the Identity Manager User Application. Normally, you don’t need to flush them yourself, because the User Application does that automatically based on how frequently their data is used or when the source data changes. However, if you have a specific need, you can manually flush selected caches or all caches.

Go to Configuration > Caching and Cluster.
In Flush Cache, select the type of cache from the list that you want to flush.
Click Flush Cache.

Flushing the Directory Abstraction Layer Cache

The Identity Applications directory abstraction layer also has a cache. The DirectoryAbstractLayerDefinitions cache stores abstraction layer definitions on the application server to optimize performance for all data model operations.

In a typical situation, the Identity Applications automatically keeps the DirectoryAbstractLayerDefinitions cache synchronized with the abstraction layer definitions stored in the Identity Vault. But, if necessary, you can manually flush the DirectoryAbstractLayerDefinitions cache as described in Flushing Caches to force the latest definitions to be loaded from the Identity Vault.

For more information on the User Application’s directory abstraction layer, see NetIQ Identity Manager - Administrator’s Guide to Designing the Identity Applications.

Flushing Caches in a Cluster

Cache flushing is supported in both clustered and non-clustered application server environments. If your application server is part of a cluster and you manually flush a cache, that cache is automatically flushed on every server in the cluster.

19.5.2 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 restart Identity Applications server.

HINT:To restart the Identity Applications, you can 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).

How Caching Is Implemented

In the Identity Applications, 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.

How Cache Settings Are Stored

Two levels of settings are available for controlling cache configuration: global and local. Use these settings to customize the caching behavior of the Identity Applications.

There are two levels of settings available to control the cache collection on your application server:

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, If you have a cluster of application servers, the cluster configuration values use the global settings.

To find the global settings in your Identity Vault, look for the following object under your 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 to reassign a server to a different cluster.

Go to tomcat/conf/ism-configuration.properties, the sample local cache settings are:
```
com.sssw.fw.cache.LockAcquisitionTimeout = 15000
com.sssw.fw.cache.EvictionPolicyClass = org.jboss.cache.eviction.LRUPolicy
com.sssw.fw.cache.eviction.WakeUpIntervalSeconds = 4
```
When you enable the Local Settings option for a cache, the modified local settings are stored in the ism-configuration.properties file.

The global settings are the default values for every application server that uses a particular instance of User Application driver. Altering the global settings values affects every server unless it specifies local settings to override the global settings.

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).

The global settings always have values. The local settings are optional.

Changing Basic Cache Settings

Settings	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 might want to increase this setting if the Identity Applications imposes a lot of lock timeout exceptions in the application log. The default value is 15000 ms.
Wake Up Interval Seconds	Specify the time interval (in seconds) that the cache eviction policy waits before invoking the following activities: Processes the evicted node events. Cleanup the size limit and expired nodes.
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.
HINT:In Local Settings, select Enable Local for the required settings to override the global settings and specify the values.

Changing Non Customizable Cache Settings

Settings	What to do
Max Nodes	Specify the maximum number of nodes allowed in the cache. If you don’t want to restrict the number of nodes, specify 0.
Time To Live Seconds	Specify the time to idle (in seconds) before the node is swept away. If you don’t want to restrict the Time To Live Seconds, specify 0.
HINT:In Local Settings, select Enable Local for the required settings to override the global settings and specify the values.

Settings

What to do

Max Nodes

Specify the maximum number of nodes allowed in the cache.

If you don’t want to restrict the number of nodes, specify 0.

Time To Live Seconds

Specify the time to idle (in seconds) before the node is swept away.

If you don’t want to restrict the Time To Live Seconds, specify 0.

HINT:In Local Settings, select Enable Local for the required settings to override the global settings and specify the values.

Click Save to save your configuration values.

Changing Customizable Cache Settings

This allows you to customize certain cache holders in identity applications. To modify the cache holders:

Click the Cache Holder ID that you want to modify. For more information about Cache Holders, see Table 19-1, Customizable Cache Holders.
(Conditional) Change the required values such as Max Nodes, Time To Live Seconds, and Max Age.

NOTE:The system clears the events in the cache according to the value specified for Max Age.
(Conditional) In Local Settings, select Enable Local for the required settings to override the global settings and specify the values.
Click Save.

NOTE:You must restart the Tomcat on each node of the cluster for the changes to take effect.

Table 19-1 Customizable Cache Holders

Cache Holder Name	Description
Authorization.Admin.LevelsCacheHolder	Caches the Administrator type information of the logged in user such as a domain administrator, delegated administrator, team manager, or a business user (self-service). See, Administrator and Manager Categories.
DirectoryAbstractionLayerDefinitions	Caches the Directory Abstraction Layer definitions to optimize performance for all data model operations. See Flushing the Directory Abstraction Layer Cache.
DirectoryService.ContainerCacheHolder	Caches containers in the directory layer. Containers are shared by many users and groups, and reading them from the directory layer involves both network communication (with the LDAP server) and object creation. By default, the cache is limited to 50 containers, and the LRUs have a default Time To Live (TTL) of 10 minutes. Depending on the directory topography in your enterprise, you might need to adjust the maximum number of nodes or the TTL if you find the performance is suffering because of queries to the LDAP server for container objects. Making settings too high in combination with a large number of usable containers can cause unneeded memory consumption and net lower performance from the server.
DirectoryService.DelProxyRuntimeServiceDelegate	Caches delegate assignments.
DirectoryService.DelProxyRuntimeService.Delegation	Caches user availability settings.
DirectoryService.DelProxyRuntimeService.Delegator	Caches the delegator entities.
DirectoryService.DelProxyRuntimeService.Proxy	Caches proxy assignments.
DirectoryService.GroupCacheHolder	Caches groups in the directory layer. Groups are often shared by many users, and reading them from the directory layer involves both network communication (with LDAP server) and object creation. By default, the cache is limited to 500 groups, and the LRUs have a default TTL of 10 minutes. Depending on the user/group topography in your enterprise, you might need to adjust the maximum number of nodes or the TTL if you find the performance is suffering because of queries to the LDAP server for groups objects. Settings that are too high, in combination with a large number of usable groups, can cause unneeded memory consumption, and net lower performance from the server.
DirectoryService.MemberhipCacheHolder	Caches the relationship between a user and a set of groups. Querying the set of groups a user belongs to can be a network and CPU intensive operation on the LDAP server, especially if dynamic groups are enabled. For this reason, relationships are cached with an expiration interval so that changes in the criteria for inclusion/exclusion in a group (such as time-based dynamic groups) are reflected. The default Max Age is five minutes. However, if you use dynamic groups which have a requirement for finer grained time control, then you can adjust the Max Age on this cache holder to be just below the minimum time your finest grained time based dynamic group requires. The lower this value is, the more times the user's groups are queried during a session. Setting a value too high keeps the user/group relationships in memory perhaps longer than the user's session needlessly consuming memory.
DirectoryService.RolesMembershipCacheHolder	Caches the application role membership list by role.
DirectoryService.TeamManagerRuntime.Team	Caches the application team instances and team provisioning requests.
DirectoryService.UserCacheHolder	Caches users in the directory layer. Reading users from the directory layer involves both network communication (with LDAP server) and object creation. By default, the cache is limited to 1000 users, and the LRUs have a default TTL of 10 minutes. Depending on the user topography in your enterprise, you might need to adjust the maximum number of nodes or the TTL if you find the performance is suffering because of queries to the LDAP server for user objects. Making settings too high combined with a large number of different users logging in can cause unneeded memory consumption and net lower performance from the server.
GlobalCacheHolder	The general purpose cache holder. This configuration applies to all caches that are not customizable (that is, all cache holders not listed in this table.)
JUICE	Caches the resource bundles used by the user interface controls and DN display expression lookup results. Changing the setting of the cache holder has a performance impact for the DN display expression lookups because they are frequently used in the User Application. The low value should be at least 300 seconds, but a higher value than 900 seconds is ok. A lower value should be used if the customer is frequently changing the attributes that are used in the DN display expression
RoleManager.RolesCacheHolder	Caches user role memberships listed by the user.
Workflow.Model.Process	Caches the provisioning process XML object structure.
Workflow.Model.Request	Caches the provisioning request XML object structure.
Workflow.Provisioning	Caches provisioning request instances that have not completed. The default maximum capacity for the LRU cache is 500. The capacity can be modified by clicking the Administration/Provisioning and choosing the Engine and Cluster settings. The Process Cache Maximum Capacity appears on this page. This cache reduces the memory footprint for workflow processing without compromising performance.

19.5.3 Managing Cluster Cache Settings

Specify the following settings in Cluster Configuration that helps in caching across the cluster:

Setting	What to do
Permission Index Cluster Enabled	Enable this option if you want to update the permission index changes to the other nodes in the cluster for the specified Permission Index Group ID.
Permission Index Group Id	Specify the Permission Index 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.
Permission Index Cluster Properties	Specify the JGroups protocol stack for the cluster specified by Permission Index Group ID. This setting is to adjust the cluster properties.
Cluster Enabled	Enable this option if you want to overwrite the cache changes to the other nodes in the cluster for the specified Group ID.
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. The Group ID must be unique and must not match any of the known JBoss cluster names such as DefaultPartition and Tomcat-Cluster. 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. This setting is to adjust the cluster properties.
HINT:In Local Settings, select Enable Local for the required settings to override the global settings and specify the values.