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

Re: direct local change when a consumer chains a write to the producer?

Michael Ströder wrote:
Howard Chu wrote:
The question is how important is it that clients be able to immediately
follow a write request with a read request,
and why these clients aren't
just using a post-read control in the first place.

When integrating software with a directory you don't have the power to insist on using this rather unknown control in the clients. Big software vendors are most times refusing such a feature request.

If this is something
that needs to be done frequently, then we probably need to provide an
option somewhere in syncprov to go back to its fully synchronous
behavior. Perhaps that should be a control of its own - "WaitForSlaves".
Still, only newly written clients would be aware of this control, so
what should the default behavior be without it?

I'd prefer having a replication configuration directive for that.

That would be simplest, but I can see needing this option on a per-request basis, as there may be a mix of clients in the same environment with different requirements. Assuming most clients don't re-read the just-modified entry, you gain throughput by keeping the updates asynchronous. For clients that re-read, the update must be fully synchronous, and this poses a problem (ITS#3671, losing connectivity to a consumer will hang the provider).

For these fairly special cases I can see configuring syncprov to be synchronous based on the authcID, that would allow your PKI system and a chaining consumer to work correctly. But in a synchronous situation I don't see a good fix for the hang issue.

 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/