Comment 6 for bug 881983

OK - I agree that the best way to do this is to create a new behaviour type - in fact thinking about this I'd like to make the "retry after marked dead" time orthogonal to the "retry on timeout" time.

So the behaviour becomes:

1. Server is good - we keep retrying on the timeout until we hit the number of failures limit
2. We mark the server as dead, and it stays dead until the "retry after market dead" timeout expires
3. We then retry a server connection, and if successful add the server back to the pool - back to the state before 1. If fail we reset the retry timeout

Now we need to do this carefully with consistent distribution, as at 2. the keys have moved to a different server, and we don't want to reset those cache keys when we add the server back to the pool (but we'd like it to accept new keys)

I'm _not_ sure I agree that anyone would be happy with the current behaviour though - as what happens now is:

1. Timeout for num_retries * retry_timeout
2. Move keys to another server for 1 x retry_timeout time
3. Timeout forever

So you get keys moved for 1x the retry_timeout time that's pretty strange behaviour.