Information Source ignoring Spawning Timeout

[klou]

http://lists.octality.com/pipermail/cherokee/2012-February/015514.html

I also have Cherokee running as a reverse proxy (local) to a small Flask app. With the Spawning timeout as default (should be 3 seconds), I would expect it to wait while spawning the app process. Instead, it gives up and immediately serves a 502.

An immediate browser refresh then produces the correct results.

Changing the timeout has no apparent effect, unless I'm misunderstanding how that field works.

[skinkie]

The spawning timeout refers to the time between 'respawning' a new process as far as I know. When the sources as exhausted for one reason or another Cherokee backs-off for a while prior to retrying to do it again.

I think in tho google bugtracker there is also a bug by me that asks if the user that firstly requests a page could be put on hold prior to serving the broken request. (You seem to agree with me that the F5 option works).

[mdavid]

A 502 Bad Gateway error suggests a communication error between the server and specified proxy.

https://tools.ietf.org/html/rfc2616#page-70

10.5.3 502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to
fulfill the request.

In this regard, Cherokee is simply taking what was returned by the proxied Flask app in the response stream and, as per the specification, parsing the response and translating it into the appropriate response to send to the request client. My guess is that Flask is configured to immediately return a 502 response to any requests made during its startup process that it is as of yet unable to process rather than holding the connection open while the process completes. Not sure if it can be configured to wait until the startup process completes before returning a response, but I can understand why they may choose the immediate return rather than holding on to connections (flooding resource requests overwhelming the system and causing a system lock if a service goes being the primary reason) but I can't say for sure. Regardless, this isn't an issue with Cherokee.

[skinkie]

I disagree here. I think what happens:

1. User makes a requests
2. Cherokee didn't spin up the backend yet
3. Cherokee replies this to the user
4. In the mean time Cherokee has set up the backend
5. The user does another request, which is instantly served over the balancer infrastructure

[mdavid]

If this were the case (I haven't checked the code just yet to verify) then you're right, Cherokee would be incorrectly dealing with the request. However, my own experience with Cherokee launching a given service has been that of waiting for:

a) A response from the service.
b) A TTL timeout

In the first case the response can be anything the service wants it to be. e.g. 502
In the second case, my experience has always been Cherokee returning a 503 Service Unavailable response which as per @klou's experience, is fixed by simply making a new request that in turn waits for a response or for the TTL timeout period to expire, whichever comes first.

Has your experience been different?

[klou]

This doesn't help, but I wanted to add a bit of "closure" or at least a workaround (and I've been ignoring it until recently)

For that particular app/Virtual Server, I simply used the Error Handler to redirect 502 to the applicable URL - as an external redirection. By the time the redirection occurs, the flask app has spun up.