5

When I am on a slow connection and making a POST request, Volley retries my request multiple times and after it all ends up hitting my errorListener. Sometimes, these retries actually succeeded in posting data.

The user will assume that the request failed, but in truth, if they refreshed the data they'd see the data was POSTed twice to the server (or however many successful retries in the bunch).

I want give Volley a very dumbed-down retry policy:

I want it to try a request for 15 seconds and if the request doesn't reach the server within 15 seconds and comes back with a response to trigger the errorListener. I don't want it to retry at all.

The only concern is if Volley tries, the request gets to the server within 20~25 seconds, but by then it triggered the errorListener and the data still got POSTed.

Does HTTP follow a time-limit after which it is 100% the data won't get posted because the request took too long? Like maybe 40 seconds? If such, then I can have the request go on for 40 seconds.

In all:

No retries and ensure 100% that if data got posted on first try go to successListener and if it didn't get posted (request died due to taking too long or error response from server) errorListener.

I was thinking of doing something with the defaultRetryPolicy... like DefaultRetryPolicy(15000, 0, 1), though I think the last parameter doesn't matter because what is the point of back-off with no retries.

How would I achieve what I asked two paragraphs back?

David
  • 7,028
  • 10
  • 48
  • 95
  • I'm guessing you're getting a TimeOutError when the error listener gets hit? – Submersed Feb 11 '15 at 15:30
  • Yes. Reading the source code, the only error Volley would throw is Timeout in that regard. – David Feb 11 '15 at 20:31
  • It seems as though `DefaultRetryPolicy retryPolicy = new DefaultRetryPolicy(0, DefaultRetryPolicy.DEFAULT_MAX_RETRIES, DefaultRetryPolicy.DEFAULT_BACKOFF_MULT);` works but... that seems more like a bug, than not. – David Feb 11 '15 at 20:43
  • Adding 0 just causes the URLConnection to do a blocking connect, so basically by providing 0 is like providing a large number for the timeout interval. – Submersed Feb 11 '15 at 21:13
  • @Submersed by that do you mean that by providing 0, I'm basically letting the connection run its course all the way until it possibly fails? If it does fail, would it still trigger a retry? – David Feb 11 '15 at 21:15
  • If it fails it would retry since you're still passing in default retry count, i.e. 1 retry. If you're interested in seeing how passing 0 affects the socket timeout, I think this post explains it pretty well. http://stackoverflow.com/questions/4969760/set-timeout-for-socket – Submersed Feb 11 '15 at 21:39
  • Ah, I see. I assume the Android platform though stop the connection at some point... at which the connection would return and do whatever it does after, which in this case would be 1 try. So, it might be best to just have `new DefaultRetryPolicy(0, 0, 0)`. – David Feb 11 '15 at 21:44
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/70740/discussion-between-submersed-and-david). – Submersed Feb 11 '15 at 21:45
  • 2
    You might want to look into making your API idempotent. Note that even if you disable retries from the Volley request policy, `HttpUrlConnection` itself performs retries. There is no way to disable it either, although it's a bug as it goes against the standard. You should probably shift to Apache's client if you wish to avoid retries, as that provides the correct retry semantics. As for the timeout for request processing, you can implement that in your server if you wish, but note that the response might still time out so it won't solve the issue. – corsair992 Feb 12 '15 at 02:30
  • Interesting. Odd that such a bug would exist for what seems like a long time. – David Feb 12 '15 at 02:35
  • 1
    The bug was [reported](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6382788) to Sun way back in 2006, but they decided to preserve backward-compatibility while providing a system property to change the behavior on only their JVM (not in the JDK itself). – corsair992 Feb 12 '15 at 02:38
  • I see. I think for a quick fix, I'll simply use `DefaultRetryPolicy(0, 0, 0)` and see how that goes. – David Feb 12 '15 at 02:48
  • 1
    @David how did you solve this in the end? – AndroidEnthusiast Jun 16 '16 at 13:37

0 Answers0