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

Re: socket instead of replog file



On Sun, 18 Apr 2004, Roland Bauerschmidt wrote:

> You could use a file notification (if available) instead. You might also

sure, i could use fam (http://oss.sgi.com/projects/fam/) or other file
notification tools, or patch the kernel

but
1) anyway, i'd have to patch slapd and slurpd at about the same grade i'm
already doing for the socket implementation
2) it wouldn't be so efficient as a socket would be, would it?
3) question: could a builtin socket be in the future a part of the
official openldap branch? (i'm patching the code in order to make possible
to choose whether to use or not the socket at all, and as well to use the
replog as a fallback in the case slurpd is unreachable, so that when
slurpd is up and running again there'd be no data loss)

> want to check if syncrepl fulfills your demands (if you haven't done so
> already).

i already did it, and i read...

from the OpenLDAP 2.2 Administrator's Guide, chapter 14:
[...] A syncrepl engine resides at the consumer-side as one of the slapd
(8) threads. It creates and maintains a consumer replica by connecting to
the replication provider to perform the initial DIT content load followed
either by periodic content polling or by timely updates upon content
changes.

so, i think it would solve many of my filesystem-related problems, but
what about realtime replicas if the client does 'periodic content polling'
or 'timely updates'? or am i wrong?

btw
i subscribed to the list, so you don't have to send me cc's, thanks anyway
=)


--
ciao
st3