On 07/07/2017 03:17 PM, Mark Reynolds wrote:
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.
well, the latest
issue I remember was on RHEL6.x with 1.2.10/11, but if
we didn't hear it could als very well mean that it is used by
recommendation of support.
That is why I asked if it is confirmed that there is no more problem, as
far as I know we did only change configuration, nothing in the plugin
itself.
Why do we want to fix soemthing which is not broken ? The delay option
is there forever, some deployments are using it, otehrs use the default.
And I would als say any effort to optimize it by using a queue is not
justified, nobody complained about peformance in delay mode.
I would also not move it away from betxn, if someone uses the delay
option, the update is outside the txn, that is a deliberate decision.
But for all the deployments using the default delay=0 it has to stay
where it is.
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(a)lists.fedoraproject.org
>> To unsubscribe send an email to389-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
>
>
> _______________________________________________
> 389-devel mailing list --389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to389-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