In message <199609271412.JAA14363@miaow.sps.mot.com>, Dave Wolfe writes:
>Please understand what I'm saying here: Exponential backoff is not a
>panacea for the boundary conditions it's trying to address and *purely*
>exponential backoff creates its own problems. This is a complicated
>problem and requires careful modeling and analysis. It shouldn't be
>lightly incorporated into 1.94 at the last minute like this without that
>analysis and testing. I should think your followup about forgetting to
>change the number of retries should convince you of that.
I simply don't agree.
We all know that both the locking mechanism itself has problems,
and the backoff algorithm used has problems too.
I don't agree that this is at all related to "how well tuned" a given
host is. Majordomo simply takes a long time to do certain operations,
and it _must_ be able to withstand a certain amount of mailbombing.
Doing a random exponential backoff _will_ address these concerns, without
really affecting the average user.
All the past retry algorithms were done with minimal testing an analysis.
They all were deficient. At least with this algorithm we have the
knowledge that its use is rooted in comparable prior art, and has survived
that long test of time.
Please, Chan, go with the random exponential backoff now in 1.94. It's
not perfect, but it's a lot better than what we have now.
--Dave
Follow-Ups:
References:
|
|
