On Fri, Jul 01 2022, Oswald Buddenhagen wrote: > yeah, i've been pondering this, and i'm somewhat undecided how to go > about it. the problem is that there are lots of conditions, and how one > "condenses" them into a single flag is somewhat arbitrary. my current > thinking is that it would be better to handle transient problems > internally, and have some related config options. my private "extended > TODO" contains this: > > - MaxRetries > - reset when progress was made: > - message bodies fetched or stored > - flags updated > - MaxRetryDelay > - used with instant errors like connrefused > - also with near-instant errors like connreset within n seconds? > > the underlying thinking is that there would be exponential back-off, > which would be used and reset depending on the case.
A good distinction could really be if retrying makes sense or not. Almost every network error falls into this category (and I say almost because I suspect there might be cases where a remote mailbox error is unrecoverable and retrying won't help). Handling retries internally would be really nice. This only makes sense if network timeouts are handled pervasively though. I'm currently running mbsync within timeout(1). Not pretty for sure as it can interrupt transfers, but mbsync can currently get stuck during slow/blocked transfers in multiple places, most commonly during resolve or during connect. If the network is reconfigured (ip address change) while a connection was taking place, the connect will linger for minutes, blocking subsequent updates. On an unstable connection such scenarios are pretty common. It's actually faster to interrupt and reconnect than waiting for a packet resend. _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
