000025990 - ClearTrust eserver configuration for replicated datastores in RSA Access Manager

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Jun 16, 2017
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000025990
Applies ToRSA Product Set: ClearTrust Entitlements Server 5.5.3 through 6.2
IssueClearTrust eserver configuration for replicated datastores
Changes made to entitlements or password status are not reflected correctly in the aserver.
Example of logs seen in aserver
sirrus.da.exception.DataStoreException: Invalid Arguments. ID / Qualified Name must be set in SQLEntry
at sirrus.da.sql.util.SQLFilterHelper.createUniqueKeyFilter(SQLFilterHelper.java:176)
at sirrus.da.sql.util.SQLAdminHelper.getAdminGroup(SQLAdminHelper.java:1108)
at sirrus.da.sql.util.SQLConnectionImpl.get(SQLConnectionImpl.java:402)
at sirrus.da.sql.auth.factory.SQLAdministrativeGroupFactory.getDefaultAdministrativeGroup(SQLAdministrativeGroupFactory.java:108)
at sirrus.da.auth.cache.factory.UserToAdministrativeGroupCache.loadAddedKey(CachingAdministrativeGroupFactory.java:297)
at sirrus.util.data.cache.LRUCache.handleDataUpdateEvent(LRUCache.java:547)
at sirrus.util.data.DataUpdateEventDispatcher.listenersHandleEvent(DataUpdateEventDispatcher.java:287)
at sirrus.util.data.DataUpdateEventDispatcher.run(DataUpdateEventDispatcher.java:241)
CauseWhen records in the ClearTrust/Access Manager datastore are modified by the Entitlements Manager or through the Admin API they cause the aserver cache records to be poisoned.  This causes the aservers to fetch updated records from the datastore. In instances where the eserver is writing to a different replicated datastore from the aserver, replication delays can cause the aservers to retrieve stale data. 

Set the following line in your eserver.conf file.


This should be set to the typical replication delay between the datastore used by the entitlements server and the authentication servers. A value of 3 (seconds) should be good, but it depends on your replication topology and load.

This value sets the time the eserver waits before telling the aservers to force a refresh of a changed item in the aserver cache.

NotesFor Active Directory datastores you can confirm the actual latency by running the "repadmin /latency" command.
Legacy Article IDa32280