Child pages
  • Tune Caches in OpenAM
Skip to end of metadata
Go to start of metadata
Caching in OpenAM

The two primary caches in OpenAM are for configuration data and user data, known as SMS and IdRepo respectively.  The OpenAM admin has some control over how these caches behave, described below.

Property: com.iplanet.am.sdk.caching.enabled

This property controls whether caching is enabled for both cache types and is set to true by default.  If this is set to false then both caches may be disabled (see below) and a new query will be issued to the data store whenever data is needed.  This can cause severe performance degradation in large deployments and should be used with caution.

 

Property: com.sun.identity.idm.cache.enabled

If the property com.iplanet.am.sdk.caching.enabled is true then this property is ignored.  If com.iplanet.am.sdk.caching.enabled is false then this property determines whether the IdRepo cache is enabled.

 

Property: com.sun.identity.sm.cache.enabled

If the property com.iplanet.am.sdk.caching.enabled is true then this property is ignored.  If com.iplanet.am.sdk.caching.enabled is false then this property determines whether the SMS cache is enabled.

Examples:

If you wanted to only enable the IdRepo cache then you would set:

com.iplanet.am.sdk.caching.enabled=false
com.sun.identity.idm.cache.enabled=true
com.sun.identity.sm.cache.enabled=false

If you wanted to only enable the SMS cache then you would set:

com.iplanet.am.sdk.caching.enabled=false
com.sun.identity.idm.cache.enabled=false
com.sun.identity.sm.cache.enabled=true

If you wanted to disable both the IdRepo and SMS cache then you would set:

com.iplanet.am.sdk.caching.enabled=false
com.sun.identity.sm.cache.enabled=false
com.sun.identity.idm.cache.enabled=false

 

Property: com.iplanet.am.sdk.cache.maxSize

The size of the IdRepo cache may be adjusted with this property.  By default this cache will contain up to 10,000 entries.  Note that there is no equivalent property to control the size of the SMS cache.

 

Property: com.sun.identity.idm.cache.entry.expire.enabled
Property: com.sun.identity.idm.cache.entry.default.expire.time

These properties control whether the IdRepo cache will expire entries based on time-to-live and how old entries may get before expiring.  By default the enabled property is False and the expire.time is 30 (the latter is expressed in minutes).

 

Property: com.sun.identity.sm.cache.ttl.enable
Property: com.sun.identity.sm.cache.ttl

These properties control whether the SMS cache will expire entries based on time-to-live and set the maximum time-to-live value.  By default these properties are false and 30 minutes respectively.  The TTL value is expressed in minutes.

 

In busy systems significant performance gains can be achieved by extending these time-to-live values but this must be balanced against the change rate of the underlying data.  User data (IdRepo cache) typically changes at a much higher rate than OpenAM configuration data so the IdRepo TTL should be kept relatively low while SMS TTL may be much higher.

 

Cache Invalidation

The cache invalidates entries via 3 possible mechanisms: TTL, Notifications or Polling.  With TTL invalidation entries will "expire" and require a refresh after their TTL times have elapsed since the last refresh.  TTL invalidation may be used in conjunction with Notifications or Polling though Notifications and Polling may not be used together.


Notifications

Notifications can only be sent is OpenAM is aware of the changes.  To ensure OpenAM is made aware of all such changes persistent search should be enabled:

Property: com.sun.identity.sm.enableDataStoreNotification
Property: com.sun.am.event.connection.disable.list

Set this property to true to enable notifications for SMS data changes and remove "sm" from the disable.list property.

 

To enable notifications (which are sent any time data is changed) the following properties must be set:

Property: com.sun.identity.sm.notification.enabled
Property: com.sun.identity.client.notification.url

Set enabled to true and set the url property to the notification endpoint that will receive the notifications and determine when to expire the SMS cache.  Note that the url property is shared with the IdRepo cache notifications.

 

Property: com.sun.identity.idm.remote.notification.enabled
Property: com.sun.identity.client.notification.url

Set enabled to true and set the url property to the notification endpoint that will receive the notifications and determine when to expire the IdRepo cache.  Note that the url property is shared with SMS cache notifications.

The com.sun.identity.client.notification.url property should be set to http://host.domain/openam/notificationservice where the host, domain (and port) identify the server hosting the ClientSDK, "openam" is the name of the deployed application and "notificationservice" remains as-is.

 

Polling

If you prefer to poll for changed data rather than use notifications, set the following properties:

Property: com.sun.identity.idm.remote.notification.enabled
Property: com.iplanet.am.sdk.remote.pollingTime

Set notification.enabled to false and set pollingTime to the poll frequency in minutes to enable polling for the IdRepo cache.

 

Property: com.sun.identity.sm.notification.enabled
Property: com.sun.identity.sm.cacheTime

Set notification.enabled to false and set cacheTime to the poll frequency in minutes to enable polling for the SMS cache.
  • No labels

6 Comments

  1. I'd like to point out that these caches are "just" server side caches. At least for some of them, if not all. It would be nice to mention the client side caches, that is J2EE agent, web agent, or SDK client caches on the protected applications side.

    I initiated this work at the following URL: http://cgrosjean.ldaptools.com/post/2013/01/14/About-OpenAM-agent-caches

  2. Unknown User (jason513)

    How can we invalidate the both IdRepo and SMS cache manually.?

    1. There is no current means to do so.  A recently filed RFE addresses the SMS cache: https://bugster.forgerock.org/jira/browse/OPENAM-3084. You could file an RFE for the IdRepo cache as well.

      1. Unknown User (jason513)

        But in above article under section "Cache Invalidation" it was mentioned that we can invalidate the cache on demand. Then I am wondering how can I invalidate a cache on manually?

        So is invalidating cache manually is different from invalidating a cache on demand?

        1. The article was misleading and has been updated.  Thank you for bringing that to our attention.  The key bit of misleading info was the word "manual" as there presently is no means to manually invalidate the cache.  With notifications enabled you could perhaps simulate a notification to force the receiver to invalidate its cache for those objects.  That's far from ideal, however, and not something we can officially support.

  3. As a note from my customer disabling cache appears to require a restart to take affect. This makes sense. If it was dynamic you could use that to "clear the cache".