When trimming the retroCL, it deletes an entry. Then retrieve the entry from the cache (no creation of tombstone) to remove it from the cache. Apparently if the entry cachen is small, it can fail to retrieve it and not testing this special condition
Fixed upstream
Verification steps: [1] Enable retro changelog plugin and set the retro changelog max age: ldapmodify .... dn: cn=retro changelog plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on - replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 30 [2] Restart the server [3] Set a very small entry cache size for the retro changelog backend ldapmodify dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 512000 [4] Restart the server [5] Add 2000 entries [6] Wait 31 seconds [7] Make sure server is still running(or did not crash during the adds)
Built tested: 389-ds-base-1.2.11.15-74.el6.x86_64 [1] Enable retro changelog plugin and set the retro changelog max age: ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p 389 -x dn: cn=retro changelog plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on - replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 30 [2] Restart the server sudo restart-dirsrv [3] Set a very small entry cache size for the retro changelog backend ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p 389 -x dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 512000 [4] Restart the server sudo restart-dirsrv [5] Add 2000 entries ldclt -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -f cn=MrXXXX -b "dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r1 -R2000 [6] Wait 31 seconds [7] Make sure server is still running(or did not crash during the adds) ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 389 -x -b "dc=example,dc=com" cn=Mr2000 # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: cn=Mr2000 # requesting: ALL # # Mr2000, example.com dn: cn=Mr2000,dc=example,dc=com objectClass: person objectClass: top cn: Mr2000 sn: toto sn # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Marking as verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0737.html