Michael Ströder wrote: > [email protected] wrote: >> Michael Ströder wrote: >>> [email protected] wrote: >>>> Michael Ströder wrote: >>>>> [email protected] wrote: >>>>>> Generating a new contextCSN at startup is of questionable worth. We >>>>>> discussed >>>>>> this a bit 'way back in 2004 >>>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html >>>>>> Perhaps we >>>>>> should just not do it; >>>>> >>>>> +1 >>>>> >>>>>> if a single-master provider starts up empty and a >>>>>> consumer tries to talk to it and both have an empty cookie, the provider >>>>>> should just respond "you're up to date". >>>>> >>>>> Why not return an error to the consumer? >>>> >>>> Typically if a consumer receives an error it will disconnect and retry >>>> later. >>>> There's not much point making the consumer reconnect - which may be costly >>>> for >>>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang >>>> on >>>> and wait for some real data to arrive. >>> >>> Is the cost really that high compared to the rest of the initialization? >> >> I meant "TLS" there. > > As I'm solely using TLS secured LDAP connection *everywhere* I also implied > TLS. Still I assume opening the syncrepl connection a few times again is > nothing compared to the majority LDAP clients opening connections for every > single LDAP simple bind request. So if it simplifies error handling which > likely results in more robustness, I'd strongly prefer that.
As it turns out, it greatly simplified things to handle this condition as you suggest. Fixed now in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
