hyc@symas.com wrote:
Howard Chu wrote:
hyc@symas.com wrote:
jclarke@linagora.com wrote:
I saw the comment in the code that clarifies this behaviour. However, it's a surprising behaviour, and I think there is code to parse this kind of thing in the serverID detection now. Maybe it could be reused?
Oops, never mind. I was thinking of the serverID code, and you're talking about the syncrepl code.
I'll have to think a bit about why the two aren't behaving identically; probably they should both use the same code.
Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such.
For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...).
Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results.
Jon