Exceptions that corrupt application configuration

[Kent]

I'm hoping for a recommendation for dealing with the (rare) exception that could happen during initial application loading which ends up corrupting the application.

While rare, I've seen that, for example, an unfortunately-timed database disconnection which happens to occur during initial application load and configuration, but after most other configuration leads to an unusable wsgi process (it is half-cooked).  All subsequent requests Apache sends to this process attempts to load the application (again) but it is in a state which causes an exception every time (because it was partly already configured).

I've considered wrapping the delicate start-up code section in a try-except block that would signal itself for termination so that Apache restarts that child:

os.kill(os.getpid(), signal.SIGINT)

But I wanted to check whether there is a "preferred" or better approach to dealing with this circumstance?

Thanks in advance!

Kent

[Graham Dumpleton]

You need to use daemon mode and then use the 'startup-timeout' option to WSGIDaemonProcess.

It was primarily added to cope with how Django initialisation is now no longer reentrant and so if an error occurs during startup, the process can be forced to restart after talking too long. This is intended to replace the use of os.kill() you may see examples of out there for doing the same.

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/5b325ada-b68b-4bb4-902f-ba2b7560cd00%40googlegroups.com.

[Kent]

Graham,

Thank you for replying.

I am indeed using daemon mode.  In these conditions, I reach the "mod_wsgi (pid=%d): Target WSGI script '%s' cannot be loaded as Python module." error.  My concern is that, until that somewhat arbitrary timeout occurs, Apache will happily continue to send requests to this child process, even though I've already detected its configuration has been messed up permanently.

Wouldn't it be better in these circumstances to signal a shutdown so that Apache doesn't send more requests to this process, maybe with signal.SIGUSR1?  (Does SIGUSR1 do anything different from SIGINT, BTW?)

Thanks again,

Kent

To unsubscribe from this group and stop receiving emails from it, send an email to mod...@googlegroups.com.

[Graham Dumpleton]

It is not an arbitrary timeout as you can set the length of it. :-)

Anyway, if you need better control send SIGINT to your own process ID if you know the condition is satisfied. This should stop accepting of new requests by that process. Don't use SIGUSR1 as that triggers a graceful shutdown of the process so new requests will still be accepted until the shutdown sequence kicks in after the graceful timeout.

To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/29dc0223-b705-42fd-a1dc-53e9b88109c1%40googlegroups.com.

[Kent Bower]

I very much appreciate your input!

You received this message because you are subscribed to a topic in the Google Groups "modwsgi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/modwsgi/RGODjsvHY68/unsubscribe.
To unsubscribe from this group and all its topics, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/15947F87-F670-40CA-8E64-B9D419CABD56%40gmail.com.