We have clients which must check that an update has reached all LDAP servers before they start some task. So we need to publish a list of all servers.
Where would you put that list, when clients should normally not contact these servers directly (ldap-prod*.uio.no) but instead contact the load balancer sitting in front of them (ldap.uio.no)? 'altServer' in the root DSE anyway, or has someone defined another attribute?
With transactional backend databases, an existing slow LDAP operation predating the change might return the old value while this quick poll sees the change. I'm content to just tell clients to wait a second after seeing the change though, unless someone has brighter ideas.
Finally, has anyone written a nice little server (LDAP or otherwise) which does this - client sends a request, server checks all LDAP servers and either returns true/false or waits & retries while false?
Hallvard Breien Furuseth wrote:
We have clients which must check that an update has reached all LDAP servers before they start some task. So we need to publish a list of all servers.
Where would you put that list, when clients should normally not contact these servers directly (ldap-prod*.uio.no) but instead contact the load balancer sitting in front of them (ldap.uio.no)? 'altServer' in the root DSE anyway, or has someone defined another attribute?
With transactional backend databases, an existing slow LDAP operation predating the change might return the old value while this quick poll sees the change. I'm content to just tell clients to wait a second after seeing the change though, unless someone has brighter ideas.
Finally, has anyone written a nice little server (LDAP or otherwise) which does this - client sends a request, server checks all LDAP servers and either returns true/false or waits & retries while false?
This requirement makes no sense, particularly if the clients can only access the directory through the load balancer. What is the ultimate goal, what does the client do next?
The most obvious thing to do is to use a postread control on the original request, to read the entryCSN of the change. Then use an assert control on the following request, assuming it references the same entry.
Howard Chu writes:
Hallvard Breien Furuseth wrote:
We have clients which must check that an update has reached all LDAP servers before they start some task. So we need to publish a list of all servers.
This requirement makes no sense, particularly if the clients can only access the directory through the load balancer. What is the ultimate goal, what does the client do next?
The point is to wait until other clients (which use the load balancer) will all see the new value.
In this case, that value says "pause mail delivery to this address". The client will move a mailbox to a new server. After the other clients in question stop delivering e-mail.
Eh, this was irrelevant though:
With transactional backend databases, an existing slow LDAP operation predating the change might return the old value while this quick poll sees the change. I'm content to just tell clients to wait a second after seeing the change though, unless someone has brighter ideas.
...in particular since the delivery clients will be using the value they read some time after reading it anyway, so the "waiting" client must in any case in wait long enough for mail delivery to stop.
The most obvious thing to do is to use a postread control on the original request, to read the entryCSN of the change. Then use an assert control on the following request, assuming it references the same entry.
That has nothing to do with contacting all servers.
openldap-technical@openldap.org
-
Hallvard Breien Furuseth -
Howard Chu