Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc We've discussed this on -devel a few times in the past. Sometimes it would be desirable to prevent a consumer from answering client requests if it has just started up and needs to perform an lengthy refresh. In prior discussions, there was a concern that in an MMR situation, two servers coming up at the same time would deadlock waiting for each other. We can avoid this problem by allowing any search request with a Sync control to proceed as normal. Or, any search request with a Sync control and a non-empty, valid cookie. Implementation can be done using an overlay hook. Note that syncrepl already installs an overlay hook now for delta-mmr, this would just expand the scope of that internal overlay.
hyc@OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.35 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.155.233.73) > Submitted by: hyc > > > We've discussed this on -devel a few times in the past. Sometimes it would be > desirable to prevent a consumer from answering client requests if it has just > started up and needs to perform an lengthy refresh. > > In prior discussions, there was a concern that in an MMR situation, two servers > coming up at the same time would deadlock waiting for each other. We can avoid > this problem by allowing any search request with a Sync control to proceed as > normal. Or, any search request with a Sync control and a non-empty, valid > cookie. > > Implementation can be done using an overlay hook. Note that syncrepl already > installs an overlay hook now for delta-mmr, this would just expand the scope of > that internal overlay. I was considering returning LDAP_BUSY for this case, but it may make more sense to return a REFERRAL to the provider instead. (Although again, if we have two MMR servers pointed at each other starting at the same time, they would just refer to each other and clients would get nowhere until one of them finishes its refresh.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > I was considering returning LDAP_BUSY for this case, but it may make more > sense to return a REFERRAL to the provider instead. (Although again, if we > have two MMR servers pointed at each other starting at the same time, they > would just refer to each other and clients would get nowhere until one of them > finishes its refresh.) IMO referrals are harmful. Just returning LDAP_BUSY seems best to me because if reliable HA is really important for a deployment you have decent load-balancers in front of your LDAP server which should do a proper health-check. Just a question: Is this database-specific? Maybe only one of several DBs is in this initial syncrepl phase and access to others should simply work. Ciao, Michael.
Michael Ströder wrote: > hyc@symas.com wrote: >> I was considering returning LDAP_BUSY for this case, but it may make more >> sense to return a REFERRAL to the provider instead. (Although again, if we >> have two MMR servers pointed at each other starting at the same time, they >> would just refer to each other and clients would get nowhere until one of them >> finishes its refresh.) > > IMO referrals are harmful. > Just returning LDAP_BUSY seems best to me because if reliable HA is really > important for a deployment you have decent load-balancers in front of your > LDAP server which should do a proper health-check. Agreed. > Just a question: Is this database-specific? Maybe only one of several DBs is > in this initial syncrepl phase and access to others should simply work. Overlays are db-specific. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > Michael Ströder wrote: >> hyc@symas.com wrote: >>> I was considering returning LDAP_BUSY for this case, but it may make more >>> sense to return a REFERRAL to the provider instead. (Although again, if we >>> have two MMR servers pointed at each other starting at the same time, they >>> would just refer to each other and clients would get nowhere until one of them >>> finishes its refresh.) >> >> IMO referrals are harmful. >> Just returning LDAP_BUSY seems best to me because if reliable HA is really >> important for a deployment you have decent load-balancers in front of your >> LDAP server which should do a proper health-check. > > Agreed. > >> Just a question: Is this database-specific? Maybe only one of several DBs is >> in this initial syncrepl phase and access to others should simply work. > > Overlays are db-specific. > A similar feature was already implemented, and never documented: commit 9e00b6cc6ce2857490b33218bdaf1339319c5f60 Author: Howard Chu <hyc@openldap.org> Date: Fri Apr 15 11:13:38 2011 -0700 Add strictrefresh syncrepl option Only affects delta-syncrepl - stop listening to clients while refresh is running. This is a bit more extreme though, it terminates all client connections and suspends the slapd listeners while a refresh is running. The solution discussed in this ITS would be preferable. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > Michael Ströder wrote: >> hyc@symas.com wrote: >>> I was considering returning LDAP_BUSY for this case, but it may make more >>> sense to return a REFERRAL to the provider instead. (Although again, if we >>> have two MMR servers pointed at each other starting at the same time, they >>> would just refer to each other and clients would get nowhere until one of them >>> finishes its refresh.) >> >> IMO referrals are harmful. >> Just returning LDAP_BUSY seems best to me because if reliable HA is really >> important for a deployment you have decent load-balancers in front of your >> LDAP server which should do a proper health-check. The attached patch should provide the desired behavior. It needs more testing though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Enhancements
changed notes
in master/RE25 reverted - not viable
changed notes changed state Test to Suspended