It seems that the persistent search is not restarted when the LDAP connection pool is lost (or there is a network outage). This issue is notthing to do with heartbeat but rather than with the new use of the OpenDJ to async use, it did not cater to connection lost.
1. Create a new realm
2. Create a datastore to a one LB (pointing to a DJ separate from any other DJ)
3. The LB --> DJ and so access authentication to warm that up
4. Destroy LB and restart LB.
5. [LB connection not reestablished even after a long time]
6. Activity on DJ not triggering anything
Current observation on 13.5.x (wrong)
- LDAP persistent connection not re-established (as seen from LB)
- External change in LDAP entry not notified to OpenAM
Expected (if fixed)
- Connection reestablished w/o touching anything.
- And also doing a directory entry change will trigger a persistent search.
When did this used to work
The same testcase will work fine in 11.0. when the LDAP connection to the LDAP will restart to connect once the network/LB reestablishes.
Configuration change and also user profile change that rely on persistent change may be lost or not notified when the Directory/Network outages happens between OpenAM and OpenDJ and causes cache to still use old values (unless an cache expiry is set). [Workaround: disable OpenAM cache or set a cache entry timeout]
On check the work in
AME-12815 (change LDAPv3PersistentSearch to use the conn.startAsync().thenOnResultOrException() to handle the connection lost and then restartSearch()) should solve this. The behaviour change in OpenDJ 3.x SDK seems to be removal of the handleErrorResult() from the psearchresult event handler from OpenDJ SDK 2.x )