SpringBoot under file upload size problem solving

Today, do a file upload function do springboot environment, beginning when testing small files, no problem, but once the single file size exceeds 1M time, the background will be reported

org.springframework.web.multipart.MultipartException: Failed to parse multipart servlet request; nested exception is java.io.IOException: org.apache.tomcat.util.http.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Unexpected EOF read on the socket

My development environment is:

1.springboot 2.0.3.RELEASE

2.java version "1.8.0_151"

At first encountered this problem when I was forced to look ignorant, because could not find an exception is thrown out from, because there is no access to our controller layer, layer in the framework of springboot gave us stopped coming, and thrown out. In line to see someone else's solution, there is nothing more than the two factions, the first one: Since it is built tomcat upload file size limit set up single file upload size, then to modify the size by modifying tomcat configuration file; second: is modify the file size is achieved by Bean configuration. I tested, in fact, two programs in question are going to solve a specific environment, I do not happen in both scenarios, but the analysis, we first identified is springboot framework layer on file size to do the basic restrictions , then I try to modify this value on it, so my question on this exception by the turn into the springboot continue to modify the size of the uploaded file.

And next spring also provides us with a set of configuration, we just need to modify the value corresponding to

spring
  servlet:
    multipart:
      enabled: true
      max-file-size: 10M  #单个文件的最大上限
      max-request-size: 30M #单个请求的文件总大小上限

Hey, is for this configuration, I wasted nearly three hours. Finally resolved, but also learned to convert thinking.

Follow-up:

In a later test I found that even after I set the size, the problem still exists, this error is not every time, but slightly longer processing time when the error occurs. According to debug trace, I found the server reads the byte stream when suddenly began to read IO stream on the terminal, and eventually locate the problem in the client, the server process that is I read the file stream in the client initiative to close the connection.

First look at the front-end code:

A rear post submission form employed, started directly after the form is submitted through validate, then submitted after the closing of the current modal window. Code seemingly no problem, in fact, the problem is hidden in this humble place, sbumit submission default is asynchronous, and we had the will is submitted after save and close the window connection, and when the file is actually bigger when asynchronous submit the relative consumption when will a little bit longer, but this time close connection release method will be our main thread, resulting IO Exception Socket our client appear. we can improve methods subsequent closing operation on submit to submit callback processing

        var options = {
            //beforeSubmit: checkBefore,  
            success: handlerResult,      
            error: handlerError,
        };
		/**
		 * 	submit 提交成功结果处理
		 * */
        function handlerResult(responseText)  {
            if(responseText.code == 0){
                parent.location.reload();
                $.modal.close();
                $.modal.closeLoading();
			}else{
                $.modal.closeLoading();
                alert(responseText.msg);
			}
        }
        /**
         * 	submit 提交失败结果处理
         * */
        function handlerError(responseText){
            $.modal.closeLoading();
            $.alertError(" 网络连接超时，保存失败！请稍后重试")
		}
    $("#form-softwareVersion-add").validate({
            rules:{
                brandId:{
                    required:true
                },
                typeId:{
                    required:true
                },
                softwareId:{
                    required:true
                },
                name:{
                    required:true
                },
                version:{
                    required:true
                }
            },
            messages:{　　　　//验证错误信息
                brandId:{
                    required: '请输入品牌'
                },
                typeId:{
                    required: '请选择类型'
                },
                softwareId:{
                    required:  '请选在更新类型'
                },
                name:{
                    required: '请输入版本名'
                },
                version:{
                    required: '请输入版本号'
                }
            },
            submitHandler:function(form){
                $.modal.loading("保存中");
                $("#form-softwareVersion-add").ajaxSubmit(options);
            }
        });

The real solution to this problem, front-end technology still owe the furnace. Under Memorial again, come on!

 

A thousand miles begins with one step, read a lot, than ten thousand books!