On 07/07/2017 04:44 AM, Ludwig Krispenz wrote: > > 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 ? Sorry I didn't realize there was still an issue here. Back in NDS 3.12 (maybe early 4.0) this was a very common problem (I personally handled countless cases on it), but I have not seen it reported since then. If it's still useful, then we should definitely keep it, and moving to a queue is fine with me if it really adds value. I really thought the log/delay was obsolete and no one used it anymore. It still breaks the be txn model, so moving it back to a plain postop plugin is the right move if we continue to use the delay. In that case, should we make the delay the default? If it's a still a common problem as you said, then lets just apply the "fix/delay" out of the box. > 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@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@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 > > > _______________________________________________ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
