Issue 6022 - lmdb inconsistency between vlv index and vlv cache names #6026
Conversation
progier389
added
lmdb
|
Got a nasty surprise: Also the test is passing as a single test but test fails when all the vlv tests are run. |
progier389
removed
the
work in progress
|
I discovered that the vlv inconstancy I described in previews comments also exists with bdb so it is not related to the current issue. Created issue #6028 to track it. Restart works around that issue. |
| entry.delete() | ||
| repl.wait_for_replication(M1, M2) | ||
| # Restart the instance to workaround github issue #6028 | ||
| M2.restart() |
There was a problem hiding this comment.
If I understood correctly, the workaround is required only for BDB. Should we restart only for BDB tests, then? (by adding some if here or something)
Also, kind of nitpick, I think it'll be useful to have a full link here (https://github.com/389ds/389-ds-base/issues/6028) in case we'll change the bug tracker somewhere in the future.
There was a problem hiding this comment.
The new testcase is still failing, and I realized that I made a mistake when creating issue 6028
(used wrong test case in the reproducer)
Redoing the test I noticed that the inconsistency occurs only in mdb and the hang only in bdb
So I fixed 6028 description for mdb inconsistency and created #6029 for the bdb hang.
I changed the code to do as you suggested.
use full link to #6029 and restart M2 only in bdb case
Note the new test case is still failing with mdb but fixing 6028 should solve it.
Problem: dbstat -L shows two vlv cache db for a single vlv index db.
There should only have a single one.
Fix:
Added a CI Test
Using a single dbmdb_recno_cache_get_dbname function to get the cache db name.
Fix dbmdb_build_dbname to also append the backend name if the name is a vlv cache
Also fixed some issue found while creating the CI test:
Fixed an error message that puzzled me to make it clearer.
Fixed a race condition in lmdb bulk import that logged crappy data in error logs and crashed the CI tests.
Issue: #6022
Reviewed by: @droideck (Thanks !)