On Thu, 22.07.10 15:19, Simo Sorce (sso...@redhat.com) wrote: > > But also HTTP is a good candidate. When apache shuts down it closes > > the listening socket but will finish processing the requests it > > already began to process. Would apache use socket actviation like > > this it would hence be restartable without loosing a single HTTP > > connection: what is already accepted will be processed, but what has > > not been accepted yet will be delayed until apache is back up again. > > > > Something similar is of course true for every state-less protocol like > > this, where each requests can be processed independently of every > > other request. > > > > And when a daemon crashes only the requests that were currently > > processed will be lost, all others stay queued and will then be > > deqeued and processed after the restart. > > > > Socket activation does not prevent all kinds of data loss or denial of > > service when a daemon crashes. However it is actually big step to make > > the data loss minimal and the outage window as short as possible. > > Bad example, it may make sense if you have a single host, but if you > have multiple HTTP servers, you want the one that died to stop answering > until it is back up and running and ready to server requests. > > The last thing you want is to have a client wait forever because the > systemd doesn't kill the socket but apache is not able to properly > restart (say for a configuration mistake).
Well, not everything makes sense in all contexts. If you have a fallback web server in place then you don't need this trick. But I am pretty sure there are more web serving devices on this planets that do no failover like you suggest then there are that do this. And for those, which otherwise have no defined fallback path it is certainly really awesome if they can just restart apache if it crashes and can rest assured that they won't lose any request except the one apache actually crashed on. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
