HI Michael,
There's a problem here - Web apps don't have a lifecycle like this. The only part of the app lifecycle that can be relied upon is the request-response cycle - someone makes a response, which will eventually be returned as a response. Outside of that internal lifecycle, not much can be guaranteed. A process will have to start in order to service a request (and there are ways to hook into that), but there are no guarantees that this process will last for 1 request, 10 or 10000. And there isn't a coordinated shutdown of the web process - the web server may choose to shut down a web worker at any time.
If you're using a queue to perform some sort of external processing, then that queue should be stored *outside* the web app itself. This means using a message queue (like RabbitMQ), or a service that provides an analogous interface (like RQ, layered over Redis). That way, a short lived web request can push something onto the queue, and then exit immediately. The web request doesn't need to worry about the lifecycle of the queue - it just uses the queue as a service.
In short - you need to stop thinking of the web server as a "program" with a startup, shutdown, and predictable lifecycle, and move to thinking about it as "a function floating in space that can be invoked" - because, in practice, that's what it is. If you've got anything long lived, it needs to live outside the web process.
Yours,
Russ Magee %-)