Access Manager SM Cache

We all know that configuration of Access Manager (AM, called OpenSSO for 8.0 release) is very sophisticated. It is nice to have fine granular control of this product. But some configuration property names are confusing and even the comments are not clear enough. Here I just want to share what I learned recently on those properties controlling the cache of SM (Service Management).

To have better performance, AM has caches implemented since day one. SM cache is available on both AM server and AM client. On the server side, SM cache gets updated whenever you make changes through AM console, or through persistent search from Directory Server if the changes are not made on AM console. This is not my topic today. I want to discuss SM cache on the client side here.

How does client side SM cache get updates? Initially updating AM client SM cache relies on notifications sent from AM server. Of course, this only works on those AM clients deployed in a web container. The notification URL is defined by property 'client.notification.url'.

Starting from AM6.2, a new property called 'sm.cacheTime' was introduced for polling changes from server. The value of cacheTime specifies the polling interval in minutes. This property is applicable only if 'client.notification.url' is not provided. If you set it as 0, polling would be disabled.

Since AM7.0patch5 and AM7.1patch2, another new property 'sm.notification.enabled' was added to get better control of polling. If it is set to 'false', polling would be controlled by the value of cacheTime. The reason of adding this property is to allow notification being used by other components while using polling for SM.

Earlier, an effort for enabling and disabling caches of different components, Identity Repository (IdRepo), User Management (UM) and SM, independently was done in AM7.0patch2 and AM7.1 RTM. This provides flexibility for customers to decide which caches to turn on and which to turn off, based on their deployment needs. New property 'sm.cache.enabled' was brought in to enable (true) or disable (false) only the SM cache. The effectiveness of this property is subjected to the value of 'sdk.caching.enabled', which is the global property that enables (true) or disables (false) the IdRepo, UM, and SM caches. If true, or if the property is not set, all three caches are enabled.

The latest improvement on this was done on OpenSSO8.0. There are two new properties were available to control the expiration of SM cache. If the property 'sm.cache.ttl.enable' is set to true, the cache entries will expire based on the time specified in the property "sm.cache.ttl" (in minutes).

Ideally, I think everyone would agree SM cache should be enabled and notification turned on. Again, your client has to running on a web container in order to provide notification URL to the server. But the notification URL is registered at run time and kept in memory of AM server. A server start causes the loss of the URL, then client can not receive any more notifications. Unless you restart your client or re-initiate SM cache by other ways. If getting the SM change immediately from the server is not so important, generally I recommend to set sm.cache.ttl.enable=true and sm.cache.ttl to an appropriate value. The default is 30 minutes.

All the property names mentioned above should prefixed with 'com.sun.identity' or 'com.iplanet.am'. So the complete set of properties are:
com.sun.identity.client.notification.url
com.sun.identity.sm.cacheTime
com.sun.identity.sm.notification.enabled
com.iplanet.am.sdk.caching.enabled
com.sun.identity.sm.cache.enabled
com.sun.identity.sm.cache.ttl.enable
com.sun.identity.sm.cache.ttl

Comments:

Post a Comment:
Comments are closed for this entry.
About

gc

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today