[OPENDJ-5070] Over allocation of db-cache-percent for existing backend results in empty error Created: 10/May/18  Updated: 08/Nov/19  Resolved: 05/Nov/18

Status: Done
Project: OpenDJ
Component/s: backends, logging
Affects Version/s: 5.5.0, 3.5.0
Fix Version/s: Not applicable

Type: Bug Priority: Minor
Reporter: John Noble Assignee: Matthew Swift
Resolution: Duplicate Votes: 0
Labels: release-notes

Issue Links:
Duplicate
duplicates OPENDJ-5584 Server does not validate sum of memor... Done
Story Points: 0
Dev Assignee: Matthew Swift
Support Ticket IDs:

 Description   

Steps to reproduce:

 

1. Create a second backend to bring total db-cache-percent to 100%

2. Increase db-cache-percent for any backend to bring the total to >100%, i.e.

 

./dsconfig set-backend-prop --port 4444 -D "cn=Directory Manager" --bindPassword password --backend-name backend2 --set db-cache-percent:30 --trustAll --no-prompt

The JE Backend could not be modified because of the following reason:

* Unwilling to Perform: Entry
 ds-cfg-backend-id=backend3,cn=Backends,cn=config cannot be modified
 because one of the configuration change listeners registered for that
 entry rejected the change:

 

If a new backend is created with an over-allocated  db-cache-percent, you get a nice descriptive error, i.e.

The JE Backend could not be created because of the following reason:

* Unwilling to Perform: The Directory Server is unwilling to add
 configuration entry ds-cfg-backend-id=backend3,cn=Backends,cn=config
 because one of the add listeners registered with the parent entry
 cn=Backends,cn=config rejected this change with the message:
 Configuration attribute ds-cfg-db-cache-percent has a value of 50% but
 the JVM has only 10% available

 

Expectation:

Over-allocating the  db-cache-percent for existing backends should give a descriptive error similar to when a new backend is created



 Comments   
Comment by Matthew Swift [ 07/Nov/19 ]

Moved to closed state because the fixVersion has already been released.

Generated at Sat Oct 31 00:37:00 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.