Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream

[michael@stroeder.com]

hyc@symas.com wrote:
> Michael Ströder wrote:
>> hyc@symas.com wrote:
>>> Michael Ströder wrote:
>>>> hyc@symas.com 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.