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

Re: PATCH: back-sock

Brian Candler writes:
> I'm working on tweaking the patch for 2.3.11 now.

Please work from the CVS HEAD branch instead.  (Might or might
not need changes from what you have done with 2.3.11.)
Otherwise someone may still have to port your patch to HEAD, and
you are the "someone" with most obvious interest in doing so.

>>> * FIXME: count the number of concurrent open sockets (since each thread
>>> * may open one). Perhaps block here if a soft limit is reached, and fail
>>> * if a hard limit reached
>> Or defer the operation a little and try again later, with some
>> timelimit for how long to wait.
> I think that's what I meant by 'block',

Ah, of course.

> although I'd rather avoid having to spin and poll.  Perhaps there's an
> object like a semaphore it could wait on, and have the thread library
> wake us up when we're ready to continue.
> My knowledge of threaded programming in C is minimal... that's why I like
> prefork libraries :-)
>> At the same time, you could add code to retry a few times if connect()
>> fails because no worker process is listening to the socket file.
>> Otherwise, if you start slapd and the worker process at the same time, I
>> think the first LDAP requests can fail if slapd starts up quicker than
>> the worker process.
> That's possible, although that particular problem goes away if you
> start the worker pool before slapd.

True.  Unless you one needs to restart both the workers and slapd.
The current "safest" sequence for that might now be stop slapd, then
worker, then start worker, then slapd.

>> Such a change might also allow the admin to kill and restart the worker
>> process without restarting slapd, and with no LDAP operation failures.
> Indeed.  What do other backend modules do?  For example, if you're
> running back-sql and you stop the SQL server for 5 seconds, do the
> requests back up and automatically retry, or do they return
> LDAP_UNAVAILABLE to requests during that period?

I don't know back-sql, but in general there is no such option now.
I think it will be needed however:

2.3 has a new and still evolving config backend/database which can be
updated with normal LDAP operations in order to add, remove or configure
slapd - including the other databases.  So if I understand correctly you
can e.g. update a BDB database by deleting it from back-config, replace
its database files with newer ones, and re-add it.  I don't know if
there is a way yet to make slapd return busy or something instead of
noSuchObject for attemts to access the database being replaced, but if
there isn't there needs to be someday.