> >>> > >>> 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. So, lets open a ticket to remove delayed processing mode then? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
