masarati@aero.polimi.it wrote:
masarati@aero.polimi.it wrote:
Am Freitag 26 Februar 2010 13:30:55 schrieb masarati@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...
The actual sequence of events would be: consumer receives LDAP_UNAVAILABLE result on its psearch, then the next time it retries, it will be talking to a server with no provider. I.e., identical to the never-configured case, it will receive a search response with no sync control. There is no opportunity to provide more meaningful diagnostics, nor is there actually anything more useful that can be said. The situation might be temporary, or it might be permanent. Who can say?