On 22/05/2021 22:44, Stefan Seelmann wrote:
Hi Alexander,
On 5/22/21 6:32 PM, Alexander Zaretsky wrote:
Hello : I am experiencing corruption using Apache Directory Server 2.0.0
M26 on windows server 2016.
Unfortunately that's a known issue, please read our statement about the
production readiness [1].
I am trying to repair the JDBM backend :
I modified the file
c:\Program Files
(x86)\ApacheDS\instances\default\conf\wrapper-instance.conf adding the
following line at the end of the file wrapper.app.parameter.1=repair
and restarting.
I realize this is not a definite solution, so I want to use mavibot as a
backend for my Apache DS instead of JDBM
I want to know how to make my apache DS work with mavibot instead of jdbm.
The easiest way is to use Studio to create a Mavibot partition, see [2].
Once stored you can find the configuration in the config partition below
ou=partitions,ads-directoryServiceId=default,ou=config
However I can't tell you if the current version of Mavibot is stable
enough or might cause similar or differnt problems.
It's stable, but it has some issues: The 0.9 version, which is used atm,
does not support cross-btree transactions. The consequence being that it
may happen that if a crash occurs in the middle of an update, some btree
might not be updated. Although the master table will always be clean.
The coming version - 1.0 - will support cross-btree transaction, which
brings two major advantages:
- first a guaranteed correct database even if a crash occurdd in the
middle of a modification: in this case, no btree will be updated at all,
otherwise all the btrees willm be updated.
- second you will benefit from the fact that the transaction is
'public'. Ie, you can drive it through LDAP transaction. This is very
interesting when it comes to inject many modifications in one shot, as
we will not write down on disk the intermediate results, but only the
last version when the transaction is closed; that leads to a real
speedup on modify operations. Typically, one can expect to inject
entries at least one order of magnitude faster than when committing a
transaction after each modification
1.0 does not have a dead revision cleanup though. That means the
database will only grow with the time. The algorithm is well known, buut
it's not yet implemented. Actually, there are 2 pôssible algorithms:
- one which remove every 'dead' revisions as soon as the oldest revision
is not anymore in use, up to the next used revision (this is what is
implemented in LMDB FTR)
- one which can claim dead revisions (or at least dead pages) when a
revision is released (but this is a much more complex algorithm).
The fact that we don't have a way to cleanup the database from dead page
is not necessary a big issue for two reasons:
- first we don't have necessarily a lot of modifications in LDAP, so the
database would eventually grow slowly
- second we could 'compact' the database when stopping and restarting
the server: we would only keep the latest revision, and that would be a
very fast operation.
In any case, yes, 1.0 is not out yet.
The good news is that now I'm done with the junit 5 migration I can
switch to mavibot. The less good news is that I have still quite little
time (but it's getting better).
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@directory.apache.org
For additional commands, e-mail: users-h...@directory.apache.org
