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.
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)?
p.
Am Freitag 26 Februar 2010 13:30:55 schrieb masarati@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.
Ralf Haferkamp wrote:
Am Freitag 26 Februar 2010 13:30:55 schrieb masarati@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.
Agreed. The actual choice of error probably isn't too critical. LDAP_UNAVAILABLE sounds fine.
Also on the topic of deletes, we should start adding term_module() handlers to the backends and overlays.
Am Freitag 26 Februar 2010 19:29:43 schrieb Howard Chu:
Ralf Haferkamp wrote:
Am Freitag 26 Februar 2010 13:30:55 schrieb masarati@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.
Agreed. The actual choice of error probably isn't too critical. LDAP_UNAVAILABLE sounds fine.
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.
Ralf Haferkamp wrote:
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.
I vote for a new call. Modifying the API of existing calls breaks source code compatibility. Adding a new helper only breaks binary compatibility. Code duplication issues can be dealt with by modules.
p.
Am Freitag 26 Februar 2010 13:30:55 schrieb masarati@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.
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).
p.
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.
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...
p.
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?
-
Howard Chu -
masarati＠aero.polimi.it -
Pierangelo Masarati
-
Ralf Haferkamp