[Date Prev][Date Next]
Re: direct local change when a consumer chains a write to the producer?
- To: Michael Ströder <firstname.lastname@example.org>
- Subject: Re: direct local change when a consumer chains a write to the producer?
- From: Howard Chu <email@example.com>
- Date: Mon, 05 Dec 2005 03:02:27 -0800
- Cc: OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <1132505214.3316.117.camel@ando> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <1132590414.3330.4.camel@ando> <email@example.com> <firstname.lastname@example.org> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando> <email@example.com> <1133163684.3318.10.camel@ando> <438AC745.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <43941115.7050302@symas .com> <firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051203 SeaMonkey/1.5a
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/