RE: ITS#1679 gentle SIGHUP handling

["Howard Chu" <hyc@highlandsun.com>]

Yes, what you suggest can be done, but I think it may be more effort than
it's worth. Much simpler just to go with the first idea. Set up a timer on
the old slapd that makes it quit even if there are active sessions, the
client can always reconnect and it'll get the new slapd.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Hallvard B
> Furuseth
> Sent: Friday, April 05, 2002 2:43 AM
> To: Pierangelo Masarati
> Cc: openldap-devel@OpenLDAP.org
> Subject: Re: ITS#1679 gentle SIGHUP handling
>
>
> Pierangelo Masarati writes:
> > but as Howard noted, this feature would be strikingly interesting
> > if the *configuration* is changed while using the *same* database.
>
> There is one another way to restart slapd almost seamlessly, at
> least on many Unix variants.  Maybe I should implement this too?
>
> 1. Start a new slapd daemon which sends a control message to the
>    old slapd but does not open any listener connections.
> 2. Old slapd quits reading new requests from clients that already
>    have outstanding requests.  Instead it reads and processes one
>    request at a time per client.  Or is that how it works already?
> 3. When there are no more outstanding requests except the ones being
>    processed, old slapd stops reading new requests.  It send()s its
>    listener file descriptors to new slapd, along with the associated
>    LDAP URLs.
> 4. If both slapds are in readonly mode or if they use different
>    databases, new slapd can begin to accept new clients.
> 5. When a client's final outstanding request is processed, old slapd
>    send()s the client's file descriptor to new slapd, along with the
>    Connection struct describing the client.
> 6. When all clients are done, old slapd terminates.
> 7. New slapd starts up properly, if it didn't in step 4.
>
> In theory old slapd can close the databases and new slapd start up
> as soon as all requests' database accesses are finished, they do not
> need to wait until the results have been sent.  I'm not sure if that
> can be fitted into the current design of the backends, though.
>
> Ldap will slow down a bit in step 2, and hang in steps 3-6 for as
> long as it can take old slapd to process a request and send the
> results.  I don't know how much time I'm talking about here?
> Is it so much that the 'gentle SIGHUP' approach is better?
>
> There are a few problems:
>
> - I don't know what to do about paged results.  The simplest way I
>   can think of is for old slapd to wait to start step 1 until there
>   are no paged requests, and if that doesn't happen in X seconds,
>   abort the connections to clients with paged requests.
>
> - A socket can get full, can't it?  So if a client doesn't read the
>   results at once, slapd can get stuck trying to send the results.
>   The simplest solution is to abort the connection after Y seconds,
>   but if we can close the databases first, that's not necessary.
>
> - I think a client can hang due to congestion after step 2 if it
>   pours a lot of requests into slapd quickly without reading the
>   results at once.  Then slapd can be stuck trying to send the old
>   results into a full socket.  Again, the simplest solution is to
>   abort the connection if the client doesn't wise up after Y
>   seconds.
>
> - If there is a deadlock in slapd somewhere so a client is
>   deadlocked but the rest of slapd is not, old slapd won't
>   terminate.  Again, abort the client connection after Y seconds.
>
> Have I missed anything?
> Do you know what of this is likely to be harder than it looks?
> Is there any reason why it would be a good idea for old slapd to
> send its outstanding _requests_ to new slapd as well?  I'd rather
> avoid that before it gets even more complicated.
>
> --
> Hallvard