Hi, while taking up some loose ends on my work on delete support for back- config (enabled with -DSLAP_CONFIG_DELETE) I wondered how we should deal with the deletion of the syncprov overlay when there are active refreshAndPersist sessions. What errorcode should we sent when closing such a connection? To me LDAP_UNAVAILABLE sound like the best choice. LDAP_UNWILLING_TO_PERFORM might also be ok.

Am Freitag 26 Februar 2010 13:30:55 schrieb masarati(a)aero.polimi.it: >> Hi, >> >> while taking up some loose ends on my work on delete support for >> back- config (enabled with -DSLAP_CONFIG_DELETE) I wondered how we >> should deal with the deletion of the syncprov overlay when there >> are active refreshAndPersist sessions. What errorcode should we >> sent when closing such a connection? To me LDAP_UNAVAILABLE sound >> like the best choice. LDAP_UNWILLING_TO_PERFORM might also be ok. > > What about an unsolicited notification (RFC 4511, 4.4)? Hm, yes. A "Notice of Disconneciton" might work as well. But that would result in the client connection been taken down, which is probably not desired. For syncrepl connections from slapd-consumers this might be ok. But other LDAPSync clients might have other operations active on the same connection which wouldn't be affected by the removal of the syncprov overlay, I guess. Returning an error just for the LDAPSync related Search seemed more logical to me.

> Also on the topic of deletes, we should start adding term_module() > handlers to the backends and overlays. Yes. I havn't gone into the details of module unloading yet, though. An additional bi_db_delete handler in the BackendInfo structure might be helpful as well. Or a flag passed to bi_db_close/bi_db_destory to indicate whether the database/overlay is closed due to a server shutdown or a delete operation on cn=config.

> Am Freitag 26 Februar 2010 13:30:55 schrieb masarati(a)aero.polimi.it: > Returning an error just for the LDAPSync related Search seemed more > logical to me. In any case, (ab)using an existing error code might not be optimal. as a consequence of removing slapo-syncprov(5), any consumer using it needs to be clearly informed that just retrying later is probably not an option. On the contrary, returning a dedicated error would allow to exactly inform the consumer about what it can expect from the (former) producer, and possibly to suggest a strategy (e.g. the message could contain a hint about some substitute producer, or so).

> masarati(a)aero.polimi.it wrote: >>> Am Freitag 26 Februar 2010 13:30:55 schrieb masarati(a)aero.polimi.it: >>> Returning an error just for the LDAPSync related Search seemed more >>> logical to me. >> >> In any case, (ab)using an existing error code might not be optimal. as >> a >> consequence of removing slapo-syncprov(5), any consumer using it needs >> to >> be clearly informed that just retrying later is probably not an option. >> On the contrary, returning a dedicated error would allow to exactly >> inform >> the consumer about what it can expect from the (former) producer, and >> possibly to suggest a strategy (e.g. the message could contain a hint >> about some substitute producer, or so). > > This situation is no different than pointing a consumer at a server that > has > no provider configured. We don't do anything special for that case; I > don't > believe anything special is called for here. Well, I believe it's not exactly identical. If you point a consumer to a DSA that's not a producer, sync replication cannot initiate. If you point a consumer to a DSA that's a producer, and eventually ceases to be a producer, the consumer could take advantage of being informed that it's pointless to keep retrying an "unwilling to perform" that could be interpreted as a temporary failure. But I don't want to make a point of it, as it would probably take us too far from the initial objective...