On Mon, Jan 25, 2016 at 5:14 AM, Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
> Hi Greg,
>
> With 794c86fd289b ("monc: backoff the timeout period when
> reconnecting") you made it so that the backoff is applied to the hunt
> interval. When the session is established, the multiplier is reduced
> by 50% and that's it - I don't see any per-tick reduction or anything
> like that.
>
> If a client had some bad luck and couldn't establish the session for
> a while (so that the multiplier went all the way up to 10), its initial
> timeout upon the next connection break is going to be 15 seconds no
> matter how much time has passed in the interim. Was that your intent?
I don't remember this, but looking at the sha I logged that behavior
in the commit message, so I'd have to say "yes". As it says, we're
trying to respond to monitor load; if they're doing so badly that we
had to increase our timeout when re-establishing a session, there's
every chance it will continue to be slow. If we reset the timeout back
to default, we'd have to go through a lot more monitor-punishing
timeout rounds on the next failure than just cutting it in half would
take.
-Greg
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
