I'm always in favor of increasing rather than static backoffs because it tolerates more environments (I use http://en.wikipedia.org/wiki/Truncated_binary_exponential_backoff).
If it did back off this way would it still be necessary to treat retry_later specially? The proposal not to decrement the retry counter worries me because an operation that continues to fail should eventually stop trying; clearly something is more broken than it should be and adding to the problem is counterproductive. B. On Wed, Apr 7, 2010 at 11:10 PM, Randall Leeds <[email protected]> wrote: > Also, I'm concerned that we cannot rely on couch not to starve the > reader requests while allowing the missing revs requests, leading to > an unbounded growth of the reader queue. The reason for this is that > the reader requests are started with spawn_monitor and therefore > erlang scheduling might give the reader loop time issue the next > couch_rep_missing_revs:next/1 call before any or all of the document > read processes call couch_rep_reader:open_doc_revs/3. >
