Issue 8268 - slapd-ldap quarantine, per configuration retries fail
Summary: slapd-ldap quarantine, per configuration retries fail
Status: VERIFIED DUPLICATE of issue 8721
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: backends (show other issues)
Version: 2.4.42
Hardware: All All
: --- normal
Target Milestone: 2.6.0
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-11 17:42 UTC by nvoutsin@gmail.com
Modified: 2021-06-23 15:36 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description nvoutsin@gmail.com 2015-10-11 17:42:42 UTC
Full_Name: Nikos Voutsinas
Version: 2.4.42
OS: Solaris/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (62.38.193.214)


Hi,

In a 4-nodes MMR deployment with a 2-nodes LDAP Proxy Front-ends, we have
repeatedly noticed that whenever the connection recovery method falls into the
quarantine code, it fails.

i.e. when all the back-end ldap servers become unavailable, for some reason,
slapd-ldap fails to follow the retry scheme that is dictated by
olcDbQuarantine.

In our case we set olcDbQuarantine to: 10,30;60,+ and when we got a temporary
network timeout from all back-end ldap server this is what we saw in the slapd
logs.

Oct  7 21:30:58 proxy slapd[330]: conn=632725 op=0 ldap_back_retry: retrying
URI="ldap://back01 ldap://back02" DN=""
Oct  7 21:30:58 proxy slapd[330]: conn=632725 op=0: ldap_back_quarantine enter.
Oct  7 21:31:08 proxy slapd[330]: conn=632759 op=0: ldap_back_getconn quarantine
retry block #0 try #0.


After that the only method to recover was either to restart the whole process or
reset the value of olcDbQuarantine.

Thanks,
Nikos
Comment 1 Quanah Gibson-Mount 2021-03-01 17:39:09 UTC
Would be useful to have a test case
Comment 2 Quanah Gibson-Mount 2021-06-23 15:36:52 UTC

*** This issue has been marked as a duplicate of issue 8721 ***