Comment 15 for bug 308181

>> (...) For example the Local Director
>> will mark a service as bad when it gets a failed connection. Even
>> though the connection would finally make it over to a good server
>> the user experienced a delay assuming the server was off the network
>> and had to wait for TCP timeouts. From that point on the LD would
>> direct traffic to services it knew were good. (...)
>
> Only the connection which "detected" the failed service hangs?

Correct.

>> So assuming we don't want the user to get hung up on a down server
>> every time they traverse the service list we need to keep a running
>> tab on sevices we've tried in the past. (...)

> I haven't understood why the user will always get hung up on a
> failed service. The LD is not going to deliver newer connections
> to a healthy server after one failure?

That part I was describing was without LDs and so strictly inside of
the browser. If we requery DNS every time and have to run down the
list servers listed for the service and there is a down server, the
user will get hung up on that down server. It will eventually time
out and the browser will try the next server, but the user will have
to wait. Which is why the implementation might want to cache the
DNS data internal to the browser and keep track of which servers are
up and which ones are down.

Or something else I had thought of, but didn't want to mention
because I didn't like it, was to initiate connections to all servers
listed and use the one that responds first. Or if there are, for the
sake of argument, 20 objects on a particular page and connections
were opened to 4 differant servers, then each connection can serve 5
objects, assuming each server is weighted equally, through the use of
persistant connections.