000011646 - When one aserver is unreachable for cache flush the eserver retries all aservers.

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000011646
Applies ToRSA Access Manger 6.1
IssueWhen 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, timeout=15000
ResolutionThis 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.
NotesNote 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.
Legacy Article IDa56827