Conversation
… an index-entry-limit of 0
An index-entry-limit of 0 is no limit at all ("For no limit, use 0 for the
value"), and the live index honours it: DefaultIndex.computeEntryIDSet gives a
key up only while the limit is above 0. The two collectors of the on-disk merge
importer compared the value as a count instead - 0 < 0 never accepted an entry
ID and 0 >= 0 always answered the undefined set - so every key an import-ldif
or a rebuild-index wrote under that setting was undefined, in an index the
import then marked trusted. Every search through such an index was unindexed,
and refused to a client without the unindexed-search privilege. The importer
this one replaced (OPENDJ-2016) mapped 0 to Integer.MAX_VALUE; the collectors
now do the same.
backendstat show-index-status read the value the same way and counted every
key of such an index as over 95% of its limit; an index with no limit has no
key near it.
Indexes imported or rebuilt under index-entry-limit: 0 before this change hold
every key undefined and have to be rebuilt once.
Part of OpenIdentityPlatform#1059: whether a changed limit needs a rebuild is decided by the same
comparison in DefaultIndex.setIndexEntryLimit, which OpenIdentityPlatform#997 moves to
AttributeIndex.planIndexUpdates; that part follows once OpenIdentityPlatform#997 is merged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An
index-entry-limitof 0 is no limit at all ("For no limit, use 0 for the value"), and the live index honours it:DefaultIndex.computeEntryIDSetgives a key up only while the limit is above 0. The two collectors of the on-disk merge importer compared the value as a count instead —0 < 0never accepted an entry ID and0 >= 0always answered the undefined set — so every key animport-ldifor arebuild-indexwrote under that setting was undefined, in an index the import then marked trusted. Every search through such an index was unindexed, and refused to a client without theunindexed-searchprivilege; set on the backend, the value is inherited by every index, so one import puts the whole backend out of indexed use.This is a regression of the importer rewrite (OPENDJ-2016, 2015): the importer it replaced mapped 0 to
Integer.MAX_VALUE(ImportIDSet,IndexKey). The collectors now do the same, through one helper; their comparisons are left as they are.backendstat show-index-statusread the value the same way and counted every key of such an index as over 95% of its limit; an index with no limit has no key near it.Tests
OnDiskMergeImporterTest: under a limit of 0 both collectors keep a key of ten entries defined and leave a key a chunk had already given up undefined; the phase-one collector, which had no test, is pinned at its limit as well.PluggableBackendImplTestCase(PDB, JE, both encrypted): an import and a rebuild underindex-entry-limit: 0leave every key of everysnindex defined. Both are red with the importer of master, which writes every one of them undefined.BackendStatTest: no key is near a limit of 0.Not in this PR
Whether a changed limit needs a rebuild (
DefaultIndex.setIndexEntryLimit, the first point of #1059) is decided by the same kind of comparison; #997 moves it toAttributeIndex.planIndexUpdates, so that part follows once #997 is merged. The order matters: today's wrong "0 → 4000 needs a rebuild" is what repaired an index an import had written all-undefined, so the importer is fixed first.Indexes imported or rebuilt under
index-entry-limit: 0before this change hold every key undefined and have to be rebuilt once.Part of #1059.