When one aserver is unreachable for cache flush the eserver retries all aservers.
3 years ago
Originally Published: 2011-12-14
Article Number
000040123
Applies To
RSA Access Manger 6.1
Issue
When one aserver is unreachable for cache flush the eserver retries all aservers.
Cache flush delay causes delays in cache flush events for password changes.
When there is a change on the eserver (for example a change to a user object) the eserver will send out a cache poison event to each aserver that is returned on the dispatchers list of asevers.  If any aserver is unreachable the eserver will try cleartrust.eserver.runtime.retry_count times (default=3) to re-send this cache poison event. It will wait cleartrust.eserver.runtime.timeout (default 0) between each attempt. The the eserver will attempt to send the cache poison event to all aservers in the connection pool not just the one that failed. If there are a large number of aservers, this is undesirable.

The aserver that is unreachable may be identified by examination of the eserver standard output in debug mode.   The debug output will log the following message for each retry attempt against an aserver that is not reachable:
2012/07/25 04:44:55:748 [*] [QueueDispatcher (sirrus.util.net.SocketFactory.debugCreateSocket)] - Connecting to 192.168.10.1:5615, timeout=15000

Resolution
This issue has been resolved in Access Manager 6.1 SP4   Contact RSA Customer Support and request this service pack or the most recent service pack for 6.1.   In 6.1.4 the eserver will only retry the specific aserver that is unreachable.
Notes
Note that this problem occurs only if the aserver is marked as up in the dispatcher list but is not responding.   Ensure that the eserver can contact all of the aservers in the dispatcher list and that aserver listen port (5615 by default) is open between the eserver and aserver.
Don't see what you're looking for?