IOException：Stream ended unexpectedly

前阵子在使用spring cloud gateway的过程中，遇到图片上传出现异常：Processing of multipart/form-data request failed. Stream ended unexpectedly（流异常关闭）。

从异常信息可以看到，springMvc在处理multipart/form-data格式的请求中，使用了StandardServletMultipartResolver对请求进行解析并做数据转换，在转换数据的过程中，遇到了异常，在没有正常解析到预期数据的情况下，流读取已经完毕，因此抛了此异常。因此可以分析，有可能是服务在接收请求的过程中，数据有丢失的情况。

数据丢失排查

1、一般网关会有文件上传大小限制，排查网关文件大小限制的问题；
2、排查请求经过spring cloud gateway数据被修改；

文件大小限制

spring cloud gateway 官方示例配置：

spring:
  cloud:
    gateway:
      routes:
      - id: request_size_route
        uri: http://localhost:8080/upload
        predicates:
        - Path=/upload
        filters:
        - name: RequestSize
          args:
            maxSize: 5000000

当请求体超过限制被拒，RequestSize GatewayFilter 将设置响应状态为413 Payload Too Large并携带报头errorMessage。以下示例显示了这样的内容errorMessage：

errorMessage` : `Request size is larger than permissible limit. Request size is 6.0 MB where permissible limit is 5.0 MB

maxSize默认请求大小为：5 MB。
由于网关并没直接返回以上异常信息，所以排除是文件大小限制问题导致。

spring cloud gateway 修改了请求体？

2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Loggers.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] Increasing pending responses, now 1
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ COMPLETE
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Loggers.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] [HttpServer] Handler is being applied: org.springframework.http.server.reactive.ReactorHttpHandlerAdapter@7ffec058
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|DefaultPartBodyStreamStorageFactory.java|<init>|Temporary folder: /tmp/nio-file-upload
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|DefaultPartBodyStreamStorageFactory.java|<init>|Temporary folder: /tmp/nio-file-upload
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Loggers.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] Subscribing inbound receiver [pending: 1, cancelled:false, inboundDone: false]
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 16384B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 02 08 20 80 00 02 08 20 80 00 02 08 20 80 00 |... .... .... ..|
|00000010| 02 08 20 80 00 02 08 20 80 00 02 08 20 80 00 02 |.. .... .... ...|
|00000020| 61 16 20 81 33 cc e0 9c 0e 01 04 10 40 00 01 04 |a. .3.......@...|
|00000030| 10 40 00 01 04 10 40 00 01 04 10 40 00 01 04 10 |.@....@....@....|

|00003ff0| a0 60 d1 d4 c8 0f c6 7a 57 b1 57 fd 6e 70 f8 38 |.`.....zW.W.np.8|
+--------+-------------------------------------------------+----------------+
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 65536B
2020-09-04 16:26:19|[reactor-http-server-epoll-5]|Slf4JLogger.java|debug|[id: 0xd99e8e2b, L:/[网关] - R:/[客户端]] READ: 23669B

上面这段日志是客户端发起请求到netty接收后打印的debug日志，可以算出该包体的总字节数是：696,437B，与笔者上传的图片文件相差无几，其中除去请求体里其他的字符，应该跟图片大小一致。

2020-09-04 16:26:19|[reactor-http-client-epoll-13]|Slf4JLogger.java|debug|[id: 0x0cb9f380, L:/[网关] - R:[服务端]] FLUSH
2020-09-04 16:26:19|[reactor-http-client-epoll-13]|Loggers.java|debug|[id: 0x0cb9f380, L:/[网关] - R:[服务端]] Writing object
2020-09-04 16:26:19|[reactor-http-client-epoll-13]|Slf4JLogger.java|debug|[id: 0x0cb9f380, L:/[网关] - R:[服务端]] WRITE: 1212249B

而上面这段日志是netty转发业务层处理好的请求到【服务端】的日志，可以看到总包体字节总数为：1,212,249B，与客户提交的包体相差近1倍。因此可以断定，是因为请求体大小变化了，而请求头中Content-Length: 696161，并没有产生变化，从而导致【服务端】解析报文出错，进而出现IO异常，Stream ended unexpectedly。

笔者曾在这个基础上做过实验，在【网关】把头部的Content-Length移除，再设置请求头Transfer-Encoding: chunked，实现分块编码传输，最终【服务端】能正常接收【网关】的请求，没报IO异常，解析multipart/form-data也正常，只是保存的图片大小已经变成1.2M，与原始图片大小（679KB）相差很大，并且无法打开。

请求体经由gateway之后为什么发生变化

由上述debug日志可以看出，netty在接收后的请求是正常的，说明问题是在更上层的业务层发生的，因此笔者先断点到SCG（spring cloud gateway，后续使用此简称）的第一个全局filter

public class AdaptCachedBodyGlobalFilter implements GlobalFilter, Ordered {

	public static final String CACHED_REQUEST_BODY_KEY = "cachedRequestBody";

	@Override
	public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {

		Flux<DataBuffer> body = exchange.getAttributeOrDefault(CACHED_REQUEST_BODY_KEY, null);
		if (body != null) {
			ServerHttpRequestDecorator decorator = new ServerHttpRequestDecorator(exchange.getRequest()) {
				@Override
				public Flux<DataBuffer> getBody() {
					return body;
				}
			};
			return chain.filter(exchange.mutate().request(decorator).build());
		}

		return chain.filter(exchange);
	}

	@Override
	public int getOrder() {
		return Ordered.HIGHEST_PRECEDENCE + 1000;
	}
}

从断点中可以看到，此处从ServerWebExchange中获取"cachedRequestBody"（缓存的body），已经是被改变后的请求体了，所以问题还出现在更前面。顺着思路，我们查找设置"cachedRequestBody"的地方，还是依赖断点。

public class DefaultServerWebExchange implements ServerWebExchange {
    public Map<String, Object> getAttributes() {
        return this.attributes;
    }
}

我们找到了ServerWebExchange的实现类：DefaultServerWebExchange，通过断点getAttributes找到设置body的入口处。最后笔者在ReadBodyPredicateFactory中找到设置入口：

public AsyncPredicate<ServerWebExchange> applyAsync(Config config) {
		return exchange -> {
			Class inClass = config.getInClass();

			ServerRequest serverRequest = new DefaultServerRequest(exchange);
			// TODO: flux or mono
			Mono<?> modifiedBody = serverRequest.bodyToMono(inClass)
					// .log("modify_request_mono", Level.INFO)
					.flatMap(body -> {
						// TODO: migrate to async
						boolean test = config.predicate.test(body);
						exchange.getAttributes().put(TEST_ATTRIBUTE, test);
						return Mono.just(body);
					});

			BodyInserter bodyInserter = BodyInserters.fromPublisher(modifiedBody, inClass);
			CachedBodyOutputMessage outputMessage = new CachedBodyOutputMessage(exchange,
					exchange.getRequest().getHeaders());
			return bodyInserter.insert(outputMessage, new BodyInserterContext())
					// .log("modify_request", Level.INFO)
					.then(Mono.defer(() -> {
						boolean test = (Boolean) exchange.getAttributes()
								.getOrDefault(TEST_ATTRIBUTE, Boolean.FALSE);
						exchange.getAttributes().remove(TEST_ATTRIBUTE);
						exchange.getAttributes().put(CACHED_REQUEST_BODY_KEY,
								outputMessage.getBody());
						return Mono.just(test);
					}));
		};
	}

顺着断点往里走，最终在CharSequenceEncoder类中发现了问题的根源：

    public Flux<DataBuffer> encode(Publisher<? extends CharSequence> inputStream, DataBufferFactory bufferFactory, ResolvableType elementType, @Nullable MimeType mimeType, @Nullable Map<String, Object> hints) {
        Charset charset = this.getCharset(mimeType);
        return Flux.from(inputStream).map((charSequence) -> {
            CharBuffer charBuffer = CharBuffer.wrap(charSequence);
            ByteBuffer byteBuffer = charset.encode(charBuffer);
            return bufferFactory.wrap(byteBuffer);
        });
    }
    static {
        DEFAULT_CHARSET = StandardCharsets.UTF_8;
    }

看到这里，就已经可以明白问题是怎么发生的了，由于在用户在上传文件的时候，经过SCG，使用了默认编码UTF-8对请求体进行解码后缓存到ServerWebExchange，所以导致图片格式的文件，最终字节数变大原因。在此之前，笔者也做了实验，用UTF-8编码的txt文件上传则不会出现问题，另外也采用了ISO-8859-1作为编码格式对图片进行上传，也不会出现问题，到这里就结案了。

解决方法：
客户端在上传图片的时候，指定编码ISO-8859-1，完美解决问题。

Content-Type: multipart/form-data;charset=iso-8859-1; boundary=-------------------------acebdf13572468
User-Agent: Fiddler
Content-Length: 696149

结束语

笔者在遇到此问题的时候，第一时间还是到网上查找资料，但发现没有一篇文章跟我的情况一样，因此写此文章希望能帮到广大码友，特别是那些准备使用spring cloud gateway的朋友，提前可以了解到这个问题。

笔者近期也是听闻很多码友开始使用spring cloud构建微服务，之前有个朋友是做电商平台的，说他们正在搭建中台，而他们的做法，是在构建中台能力中引用外部的各种能力进行整合，从而快速实现自己的中台。
就比如他们做电商平台的，做了个快递中台，其中对接了快递100的查、寄的能力，短时间就搭建了功能齐全的快递业务中台，笔者觉得这种思路非常可取，后续也希望能学习一下，也快速构建自己中台。

几天前，我开始将壹個 新的 Libcloud 网站迁移到我们的 Apache SVN 网站资源库的工作。
在这次迁移中，我进行了壹堆提交到SVN资源库的操作，这些提交操作是由新增（增加源代码，并且为新的网站生成静态文件）和删除（删除旧网站上的源代码和数据）组成。
在某些时候，我已经更新了网站内容，并且重新生成了网站，并且想再次提交更新过的文件。

当这些更新和删除操作在传输的时候，所有的壹切看上去都很好，但是就在服务器准备响应所有这些更新时，我接收到了如下的错误信息：

Transmitting file data ............svn: Commit failed (details follow):
svn: Delta source ended unexpectedly

我以前从来没有接到过这种错误信息，但是我猜测这個问题可能与壹些怪异的壹致性问题有关系，在此之前我增加新的网站文件和删除旧文件的时候有看到过这种问题。

当时我是这麽做的，我在提交和之后壹個大的提交之间运行了几次 svn update，尽管我觉得这不应该，但是我从服务器端接收到了旧的更新，因为本地资源库应该拥有所有的更新内容，并且表现出壹個最新的状态。
其中壹個我执行的提交操作很庞大，包含了大量的更新内容，所以我立即猜测到这可能与Apache GEO 负载均衡的 SVN 配置和壹些奇怪的复制/不同步的问题有关系。我等了好几分钟，然后再次运行 svn update 命令，这次问题似乎被解决了，我接收到了所有的更新内容，这些内容在壹致性问题出现之前就已经存在于本地了。看上去，我要麽再次重定向到相同的 SVN 服务器，要麽把现在所有的变化完全复制到另一台服务器上（非常需要，我不能够100%肯定当前的复制是同步的还是不同步的）。
无论如何，现在回到最初的问题上去。

在我遇到这個错误信息的时候，我尝试了如下事情：
1、我检查了 svn status 的输出内容；
2、我尝试使用命令 svn update -r <rev> 检出壹個早期的版本；
3、我尝试了clean checkout （使用命令 svn co <repo url> clean-checkout）；
没有壹個方法是奏效的。

svn status 只显示已经存在的文件的更新状态（M），而且这种更新不包含增加的新文件，在我重新添加了更新过的文件之后（是的，这些文件并不包含.svn 目录），我尝试了上述的方法2和方法3，但是我仍然在提交的时候接收到了相同的错误信息。
在这种情况下，我彻底没撤了，而且我不想把这個问题报告给还不存在的ASF基础架构团队，所以我开始尝试用 Google 来找到问题的解决方案。最后我无功而返，但是至少有壹個共识就是这似乎是由壹种壹致性问题引起的，它发生在本地 checkout 出来的版本和远程资源库之间，就像我前面所猜测的那样。
为了找出到底是哪個文件或者文件夹引起的这個问题，我写了壹小段脚本，用于将所有的文件壹個接壹個的提交。
这样做对于项目成员们而言没有任何价值，甚至可能让他们不高兴，因为这样做会导致100多条提交记录，而且每条提交记录都会生成壹個发送给commits@ 邮件列表的通知邮件。

#!/bin/bash

FILES=$(svn status generated/ | awk '{print $2}')

for file in ${FILES}; do
    svn commit ${file} -m "Regenerate website."
done

在这些提交操作中，除了三個文件提交失败以外，其它的都提交成功了。对于这三個叛逆的文件，服务器端返回了壹個错误信息说，这些文件不属于资源库的壹部分。这就是壹致性问题，因为 svn status 显示这些文件已经被更新过，并且没有新的内容引入。

为了解决这個问题，我尝试移除了这些文件（svn rm），把它们再重新加回来（svn add）最后提交更新。

# backup to-be removed files (exclude .svn directories)
svn rm generated/blog/tags/dir1
svn rm generated/blog/tags/dir2
svn rm generated/blog/tags/dir3
# re-added changed files back
svn add generated/blog/tags/*
svn commit -m "Regenerate website."

这次的做法解决了问题，在文件传输的过程中我没有再接收到任何错误信息。

我仍然不是很确信到底是什么导致了这個问题，因为这些文件在本地和远端状态上有明显的不壹致，但是我仍然很高兴解决了这個问题，我不需要再处理 SVN 了。
2014年01月01日最后更新：Justin 确认了 Apache SVN 配置使用了异步的复制方式，这解释了我前面遇到的第壹個问题。他同样提到，为了避免发生类似问题，我可以在使用 svn relocate 的时候明确的选择只使用 master 工作的方式。

英文原文出处：http://www.tomaz.me/2014/01/01/resolving-delta-source-ended-unexpectedly-svn-issue.html ，中文译文首发开源中国社区 http://my.oschina.net/bairrfhoinn/blog/195733 ，转载请注明原始出处。

1、先用su - mqm进入mq用户，然后输入dspmq查看当前已经创建了的mq队列管理器

[root@db ~]# su - mqm
上一次登录：四 8月 12 16:22:11 CST 2021pts/0 上
-bash-4.2$ dspmq
QMNAME(T_QM_105)             STATUS(Ended unexpectedly)
QMNAME(T_QM_011)             STATUS(Ended unexpectedly)
-bash-4.2$ 

上面的T_QM_105_YTH_510000和T_QM_011_YTH_510000就是我系统里面现有的mq队列管理器。

2、使用dltmqm命令删除这些有问题的队列管理器。

-bash-4.2$ dltmqm T_QM_105
-bash-4.2$ dltmqm T_QM_011

3、新建队列管理器（将下列命令行逐个运行）

注：T表示测试；105表示银行编码（建行）；011表示财政厅；L表示本地队列；S表示传输队列；R表示远程队列
创建第一个队列管理器（模拟银行端）：
	创建队列管理器：crtmqm -q T_QM_105 
	#T_QM_105：队列管理器名称
	运行队列管理器：strmqm T_QM_105 
	打开运行管理器：runmqsc T_QM_105                                                    
	定义本地队列：DEFINE QLOCAL(T_L_105 ) share   #T_L_105：本地队列名称
	定义传输队列（建行传输到财政）：DEFINE QL(T_S_105_011 ) usage(xmitq) SHARE   #T_S_105_011：远程队列名称
    定义远程队列（建行到财政）：DEFINE QREMOTE(T_R_105_011 ) RNAME(T_L_011 ) RQMNAME(T_QM_011 ) XMITQ(T_S_105_011 ) REPLACE        
    #T_R_105_011：远程队列名称；T_L_011表示对端（财政）的本地队列；T_QM_011表示对端财政的队列管理器；T_S_105_011表示通过T_S_105_011传输队列进行传输。
    定义发送通道（建行发送到财政）：DEFINE CHANNEL(T_011 ) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('192.168.29.150(1515)') XMITQ(T_S_105_011 ) REPLACE
    # T_011发送通道名称；192.168.29.150(1515)对端的（财政）mq所在服务器的IP地址和监听的mq端口；T_S_105_011表示通过T_S_105_011传输队列进行传输。
    定义接受通道：DEFINE CHANNEL(T_105 ) CHLTYPE(RCVR) TRPTYPE(TCP) REPLACE
    #T_105表示创建一个名为T_105的接收通道
	定义服务器通道：define CHANNEL(DC.SVRCONN) chltype(SVRCONN) trptype(TCP) mcauser('mqm')
	#DC.SVRCONN表示服务器通道名称
	定义监听端口，以及监听名字：DEFINE LISTENER(T_QM105) TRPTYPE(TCP) CONTROL(QMGR) PORT(1414)
	#T_QM105监听名称；1414表示为T_QM_105队列管理器定义一个1414端口
	开启端口监听：start LISTENER(T_QM105)
	开启传输通道（财政）：start chl(T_011 )
    创建通道触发器（财政）：alter ql(T_S_105_011 ) TRIGDATA('T_011 ') TRIGTYPE(FIRST) TRIGGER initq('SYSTEM.CHANNEL.INITQ')
    关闭认证
	alter qmgr CHLAUTH(DISABLED)
	alter qmgr CONNAUTH('')
	refresh security type(CONNAUTH)

创建第二个队列管理器（模拟财政端）：
	创建队列管理器：crtmqm -q T_QM_011 
	运行队列管理器：strmqm T_QM_011 
	打开运行管理器：runmqsc T_QM_011 
	定义本地队列：DEFINE QLOCAL(T_L_011 ) share
	定义传输队列（建行）：DEFINE QL(T_S_011_105 ) usage(xmitq) SHARE
    定义远程队列（建行）：DEFINE QREMOTE(T_R_011_105 ) RNAME(T_L_105 ) RQMNAME(T_QM_105 ) XMITQ(T_S_011_105 ) REPLACE	
    定义发送通道（建行）：DEFINE CHANNEL(T_105 ) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('192.168.29.150(1414)') XMITQ(T_S_011_105 ) REPLACE
    定义接受通道：DEFINE CHANNEL(T_011 ) CHLTYPE(RCVR) TRPTYPE(TCP) REPLACE
	定义服务器通道：define CHANNEL(DC.SVRCONNT) chltype(SVRCONN) trptype(TCP) mcauser('mqm')
	定义监听端口，以及监听名字：DEFINE LISTENER(T_QM011) TRPTYPE(TCP) CONTROL(QMGR) PORT(1515)			
	开启端口监听：start LISTENER(T_QM011)
	开启传输通道（建行）：start chl(T_105 )
    创建通道触发器（建行）：alter ql(T_S_011_105 ) TRIGDATA('T_105 ') TRIGTYPE(FIRST) TRIGGER initq('SYSTEM.CHANNEL.INITQ')
    关闭认证
	alter qmgr CHLAUTH(DISABLED)
	alter qmgr CONNAUTH('')
	refresh security type(CONNAUTH)

4、测试（命令行方式）

-bash-4.2$ cd /opt/mqm/samp/bin  #切换到/opt/mqm/samp/bin目录
#测试发送消息（从银行端发送到财政端）
-bash-4.2$./amqsput T_R_105_011 T_QM_105  #./amqsput 银行端到财政端的远程队列名称 银行端的队列管理器名称
Sample AMQSPUT0 start
target queue is R_01_02
jianhang!!              #随便输入发送的内容，输入完测试内容后连续两次enter键退出并发送
Sample AMQSPUT0 end
#查看是否接收到消息（需要在财政端查看是否收到来自银行端的消息）
-bash-4.2$ ./amqsget T_L_011 T_QM_011    #./amqsget 财政端的本地队列 财政端的队列管理器
Sample AMQSGET0 start
message <jianhang!!>   #接收到的内容
no more messages
Sample AMQSGET0 end

反之也需要测试从财政端发送消息到银行端，看银行端能不能正常接收消息。