[Date Prev][Date Next]
Re: direct local change when a consumer chains a write to the producer?
- To: Howard Chu <email@example.com>
- Subject: Re: direct local change when a consumer chains a write to the producer?
- From: Michael Ströder <firstname.lastname@example.org>
- Date: Mon, 05 Dec 2005 11:37:11 +0100
- Cc: OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <email@example.com> <firstname.lastname@example.org> <email@example.com> <1132590414.3330.4.camel@ando> <firstname.lastname@example.org> <email@example.com> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando> <firstname.lastname@example.org> <1133163684.3318.10.camel@ando> <438AC745.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <43941115.7050302@symas .com>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
Howard Chu wrote:
> The question is how important is it that clients be able to immediately
> follow a write request with a read request,
In a project we had problems with a PKI product of a major vendor
accessing another directory server product. The RA component of this
product was first configured to access a shadow server. The shadow was
configured to chain write requests to the master.
It appeared that the RA component was reading an entry right after
modifying it. Strange things with strange error messages happened in the
configuration above. It took us quite a while to figure that the
replication update delay was the problem. The product even had a
configuration directive for awaiting the replication time delay but that
did not work maybe due to a bug of the product. It was simply not
possible to let the RA use the shadow server.
> 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.