On Sat, Jul 2, 2016 at 6:38 PM, Arne Schwabe <a...@rfc2549.org> wrote:
> > connect-retry 5 1800, which would mean "scale back up to 1800s" and > > maybe default that option to connect-retry 5 300. That also allows > > specifying larger connect-retry values without backoff. E.g. > > connect-retry 60 60 > > > > > > Good idea. > > > > Agreed, triggering SIGHUP is not ideal. The only reason for it was to > > reset the counters so that the backoff time doesn't get stuck at the > > highest value for ever. If we reduce the max backoff interval that's > > less of a concern. > > > > One motivation for this patch is to avoid logs filling up. For a client > > stuck in a restart loop with verb=3 and 5 minutes max pause, the logs > > grow by about 1 M per day -- may be not too bad. > > > > Selva > > Do you want to propose a new patch or should I do it. I would propose > still a exponential backoff but starting a 2s. so we get 2s 4s 8s ... or > as default conect-retry 2 256. It would then just stay at the 256s > interval until a sucessful connection is established. That simplifies > the logic and gives predictable (from a user perspective) results. > > Iirc the logic of connect-retry was changed by me in master so changing > the logic again should not be a problem Just sent off v2 before checking for new mails... If you want to change the default wait time to 2s, it can be easily done in an independent patch. Was there a reason fro changing it from 2s in 2.3 to the current 5s in the first place? In any case my v2 would use 5, 5, 5, 5, 5, 10, 20,... ,160 and then jump to 300 instead of 320 and stay there which is pretty ok in my opinion. As the user can now specify any combination of the base wait interval and the max value, the last interval before capping will have an odd value in general -- we can avoid it for the default values but it will only stay so until someone changes the default again one day.. In case it matters, the intervals are still predictable although it doesn't have to be in a true backoff logic. Selva
