Might as well paste my code for this :)

class BetterRetryPolicy : DefaultRetryPolicy {
    constructor() : super()
    constructor(initialTimeoutMs: Int, maxNumRetries: Int, backoffMultiplier: Float) :
        super(initialTimeoutMs, maxNumRetries, backoffMultiplier)

    var requestStartTime: Long = 0

    override fun getCurrentTimeout(): Int {
        requestStartTime = System.nanoTime()
        return super.getCurrentTimeout()
    }

    override fun retry(error: VolleyError?) {
        val now = System.nanoTime()
        super.retry(error)
        val elapsedMs = TimeUnit.NANOSECONDS.toMillis(now - requestStartTime)
        if (elapsedMs < super.getCurrentTimeout()) {
            try {
                Thread.sleep(super.getCurrentTimeout() - elapsedMs)
            } catch (ex: InterruptedException) {}
        }
    }
}```

Comment on that code posted a few days ago. It definitely isn't perfect, because it blocks the Volley processing thread that it runs on, while it's waiting for the timeout. If we were to see an implementation of this in the library, it really should use asynchronous scheduling to get this job done.

Yep - as noted above: "It's not particularly efficient, but Volley already blocks on network requests rather than handle them asynchronously, so worst-case behavior is unchanged"

While Volley is good about exposing an async interface to clients, it's not the most efficient about actually doing things asynchronously under the covers, thanks to the network/cache dispatcher threads. The Network interface must either return the final response after all retries or throw an error, and this interface couldn't be changed without breaking Volley's public API or building an alternative entire asynchronous stack. I filed #181 to capture some thoughts there, but at the moment there are no plans to pursue this.

BTW - if the delays here are ~seconds long or longer, it would probably be more appropriate to use a higher-level abstraction to perform any retries, like JobScheduler or Firebase JobDispatcher.

OK. Thinking about it a little more, I'm hesitant to encourage the direction of blocking in retry() in the long term, as it would tie us more tightly to this synchronous network model. So I don't think I'd want to suggest that in the documentation, but as noted above, you can still do this in the mean time, and it will work as long as you're comfortable with one of the (limited) NetworkDispatcher threads being stalled during the sleep.

For 1.1.1 I'll thus update the documentation to explain the behavior so it's understood, without suggesting a block in retry().

I haven't fully thought this out, but we might be able to swing this in the current architecture by re-adding the failed request to the queue after the desired delay. We could use a main thread handler to post a delayed message. Since the retry policy is an object attached to the request, and there's no other context outside of the request in the current retry loop, this should roughly accomplish what we're after, although the request may end up being delayed more than the requested amount of time if other requests come in and fill the queue in the interim. An API change would still be required to specify the delay between retries, so that's not until at least 1.2.0.

Javadoc clarified. Moving to 1.2.0 milestone to investigate adding a new API to RetryPolicy to specify a delay time and seeing if we can either implement this in the current architecture or else fix it if/when we build an async alternative.