排查与解决 java.io.EOFException: \n not found: limit=0 content=…

先去 GitHub - huaweicloud/huaweicloud-sdk-java-obs: The OBS SDK for Java, which is used for accessing Object Storage Service 找，没有发现相关 issue。

遇事不决就 Google， 发现 Okhttp 有相关的： java.io.EOFException: \n not found: limit=0 content=… · Issue #5390 · square/okhttp · GitHub 。然后看了一下 OBS SDK 浓眉大眼的，还真用的是 Okhttp。

Okhttp

OkHttpClient.retryOnConnectionFailure
public Builder() {
 ...
 retryOnConnectionFailure = true;
 ...
但是 OBS SDK 却在构建时设为 false，不明白为啥。builder.....retryOnConnectionFailure(false).....
 
如果看到这，相信也发现了 SDK 写死设置为 false 了，根本没有在外部配置的可能性。兜兜转转又回到了起点。
 
huaweicloud-sdk-java-obs
 
SDK 基本只靠 ObsConfiguration这个类对自己和 Okhttp Client 进行配置，可以说这就是一个唯一的入口：
 
@Bean
public ObsClient obsClient(HwCloudObsPropreties hwCloudObsPropreties) {
    ObsConfiguration obsConfiguration = new ObsConfiguration();
    obsConfiguration.setEndPoint(hwCloudObsPropreties.getEndPoint());
    obsConfiguration.setEndpointHttpPort(80);
    obsConfiguration.setEndpointHttpsPort(443);
    obsConfiguration.setConnectionTimeout(60000);
    obsConfiguration.setSocketTimeout(60000);
    obsConfiguration.setValidateCertificate(false);
    obsConfiguration.setUploadStreamRetryBufferSize(512);
    obsConfiguration.disableNio();
    return new ObsClient(hwCloudObsPropreties.getAccessKey(),hwCloudObsPropreties.getSecretKey(),obsConfiguration);
public class ObsConfiguration implements Cloneable {
    private int connectionTimeout = 60000;
    private int idleConnectionTime = 30000;
    private int maxIdleConnections = 1000;
    private int maxConnections = 1000;
    private int maxErrorRetry = 3;
    ......
很遗憾，它不支持 retryOnConnectionFailure，至少是目前使用的版本：3.1.3。
 
于是这里又剩了几条路
 
下源码，手动改，再重新打包，稍微麻烦一点。
在外层捕获异常，硬编码重试，不够优雅。
偏门方式：把连接池闲置连接存活时间idleConnectionTime 设置的小一些(因为不能为 0)，可以尽量小一些，但是担心太小，连接池的就没有意义了。频繁建立与销毁会带来性能损耗。
升级到新版，至少是 3.20.1 以后，但是整体兼容性未知。
 
关于第三点升级的方案，在 3.20.1 以后，扩展了huaweicloud-sdk-java-obs/ExtObsConfiguration.java 来继承 ObsConfiguration，增加了对retryOnConnectionFailure的支持。
 
public class ExtObsConfiguration extends ObsConfiguration {
    // 是否重试
    private boolean retryOnConnectionFailureInOkhttp;
    // times for retryOnRetryOnUnexpectedEndException;
    private int maxRetryOnUnexpectedEndException;
    public ExtObsConfiguration() {
        super();
        this.retryOnConnectionFailureInOkhttp = ExtObsConstraint.DEFAULT_RETRY_ON_CONNECTION_FAILURE_IN_OKHTTP;
        this.maxRetryOnUnexpectedEndException = ExtObsConstraint.DEFAULT_MAX_RETRY_ON_UNEXPECTED_END_EXCEPTION;
构建 client 时, 根据实际配置填入:
 
if (config instanceof ExtObsConfiguration) {
            // retry in okhttp
            obsProperties.setProperty(ExtObsConstraint.IS_RETRY_ON_CONNECTION_FAILURE_IN_OKHTTP,
                    String.valueOf(((ExtObsConfiguration) config).isRetryOnConnectionFailureInOkhttp()));
            // retry on unexpected end exception
            obsProperties.setProperty(ExtObsConstraint.HTTP_MAX_RETRY_ON_UNEXPECTED_END_EXCEPTION,
                    String.valueOf(((ExtObsConfiguration) config).getMaxRetryOnUnexpectedEndException()));
builder..retryOnConnectionFailure( obsProperties.getBoolProperty(ExtObsConstraint.IS_RETRY_ON_CONNECTION_FAILURE_IN_OKHTTP, false))
上述方法的前提都是，只有测试环境出现了问题，如果仅仅是一个环境就通过偏二方库的方式修改，影响太大；如果在应用层判断环境来处理，太麻烦，容易留坑。
 
服务器，柳暗花明又一村
 
因为只是一个环境出错，本地无法复现，那就只能在测试环境验证。但是任何代码修改都要经过各种流程才能上去，过于麻烦。
 
只好把视角转到环境与服务器上，期望能发现是服务器问题，仅通过修复特定服务器的配置来解决。
 
应用服务器
 
在开发环境和测试环境的服务器上，持续执行：netstat -an |grep 服务器IP
 
发现在请求 OBS 时，TCP 连接都是打开状态：
 
 
tcp6 0 0 172.160.0.132:56970 xxx.xxx.xxx.xxx:443 ESTABLISHED
 
但是请求完毕之后，开发环境会保持一段时间的打开状态，持续 30s 左右。
 
而测试环境的连接会直接进入 CLOSE_WAIT。如果这个时间触发调用，就会出现上述情况。
 
在问询了 DBA 之后，被告知 OBS 服务器只有一台，那我以为是应用服务器的配置不同，可能测试环境没开启 TCP Keepalive。
 
于是去找配置，然后啥也没有。
 
cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes
 
不论是哪个环境都没有找到相关配置，也没有找到其他可能性配置，可能和用的是容器有关。
 
那只能猜测应该都是开启的，把思路转向 OBS 服务器。
 
OBS 服务器
 
因为之前拉 TCP 连接状态，发现都是 OBS 服务器主动关闭。这里可能问题在 OBS 服务器。
 
对比了一下几个环境的配置，发现其他环境都是公网域名，如果在服务器上 ping 的话，都是局域网 IP。
 
而测试环境的直接就是一个局域网域名，猜测可能是代理服务器。
 
找了 DBA 确定并处理了这个问题，上述问题就解决了。
 
 
不用改代码是极好的。
 
所以总结一下上述流程发现的解决方案：
 
Okhttp
 
第二第三的方法有些人说不好使，具体看个人了。
 
设置 retryOnConnectionFailure(true)
set header("Connection","close")
set header("Accept-Encoding", "identity")
 
方案来源：
 
android - java.io.EOFException: \n not found, while reading from BufferedReader - Stack Overflow
java.io.EOFException: \n not found: limit=0 content=… · Issue #5390 · square/okhttp · GitHub
 
SDK 封装
 
如果是 SDK 封装了 Okhttp，没有更改入口的话：
 
自己拉源码改
看是否有可以升级的版本做支持：像文章中的 hwcloud SDK OBS 可以升级到 3.20.1 以后
上层捕获异常, 可能需要判断最深 cause 才能定位到异常. 之后进行重试(最不好用)
 
huaweicloud-sdk-java-obs/ExtObsConfiguration.java at c6bd01c1a57d4549d33c2d2396cd9ad33d17691c · huaweicloud/huaweicloud-sdk-java-obs · GitHub
 
服务器 or 应用
 
如果是自己的服务器或应用的话，可以支持一下 keepalive， 对齐一下连接池的存活时长和服务器或应用 keepalive 的时长。
 
 
当然，因为我没有直接接触到服务器端，所以可能思路给出来。具体解决方案可以自行研究，或者自行运维哦。
 
huaweicloud-sdk-java-obs/ExtObsConfiguration.java at c6bd01c1a57d4549d33c2d2396cd9ad33d17691c · huaweicloud/huaweicloud-sdk-java-obs · GitHub
android - java.io.EOFException: \n not found, while reading from BufferedReader - Stack Overflow
java.io.EOFException: \n not found: limit=0 content=… · Issue #5390 · square/okhttp · GitHub
TCP Keepalive HOWTO (zzyongx.github.io)
                    排查与解决java.io.EOFException: \n not found: limit=0 content=…问题起因是项目向华为云 OBS 请求视频， 偶现题目中的异常；如果等一段时间（30s），就可以正常读取到视频。原因是 OBS SDK 底层用的 Okhttp 连接池，而 Okhttp 的 GitHub 上也有相关 issue：服务器在返回数据后就直接关闭 TCP 连接，而客户端（项目应用）却将连接放入连接池重复使用；当下次请求复用时，连接已经被关闭，就读取不到返回值，报上述异常。
 将okhttp 3.14.2替换为okhttp 3.14.4。
 将log4j-core 2.12.0替换为log4j-core 2.13.2。
 将log4j-api 2.12.0替换为log4j-api 2.13.2。
 版本3.20.3的新功能：
 支持请求者付款。
 删除默认的log4j配置。
 版本3.20.1第三方依赖性：
 用okhttp 3.14.2替换okhttp 3.11.0。
 版本3.19.11的新功能：
 请求身份验证支持通过顺序搜索来获取访问密钥。
 支持下载请求。 如果返回状态代码302 Found，则不需要身份验证信息进行重定向。
 第三方依赖性：
 将log4j-core 2.8.2替换为log4j-core 2.12.0。
由于此问题不是必现，故不太好定位排查，根据关键异常信息：EOF一般指输入流达到末尾，无法继续从数据流中读取; 怀疑可能是由于双方（client<->server) 建立的连接，某一方主动close了，为了验证以上猜想，笔者查阅了相关资料，以及做了一些简单的代码实验
如何解决
Github Issue or google or stackoverflow?
根据@...
				
1、如果你没有使用OkHttpClient单例模式的话，而是每次都new 一个OkHttpClient 在大量的请求下，很容易就会出现OOM 因为OkHttpClient 每new 一个 就会创建一个线程池，线程池默认有5个线程，不断new 就会出现OOM
2、在使用OkHttpClient 单例模式的情况下，出现IOException和EOFException 类似如下：
java.io.IOException: unexpected end of stream on Connection{xxx, 
				
java.io.EOFException
EOFException：当输入过程中意外到达文件或流的末尾时，抛出此异常。
此异常主要被数据输入流用来表明到达流的末尾。注意，其他许多输入操作返回一个特殊值表示到达流的末尾，而不是抛出异常。
产生原因：
1、数据流中写入数据时的顺序和读取时的顺序不一致
2、UTF是双字节编码，而writeChars方法写入的是按照字符格式写入的，在文件中的占位要小于以Unicode编码的同样字符串，所以，使用readUTF方法读取时，会出现EOF错误
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.util.ArrayList;
public class ReadFromFile {
    public static ArrayList<Student> rea.
今天在用对象流反序列化文件时遇到一个特别无语的错误，EOFException，表示流异常到底文件末尾。
刚开始我一直觉得这个异常是程序错误导致的，后面才发现这个其实是正常的，
就像是字节流读到文件末尾返回-1一样，对象流不是返回值，而是直接抛出异常，
所以说这个异常并不是程序错误导致的，而是表示正常读到了文件末尾。
解决方法
解决方法也很简单，
直接catch 而不给打印出来就行了。
				
关于Okhttp的介绍以及牛逼之处笔者不进行科普了，不懂的自行戳http://blog.csdn.net/lmj623565791/article/details/47911083
在使用Okhttp的过程中频繁的发起Http请求时偶尔会看到如下的错误
ERROR [IOException]-[120]
    java.io.IOException: unexpected end of
如果你对象流不是很明白的，可以先看看The Java™ Tutorials——（2）Essential Classes——Basic I/O 之 7. 对象流（Object Streams）的讲述，链接中给出了一些程序例子，很容易理解。
这里描述的j...
					
hdfs的DataNode日志 发现了java.io.EOFException: Premature EOF: no length prefix available
				
EOFException是Java中的一种常见异常，表示在尝试读取文件或流时到达了文件或流的末尾（End of File）。 在HDFS中，DataNode负责维护HDFS文件系统的数据块，并在客户端请求时将这些数据块返回给客户端。
如果在DataNode日志中出现了java.io.EOFException: Premature EOF: no length prefix available，则表示在尝试读取数据块时遇到了文件的末尾，但是没有发现长度前缀。这可能是由于文件已损坏或损坏造成的。
建议检查数据块的完整性，并尝试重新下载或恢复这些数据块。如果问题仍然存在，则可能需要调查数据块的存储位置，以确定是否存在硬件故障或其他问题。