[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Denying access to syncrepl consumere during initial DIT content load



Hi,

On Mon, 24 Mar 2014, Michael StrÃder wrote:

Howard Chu wrote:
Christian Kratzer wrote:

I remember a discussion some time ago about the possibility of delaying
access to a syncrepl. consumer during the intial DIT load.

http://www.openldap.org/lists/openldap-bugs/201308/msg00043.html

Feel free to experiment with it and see whether it suits your need.

Why was this undocumented strictrefresh option limited to delta-syncrepl?

ok Thanks for the pointer.

Thats why it is not working in my setup as this old horse still does regular syncrepl....

I see following in servers/slapd/syncrepl.c

1013  if (si->si_strict_refresh) {
1014     slap_suspend_listeners();
1015     connections_drop();
1016  }

and folloing turns listeners on later on:

1174  if ( err == LDAP_SUCCESS
1175      && si->si_logstate == SYNCLOG_FALLBACK ) {
1176      si->si_logstate = SYNCLOG_LOGGING;
1177      rc = LDAP_SYNC_REFRESH_REQUIRED;
1178      slap_resume_listeners();
1179  } else {
1180      rc = -2;
1181  }

The logic seems to be that once we are synced up with one of the providers we should be set as the other providers should have identical data.

I can also see the next caveat that resetting all connections is possibly triggered each time a syncrepl connection is setup to a provider.  Perhaps even when dumping connections on a consumer when a provider is restarted and the consumer reconnects.

I would really like such a feature for consistency but this seems to need more deep thinking.

Greetings
Christian

--
Christian Kratzer                   CK Software GmbH
Email:   ck@cksoft.de               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/