[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. Ciao, Michael.
