On 07/06/2017 01:07 PM, Ilias Stamatis
wrote:
Hello,
It finally turns out that
this file is used for other purposes than real
logging.
The referint plugin currently works like that;
When the delay update is set to be more than 0 a
new thread is created executing referential
integrity code every x seconds (set by delay
update). When
a delete or modrdn operation happens, the plugin
will write that down to its logfile. So, every x
seconds the plugin will check the logfile, see
what happened and apply the changes. Finally, it
deletes the file, thus clearing the state for
the next time it reads from it.
After discussing this with
William he suggested it's better to replace the
file with a queue, since the file
involves excess fsync / sync, and has all kinds
of potential state/race issues. Using a queue
will be much faster as well.
William went even further
and suggested that we
could get rid of the async referint update
completely. This probably wouldn't happen soon
though, since likely customers are using it. For
now we could provide a warning such as "we
recommend you set delay to 0".
Finally, the referint-logchanges
attribute does absolutely nothing. It seems to
be completely ignored by the plugin, so we could
remove this as well.
I'll
start working on these changes soon.
Any thoughts or objections on the above would be welcome.
The only problem with going to a queue is if the server goes down
unexpectedly. In such a case those RI updates would be lost.
This also brings up a different point... the RI plugin is a backend
txn plugin. If we write changes to a log, and those changes end up
failing for some reason, then there is no way to rollback the
original transaction --> breaking the backend txn plugin model.
Perhaps the log/delay should just be removed? Or ignore the
log/delay settings if the plugin is set as a backend txn plugin?
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
|
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
