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.
-
hyc＠symas.com