Android（Java）HttpURLConnection“读取”超时静默重试
因此，我使用Google Volley来处理HTTP请求，它基本上使用Java的HTTPurlConnection。
当设置了“读”超时，如果服务器连接已经建立，但服务器在应答之前等待/Hibernate/延迟响应“超时”时间（因此引发“读”异常而不是“连接”异常），则在引发该异常之前发送另一个（静默）请求，导致两个类似的请求，这是不可接受的。
我在寻找什么样的解决方案？
好吧，一个可以很好地解决这个问题/bug的解决方案，就像这里解释的修复一样（但我再次认为这在这种情况下是不相关的）。
还有，我希望保持原始流的原样，这意味着不要强迫连接关闭或类似的事情。
我现在要做的是将“读取”超时设置为“连接”超时的两倍（它们同时开始计数），以确保首先引发“连接”异常。我还将尝试在服务器端克服这个问题。问题是，这个“读取”超时是有原因的，而我当前的实现实际上只是忽略它，只处理“连接”超时。
编辑volley库的RetryPolicy对此问题没有影响，因为这是静默重试。我尽可能地往图书馆里看。到处都是日志/断点，取消了重试调用。我怎么知道这99.99%是httpurlconnection问题。
共有1个答案
这个糟糕的决定是由一个开发商在2006年做出的。下面是某人的一个很好的引文，它从java的角度解释了整个情况：
“现在您可能已经猜到这是一个bug(http://bugs.java.com/bugdatabase/view_bug.do？bug_id=6382788)。不是重试机制，当然，那只是废话。bug是对于POST也会发生这种情况（默认情况下，对于HTTP RFC来说，POST不是幂等的）。不过别担心，比尔很久以前就修复了那个bug。比尔通过引入一个拨动把它修好了。比尔了解了向后兼容性。Bill决定最好在默认情况下让切换“打开”，因为这将使它与bug向后兼容。比尔笑了。他已经可以看到全球范围内惊讶的开发人员的脸。请不要像比尔？“
来源
建议的解决方案是：
System.setProperty("sun.net.http.retryPost", "false")
httpURLConnection.setChunkedStreamingMode(0);
编辑2：给您一个最终的答案：您现在可以使用OkHttp作为Volley的传输层，只需最少的代码。
另一个有用的解决办法
-
问题内容： 所以我正在使用HTTP请求，该请求基本上使用的。 根据我的测试， 问题是这样的 ： 当到达“读取”超时时，在关闭连接并引发相关异常之前将执行静默重试。 请注意 ： -使用请求时，我注意到此错误。 -“读取”超时与“连接”超时不同。 -如果未设置“读取”超时（通过调用设置）（设置为0），或者未将其设置为大于的值，则不会发生此错误。 - 例如，这里已经讨论了这个问题，但是我没有找到令人满意
-
问题内容： 我似乎有时会遇到一些tcp请求被“卡住”的麻烦，就像它正在等待一些响应，但连接已被“切断”，因此响应永远不会到来。这是具有默认超时的HttpURLConnection的预期行为吗？是否设置了明智的默认设置，以便默认情况下我无法进入这种奇怪的“挂起”情况？ 问题答案： 出现HttpURLConnection的“默认”超时为零，表示“无超时”。 不幸的是，根据我的经验，根据您与服务器的连接
-
我需要知道如何读取（同步或异步不重要）与超时。我想检查一个设备是否与串行端口连接。 为此，我使用，然后等待设备的响应。 如果连接了设备工作正常，但如果没有设备，程序就会停止，这就是我需要超时的原因
-
问题内容： 这是一个基于客户端/服务器的简单ping / pong程序。不幸的是，IT无法正常工作并显示以下错误消息： 它停止在CLIENT TASK 30行，实际上，客户端不读取服务器已发送的内容。这里的代码： 服务器 服务器任务 客户 客户任务 问题答案： 问题出在循环内部的使用与从连接另一端处理套接字的方式之间的交互。 仅当从其读取的流结束时才返回-1，这在本质上将意味着套接字已关闭。在关闭
-
我返回了一个代码，使用jsoup-1.7.3.jar读取网页，它对一些网站有效，但对一些URL显示读取超时错误。 线程“main”java.net.SocketTimeoutException中的异常：java.net.SocketInputStream.socketRead0（本机方法）处java.net.SocketInputStream.Read（SocketInputStream.java