[Zope-Coders] Signal forwarding

[Toby Dickenson]

On Friday 11 Oct 2002 2:35 am, Chris McDonough wrote:

> and it will show that I
> don't actually *run* a Zope site=20

Then get off the open source projects, back to commercial software where =
you=20
belong!

> ( ;-)

;-)

> Does
> Apache do this sort of thing?

This patch changes a number of different things. I assume you are asking =
about=20
the phased shutdown....

This approach is almost identical to the one used by Squid, and Squid's=20
architecture is very similar to Zope's.

Apache does a very similar thing: it allows its individual child processe=
s to=20
shutdown when they have completed their current request. See SIGUSR1 at
http://httpd.apache.org/docs/stopping.html .

Apache's multi-process approach has the advantage that the shutdown as a =
whole=20
is not be delayed by one slow client. If 30 seconds of downtime is=20
unacceptable during a restart then the best workaround for Zope is the sa=
me=20
as for squid: Run two copies of the server, and dont restart them both at=
 the=20
same time.

> but can you provide an example
> of where this level of gracefulness is absolutely necessary? =20

Currently Zope responds to a shutdown request by stopping unconditionally=
 and=20
immediately. Client sockets are severed as they stand - possibly half way=
=20
through a response. This can lead to browsers displaying half-complete pa=
ges,=20
and similar problems. Some clients dont detect that a problem has occured=
 and=20
may cache the half-complete pages.

(until recently Zope actually close()d all its sockets before shutting do=
wn -=20
denying clients any possibility of detecting that they have not received =
the=20
whole response. Today Zope leaves this to the operating system, so this=20
problem only occurs if the client has a bug.)

Another way of tackling this problem would be for clients (or intermediat=
e=20
proxies) to retry a request if it is terminated mid-response. This works =
fine=20
for GET requests, which can be assumed to be idempotent, but not for POST=
 or=20
PUT.

I am particularly interested in this because my application has a particu=
larly=20
high density of POSTs. Without such a change, my application required hum=
an=20
intervention if Zope is shut down half way through handling a POST.