On 07/07/2017 07:10 AM, William Brown wrote:
>>>> 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.
>> We already have this issue because there is a delay between the change
>> to the object and the log being sync() to disk. So we can already lose
>> changes here. TBH the only fix is ot remove the async model. I actually
>> question why we still need async/delay processing of the refint
>> plugin ...
> Historically speaking, a long time ago, we used to see high CPU when the
> RI plugin was engaged. Setting the delay to 1 second, and allowing the
> log thread to do the work, improved performance. Of course this is now
> obsolete with the betxn plugin model and other improvements, but I
> wanted to share why the feature even existed.
I guess that would be related to internal op searches / lack of
indexing. These days it's not as big of an issue.
boldly said. How do you know,
did you verify it ?
we have seen many customer issues with refereint which were resolved by
making it async, just removing this option without proof of a better
solution is no good.
I also am not sure if we need to tie anything into the betxn. There are
operations, which, in my opinion, can be delayed, even redone by fixup
tasks, so it is not necessary to have it in one txn, and if the option
is there to delay it if you want, we should not take it away
So, lets open a ticket to remove delayed processing mode then?
you can, but I will
oppose to implement it :-)
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
--
Red Hat GmbH,
http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander