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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
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
|
