Implement graceful-timeout for dameon mode.

[GoogleCodeExporter]

Add graceful-timeout. When using maximum-requests, rather than shutdown 
immediately with 
risk that shutdown-timeout will kick in and requests be interupted, allow for 
up to graceful-
timeout period to occur and if become idle in that time then shutdown. If reach 
end of grace period, 
then do normal forced shutdown with shutdown-timeout applying on top of 
graceful-timeout.

Also have daemon process accept signal AP_SIG_GRACEFUL (normally SIGUSR1) and 
apply same 
policy of waiting graceful-timeout for idle state and then shutting down or 
forced shutdown at end 
of that.

In both cases process is being restarted straight away for same generation of 
Apache parent. This 
isn't linked in any way to an Apache graceful restart or shutdown.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 11 Apr 2010 at 4:02

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 11 Apr 2010 at 4:02

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

This was added in r1583, r1584. and r1585.

Original comment by Graham.Dumpleton@gmail.com on 2 Jul 2010 at 10:55

• Added labels: Milestone-Release4.0

[GoogleCodeExporter]

When I issue apachectl graceful, I notice the app is restarted *before* my 
current request has returned.  Will this change fix that?

Is the current svn HEAD revision stable?

Original comment by jkentbo...@gmail.com on 1 Apr 2011 at 9:20

[GoogleCodeExporter]

Unfortunately this change will not make a difference to Apache graceful 
restarts. It is a limitation of Apache that graceful restarts do not extended 
to non Apache child processes (what it calls other processes). As such, long 
running requests which take more than 3 seconds can be interrupted.

That said, I have noticed myself that Apache isn't working how I expect it to 
work even for requests less than 3 seconds and for new connection when I have 
been doing some siege testing and restarting Apache while the test is going. 
The testing tool should only show a delay and not get failed connections, but 
for some reason it is seeing failed connections. This isn't a mod_wsgi thing 
though but something more fundamental to Apache. I have yet to get time to 
investigate properly.

As to HEAD, I believe it is stable right at this minute, but I will eventually 
go back to hacking on it again which one would have to be careful with using 
it. I do though usually strive not to commit code that breaks anything even 
when doing lots of changes.

Original comment by Graham.Dumpleton@gmail.com on 2 Apr 2011 at 10:26

[GoogleCodeExporter]

You mentioned you noticed Apache isn't working as you expected.  Ignore that 
for a second: according to how you expected Apache to work, is there any way 
one should be able to gracefully restart the web service, allowing the wsgi app 
to restart such that all currently requests are finished, the app cleanly 
restarts and then, going forward, and including any queued requests, these are 
fed to the restarted app?

(The issue this ticket has solved has gone over my head, if not related to 
apache graceful.)

Original comment by jkentbo...@gmail.com on 4 Apr 2011 at 2:34

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 19 Mar 2012 at 10:25

• Changed state: Started

[GoogleCodeExporter]

Just to clarify since the status is 'Started': this change will not affect 
apachectl graceful restarts?

Original comment by jkentbo...@gmail.com on 16 Apr 2012 at 1:39

[GoogleCodeExporter]

The 'graceful-timeout' option for daemon mode will not change how 'apachectl 
graceful' works. That Apache kills off managed processes such as the daemon 
processes created by mod_wsgi is an Apache limitation.

If you are going to use 'apachectl graceful' you will never see requests in 
daemon processes be allowed to complete.

If you are not wanting to restart the whole of Apache, but only the Python web 
application running in mod_wsgi daemon mode processes, in mod_wsgi 4.0 there is 
an ability to send the daemon processes a signal to cause them to perform their 
own form of graceful restart.

Original comment by Graham.Dumpleton@gmail.com on 16 Apr 2012 at 8:59

[GoogleCodeExporter]

That sounds perfect.  If that already there, or pending this enhancement?

Original comment by k...@retailarchitects.com on 17 Apr 2012 at 1:59

[GoogleCodeExporter]

See:

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0400

and also:

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0304

The latter because last weekend back ported a lot of stuff to 3.X branch so can 
make a 3.4 release so not showing in the 4.0 changes file now.

The changes for time outs and other things is being held of still for 4.0 as 
will still be making more changes related to how daemon processes are managed.

Original comment by Graham.Dumpleton@gmail.com on 18 Apr 2012 at 2:09

[GoogleCodeExporter]

I can work something out, but I'm wondering if you have a suggested way to get 
the list of the pids for the processes so I can send SIGUSR1 to each of them?

For example, if my daemon group has processes = 5 threads = 15, I need to get 
the pids of those 5 processes to signal SIGUSR1 for graceful restart.

Second question, I assume that after SIGUSR1 is caught, new requests by that 
process are not accepted, but rather queued until the next process is born?

Original comment by k...@retailarchitects.com on 9 Jun 2012 at 1:11

[GoogleCodeExporter]

To more easily identify process, use display-name option to WSGIDaemonProcess 
to name them. Can then see them separately in 'ps' and depending on platform, 
'killall' command may even allow you to send signal using that process name as 
well.

As to behaviour when signal arrives, it will still continue accepting requests 
and if there is a point within graceful timeout period that there are no active 
requests it will shutdown immediately. If graceful timeout expires, then it 
will stop accepting requests and if during subsequent shutdown timeout period 
there are no active requests it will shutdown immediately, otherwise will be 
forced shutdown when the shutdown timeout expires.

Original comment by Graham.Dumpleton@gmail.com on 10 Jun 2012 at 10:54

[GoogleCodeExporter]

Just to be explicit, when you say "subsequent shutdown timeout period" you are 
referring to "shutdown-timeout" option, correct?

Original comment by k...@retailarchitects.com on 11 Jun 2012 at 12:00

[GoogleCodeExporter]

Yes, am referring to shutdown-timeout.

Original comment by Graham.Dumpleton@gmail.com on 11 Jun 2012 at 12:05

[GoogleCodeExporter]

Closing as completed in 4.X releases.

Original comment by Graham.Dumpleton@gmail.com on 16 Sep 2014 at 7:42

• Changed state: Fixed