Query- Why MarkerLogs show much different millisecond values than specified timeouts.

[gupta-sachin]

Below are some sample logs. Here specified timeouts are 5, 10, 20, 40 ms but as per marker logs, the attempts of request took 35, 27, 44, 301 ms respectively.

09-24 17:37:33.039 15137-15137 D/Volley: [1] MarkerLog.finish: (+0   ) [ 1] add-to-queue
09-24 17:37:33.040 15137-15137 D/Volley: [1] MarkerLog.finish: (+0   ) [2300] network-queue-take
09-24 17:37:33.042 15137-15137 D/Volley: [1] MarkerLog.finish: (+35  ) [2300] socket-retry [timeout=5]
09-24 17:37:33.042 15137-15137 D/Volley: [1] MarkerLog.finish: (+27  ) [2300] socket-retry [timeout=10]
09-24 17:37:33.045 15137-15137 D/Volley: [1] MarkerLog.finish: (+44  ) [2300] socket-retry [timeout=20]
09-24 17:37:33.045 15137-15137 D/Volley: [1] MarkerLog.finish: (+301 ) [2300] network-http-complete
09-24 17:37:33.046 15137-15137 D/Volley: [1] MarkerLog.finish: (+1   ) [2300] network-parse-complete
09-24 17:37:33.046 15137-15137 D/Volley: [1] MarkerLog.finish: (+0   ) [2300] network-cache-written
09-24 17:37:33.046 15137-15137 D/Volley: [1] MarkerLog.finish: (+0   ) [2300] post-response
09-24 17:37:33.046 15137-15137 D/Volley: [1] MarkerLog.finish: (+1   ) [ 1] done

[jpd236]

The timeout values provided in the retry policy are passed to the HttpStack, and it is up to the stack to decide how to interpret / use timeouts. For example, HurlStack uses the value as the connect and read timeouts on the underlying HttpURLConnection:

https://github.com/google/volley/blob/master/src/main/java/com/android/volley/toolbox/HurlStack.java#L210

Without knowing much about the internals of HttpURLConnection, it seems plausible that the socket could successfully connect and begin returning bytes within some timeout while still taking longer to actually read the full response over the wire.

There might be a use case for specifying a global request timeout that applies across the full operation, which is probably closer to how you're thinking about the timeout, but that would be challenging to implement with Volley's current blocking architecture. It might be more feasible when Volley becomes asynchronous (see #181).