[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
NT, slurpd, rambling
Just out of curiosity I updated my build tree on my Windows laptop. Had to
update from BDB 4.1.1 to 4.1.25 and remember how to build it, then got
OpenLDAP HEAD to build. While I was poking around I copied the NT service
code from slapd into slurpd and left it running on my machine. I noticed that
slurpd spends a lot of time spinning waiting for the replog file to get
non-empty.
A long time ago when I first noticed this, I thought - why don't we have
slurpd replace the replog file with a FIFO, named pipe, Unix domain socket,
whatever, when it starts up, and then it can just sit in a blocking read on
that? There's a problem of what to do if slurpd exits, but that's easy
enough - if slurpd stops listening, any write attempt to the (pipe) will
fail, and slapd can switch back to writing a flat file. (The easiest thing is
to use two filenames - the existing flat text file, and a second name for the
named pipe. slurpd creates the named pipe on startup, processes and empties
the flat file. slapd checks for the named pipe and writes it if it exists,
otherwise writes to the flat file. If a write to the named pipe fails, delete
the named pipe; slurpd will recreate it when it starts again...)
Of course slurpd is soon to be replaced with this client-driven replication
stuff that is still under development, so it's not too interesting now.
But along these lines, we can also build a replicator on top of back-ldap. It
just needs to be able to save state for when a target is down, and have a
manager thread to try and kick queued ops out periodically. Otherwise it runs
in realtime. The queue manager can use back-bdb as its backing store,
similarly to how the LDAP proxy cache works. It can be a simple queue, or it
can coalesce multiple changes to the same object while a target is down.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support