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

[hyc@symas.com]

Michael Ströder wrote:
> 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.

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/