On Thu, 2007-05-31 at 15:40 +1000, justin randell wrote:[...]

The answer is "it depends".

When establishing a connection, Pound does try all relevant back-ends
before giving up and returning a 503.

On the other hand, once the connection was established, subsequent
requests are answered only by the current back-end, and a failure will
result in a 503. This applies only to HTTP 1.1.

Hope this helps a bit.[...]

hi robert,

On 6/1/07, Robert Segall <roseg(at)apsis.ch> wrote:[...]

thanks for the explanation.

just to make sure i understand: prior the initial pound -> backend TCP
connection, we have redundancy? but once a pound -> backend TCP
connection is established, if the given backend dies we get 503's even
if other backends are available?

how difficult would it be to add the checks for alive backends in a
service after the TCP connection is established? is this a feature you
would consider?

cheers
justin

It would be useful if Pound checks other backends before to respond to
client with 503 error.

Regards
Lorenzo

So if I understand well:

If I have a 30 minutes timeout IP persistency setup for my service with 2
backends
One of my backends dies
Half my users will be getting 503s for 30 minutes?
[...]

hi François,

On 6/4/07, Francois Rejete <francois(at)rejete.com> wrote:[...]

i'm not exactly sure what you mean by "IP persistency", but as i
understand it, pound will stop trying to use a given backend after the
first 503 (not keep retrying it and thus sending 503s), so you wont
get half your users getting 503s for 30 minutes.

the issue here is a bit more fine-grained - can the first 503 be
avoided when pound is reusing an existing TCP connection to a
particular backend in a service definition,  where the given backend
dies but there are others available?

hope that helps.

cheers
justin

On Mon, 2007-06-04 at 17:58 +0900, Francois Rejete wrote:[...]

No. Once a back-end is dead its sessions are removed, and new requests
go to other back-ends.

The situation I described applies to HTTP 1.1 (multiple requests per
connection): a client opens a connection, the first request goes through
OK, but there is a problem with the second. The client gets a single 503
and the connection is closed.

In some cases (not all) the back-end is declared dead. This was done so
that a slow back-end may time-out without being killed.[...]