java - Android (Java) HttpURLConnection 静默重试 'read' 超时

Question

所以我使用 Google Volley 进行 HTTP 请求，它基本上使用 Java 的 HttpURLConnection。

根据我的测试，问题是这样的:
当 HttpURLConnection 上的“读取”超时到达时，将在关闭连接并抛出相关异常 (SocketTimeoutException) 之前执行静默重试。

注意:
- 我在使用 HTTP POST 请求时注意到这个错误。
-“读取”超时不同于“连接”超时。
- 如果“读取”超时(通过调用 connection.setReadTimeout(int) 设置)未设置 (0)，或设置为大于 connection.setConnectTimeout(int) ，不会出现这个错误。
- 这个问题已经讨论过，here例如，但我还没有找到任何令人满意的解决方案。
- 可以找到一个有点相关的问题 here ，但我不确定它是否相关(是吗？)

更多背景
我的应用程序用于付款，因此不重试请求至关重要(是的，我知道它可以由服务器处理，我希望我的客户端无论如何都是“正确的”)。

设置“读取”超时后，如果服务器连接已建立，但服务器在回答之前等待/ sleep /延迟响应“超时”时间(因此引发“读取”异常而不是“连接” ' 异常)，另一个(静默的)请求在引发该异常之前发送，导致 2 个类似的请求，这是 Not Acceptable 。

我在寻找什么样的解决方案？
好吧，一个可以很好地解决这个问题/错误的方法，就像修复解释的一样 here (但我再次重申，我认为这在这种情况下无关紧要)。
另外，我想保持原始流程不变，这意味着不要强制关闭连接或类似的东西。

我现在要做的是将“读取”超时设置为“连接”超时的两倍(它们同时开始计数)，以确保首先引发“连接”异常。我也会尝试在服务器端解决这个问题。问题是，这种“读取”超时是有原因的，而我当前的实现实际上只是忽略它，并且只处理“连接”超时。

编辑Volley 库的 RetryPolicy 对此问题没有影响，因为这是静默重试。我尽可能地深入图书馆内部。到处都是日志/断点，取消了重试的调用。我怎么知道这是 99.99% 的 HttpURLConnection 问题。

Answer 1

这个错误的决定是由开发者在 2006 年做出的。这是从 Java 角度解释整个情况的人的一段很好的引用:

"As you probably guessed by now it's a bug (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6382788). Not the retry mechanism, of course, that's just crap. The bug is that it also happens for a POST (which is by default not idempotent per HTTP RFC). But don't worry, Bill fixed that bug a long time ago. Bill fixed it by introducing a toggle. Bill learned about backward compatibility. Bill decided it's better to leave the toggle 'on' by default because that would make it bug-backward-compatible. Bill smiles. He can already see the faces of surprised developers around the globe running into this. Please don't be like Bill?"
Source

那么建议的解决方案是:

System.setProperty("sun.net.http.retryPost", "false")

但是我们不能在安卓上这样做!唯一剩下的解决方案是:

httpURLConnection.setChunkedStreamingMode(0);

Which seems to be working, but isn't very effective from a requesting-time perspektive.

编辑:我无法使用这个实现，所以我寻找了一个替代库。我发现 HttpUrlConnection 的实现使用了 OkHttp从 Android 4.4 开始。由于 OkHttp 是开源的，我可以搜索他们是否也有静默重试问题。是的，他们 had problems with it并于 2016 年 4 月修复。CommonsWare (一个真正的 android expert )解释说每个制造商都可以决定他们可以使用哪种实现。因此，肯定有很多设备可以对 POST 请求进行静默重试，作为开发人员，我们只能尝试一些变通办法。

我的解决方案是更改库

编辑 2:给你一个最终答案:You can now use OkHttp as the transport layer for Volley with minimal code.

Another helpful solution