Ajax + Spring MVC上传文件失败的问题的排查解决方案
最近在做一个文件上传需求,发现当上传文件大于60M时,前端ajax文件上传后,服务请求不到服务端。
排查过程:
第一步,页面请求返回NS_BINDING_ABORTED,先查了下Nginx日志,Nginx 400 Bad Request 猜测是因为客户端Post请求Packet在网络传输过程中部分丢失导致到服务端无法正常响应,客户端10s超时断开连接,这时候nginx记录了400。这种情况下,nginx实际未反馈400的response,只是在连接断开时记录了400的日志。
于是排查前端代码如下:前端在上传文件请求后,设置10S的请求超时时间,初步猜测是上传文件较大,前端请求包还没有发送完毕就中断请求了,于是把timeout时间设置加大,增加到20秒,发现60多M的文件上传成功。
1 $.ajax({ 2 url: '/upload_url', 3 type: 'post', 4 data: data, 5 timeout: 10000, // 超时 6 cache: false, 7 processData: false, 8 contentType: false, 9 success: function(json) { 10 ....... 11 } 12 }, 13 error: function() { 14 15 }, 16 complete: function(XMLHttpRequest, status) { 17 if (status === 'timeout') { 18 // 超时直接提示 19 // '上传时间较长,请稍后查看结果', 20 }); 21 } 22 } 23 })
第二步,测试上传文件大于100M时的情况,发现服务端不会接收到请求,加大了超时时间也没有任何效果,排查Nginx配置上传文件大小限制是300M,即 client_max_body_size 300m。
并且发现Nginx如下日志:
。。。。。。。。。。。a client request body is buffered to a temporary file /dev/。。。。。。。/client_body/XXXXXXX, client
。。。。。。。。。。。pwrite() "/dev/。。。。。。。/client_body/XXXXXXX" failed (28: No space left on device), client
所以,优化nginx配置,client_max_body_size 300m; client_body_buffer_size 300m; 加大上传缓存Buffer size文件,reload nginx生效。
ps :
client_max_body_size
此指令设置NGINX能处理的最大请求主体大小。 如果请求大于指定的大小,则NGINX发回HTTP 413(Request Entity too large)错误。 如果服务器处理大文件上传,则该指令非常重要。
client_body_buffer_size
此指令设置用于请求主体的缓冲区大小。 如果主体超过缓冲区大小,则完整主体或其一部分将写入临时文件。 如果NGINX配置为使用文件而不是内存缓冲区,则该指令会被忽略。 默认情况下,该指令为32位系统设置一个8k缓冲区,为64位系统设置一个16k缓冲区。 该指令在NGINX配置的http,server和location区块使用。
第三步,继续测试100M以上的文件,仍然不成功,浏览器前端请求结果返回 net::ERR_INCOMPLETE_CHUNKED_ENCODING,于是排查nginx日志如下:
。。。。。。。。。 错误日志全部是104: Connection reset by peer) while reading upstream
等待远程TCP接收到连接中断请求的确认
。于是分析nginx配置,nginx作为反向代理既然是客户端又是服务端,当和后端服务建立连接时并没有默认开启长连接,开启长连接后性能应该会提升很多,于是优化nginx配置开启nginx长链接【说明:(从client到nginx的连接是长连接,对于客户端来说,nginx长连接是默认开启的。从nginx到server的连接是长连接,需要自己开启】。proxy_send_timeout 200;
proxy_read_timeout 300;
proxy_http_version 1.1; ##开启后端,长连接
proxy_set_header Connection ""; ##开启后端,长连接
org.springframework.web.multipart.commons.CommonsMultipartResolver.parseRequest(CommonsMultipartResolver.java:162)
org.springframework.web.multipart.commons.CommonsMultipartResolver.resolveMultipart(CommonsMultipartResolver.java:142)
org.springframework.web.servlet.DispatcherServlet.checkMultipart(DispatcherServlet.java:1099)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:932)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
<property name="maxUploadSize" value="314572800" /> <!--300M-->
<property name="maxInMemorySize" value="314572800" /> <!--300M 设置multipart请求所允许的最大大小,默认不限制 -->
<property name="defaultEncoding" value="UTF-8"></property> <!-- 设置一个大小,multipart请求小于这个大小时会存到内存中,大于这个内存会存到硬盘中 -->
</bean>
1、Nginx 400 Bad Request
一般导致400异常的场景:
(1)请求头过大(2)空请求
(3)URLConnection发起HTTPS请求经过代理400异常
(4)网络传输丢包导致的400异常
2、Nginx 499 / ClientClosed Request
upstream在以下几种情况下会返回499:
(1)upstream 在收到读写事件处理之前时,会检查连接是否可用:
ngx_http_upstream_check_broken_connection,
if (c->error) { //connecttion错误
……
if (!u->cacheable) { //upstream的cacheable为false,这个值跟http_cache模块的设置有关。指示内容是否缓存。
ngx_http_upstream_finalize_request(r, u, NGX_HTTP_CLIENT_CLOSED_REQUEST);
}
}
如上代码,当连接错误时会返回499。
(2)server处理请求未结束,而client提前关闭了连接,此时也会返回499。
(3)在一个upstream出错,执行next_upstream时也会判断连接是否可用,不可用则返回499。
总之,这个错误的比例升高可能表明服务器upstream处理过慢,导致用户提前关闭连接。而正常情况下有一个小比例是正常的。