Define optional delay time between (Connection) retries

[vmattila]

In case that a connection error happens, Connection::retry() loops configured amount of times. It would be useful in connection errors that the library would sleep a second before a new try: that would allow for example primary failover to complete better.

Optionally, the sleep time could be exponential: first retry immediately, second retry after 1 second sleep, third reply after 2 seconds and so on.

I am happy to contribute with the code if this feature is considered useful in general.

[jmikola]

This seems like a useful feature for all of the retry() methods, since a replica set failover could disrupt connections and queries alike. Since the total time for a failover should not exceed one minute, we can likely cap the maximum retry time, too.

Currently, the non-Connection classes take options as constructor parameters. It may make more sense to pass around the Configuration object. I'm open to suggestions on that -- sadly, it'd be a BC break.

This also seems relevant: http://en.wikipedia.org/wiki/Exponential_backoff

[vmattila]

I went through all retry() methods and found them in Collection, Connection and Cursor classes. It seems that the $numRetries is the only configuration parameter in most constructors with exception of Collection having also $cmd for the command prefix. At least $numRetries could be replaced with a Configuration object - or if there is no other options to configure - with something like RetryConfiguration. To maintain BC (for a while), constructors could convert integer $numRetries to proper Configuration object instance and rise a deprecation notice.

Is there possibility that we'll get "nested" retry loops? Something like an error occurs in Collection retry, it's retried with an optional sleep until an exception is thrown, captured in Connection retry loop and started again? Should we delegate the whole retry logic "globally" to a central object shared between all retrying objects? The "retry manager" could then keep track of all errors and retries and decide not to retry if the application has tried to survive from errors too long (for example up to the minute or near PHP's max_execution_time. Maybe too much complexity for simple things, though...

[jmikola]

I don't think nested retry loops are desirable, because then the retry logic would certainly exceed the number of attempts and delay (if any). Also, Connection only retries when initializing and attempting to connect, which are distinct from the actions that a Database or Collection would retry.

I've already removed the command prefix arguments in #131, so constructor signatures are definitely changing for 1.1. I would like to get this feature into 1.1 stable (or an ensuing patch release), and will attempt to utilize some configuration object as you said instead of tacking on new constructor arguments.

[jmikola]

Relevant: https://gist.github.com/jmikola/cc3034eb2c78c863db40