[#1067] Ask the memory quota whether an explicit db-cache-size fits instead of taking it

[vharseko]

Fixes #1067

What

ConfigurableEnvironment.validateDbCacheSize checked an explicit db-cache-size against the server's memory quota with acquireMemory - a reservation - and nothing gave it back. JEStorage.buildConfiguration reserves the same size again four lines later, on purpose, and close() releases only that one, so every open of a JE backend with an explicit size (each enable, each import-ldif or rebuild-index of a disabled backend; twice for an import with include/exclude branches, which opens the storage once more to migrate them) drained one cache size from what the server believed it had left.

The check is now the probe it was meant to be - isMemoryAvailable takes and gives back in one call - and the warning it logs names what the quota has left (getAvailableMemory()), as its text says ("the JVM has only %d available") and as the same warning from isConfigurationAcceptable does, rather than the size of the old generation (getMaxMemory()).

The reservation dates from OPENDJ-1727 (2015-03), which added it for the local-db backend that had no reservation of its own; OPENDJ-1719 (2015-09) kept it while giving JEStorage one. Wren:DS carries the same reservation.

Dropping the check altogether was the other option in the issue; it is kept because at startup the open of a backend is not checked against the quota beforehand, and a refused reservation in buildConfiguration is silent - the warning is the only word the operator gets that an explicit size did not fit.

Test

ConfigurableEnvironmentTest pins parseConfigEntry against the server's own quota - the one the check reaches through DirectoryServer, which the mock quota JEStorageTest/PDBStorageTest watch does not see, which is why none of them caught this:

• anExplicitCacheSizeTakesNothingFromTheQuota - RED before the fix: 192 MB → 128 MB after one parse;
• aCachePercentTakesNothingFromTheQuota - the percent road never went through the check;
• aCacheSizeTheQuotaCannotGrantIsWarnedAboutWithWhatIsLeft - the quota filled to half a cache size, the warning is logged with what is left and nothing is taken - RED before the fix: the warning said "the JVM has only 536870912 available" (the old generation) while the quota had 32 MB.

Regression, one JVM per class, all green: JETestCase 35, EncryptedJETestCase 35, ID2ChildrenCountTest 4, DN2IDTest 7, StateTest 8, OnDiskMergeImporterTest 29, ReplayedConfigChangeTest 12, ControlsTestCase 82, PDBStorageTest 10.

Related

• A live change of db-cache-size drifts the memory quota: the storage reserves the old size at open and releases the new one at close #1063 / [#1063] Give back what the open reserved rather than what the configuration says by then, and ask for a restart when the cache size changes #1066 - the storage's own reservation, released as it was taken; this reservation sits outside that pair.
• Not in this PR: a reservation buildConfiguration is refused (explicit size or percent, JE and PDB alike) is still silent there - the warning above is the only one, and only for an explicit size on JE.

[maximthomas]

praise: the leak is closed where it starts, and the test watches the quota the check actually reaches.

• parseConfigEntry has one production caller, JEStorage.buildConfiguration:760, which reserves the size itself at :767 — the reservation in validateDbCacheSize could only leak, and isMemoryAvailable (MemoryQuota:80-91, acquire + release) is the right replacement.
• The warning now passes getAvailableMemory(), which is what its text ("the JVM has only %d available") says.
• ConfigurableEnvironmentTest reads the server's own quota through DirectoryServer, which the mock quota in JEStorageTest/PDBStorageTest never sees; green on every Linux cell of run 35307742961.