On 09/26/2016 11:13 AM, thierry bordaz wrote:
On 09/23/2016 11:31 AM, Ludwig Krispenz wrote:
> Hi Thierry,
> the description in the commit is now fine, but given that the choice
> of LDAP_CONSTRAINT_VIOLATION is a bit arbitrary it would be good to
> have a comment where it is set, explaining why this error code was used.
> About which error code to choose, if you have to pick one of the
> errors which will allow "keep_going" it is fine, although I think the
> original choice of unwilling to perform was a better match,
> operations_error or ldap_other would, in my opinion, also be good
> candidates - but they are in the wrong category.
Thanks Ludwig. You are right, it is missing the comment in the code.
I added the commend and also fixed an incorrect url in the bug
> Looking at ignore_error_and_keep_going, I am wondering if this
> partition in go|stop is really still correct ? maybe we should
> investigate this as well.
ignore_error_and_keep_going is used on both consumer and supplier
sides. On both sides it lets the replication session continuing on
"transient" error. I wonder if there is not something wrong. I think
it is fine to continue replication on minor (syntax, duplicate values,
...) failures but the failed update is silently skipped. Just an error
is logged on the supplier side, with a invalid statement: "Will retry
later" that is false the update will be simply skipped.
Do you think we could create a conflict entry with the op parameters
that were skipped ?
I am not sure, I just noticed when looking at
ignore_error_and_keep_going() that there might be situations where
behaviour should be double checked.
maybe you should open an other ticket to investigate this
> On 09/23/2016 10:08 AM, thierry bordaz wrote:
>> Thanks Noriko for your review. I updated the patch to give more
>> explanation why the fix is in modify_schema_dse.
>> I pick up LDAP_CONSTRAINT_VIOLATION in replacement of
>> UNWILLING_TO_PERFORM but I have not strong opinion on appropriate
>> value of that returned value. In the logic of that fix, it just
>> needs to be not fatal regarding ignore_error_and_keep_going.
>> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
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