The temporary upload location [/tmp/tomcat.4296537

2020-05-22 00:16发布

问题:

I am using Spring Boot 1.5.13 version.

I got the exception message like below.

Could not parse multipart servlet request; nested exception is java.io.IOException: The temporary upload location [/tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] is not valid

I founded out this issue in Spring Github Issues. https://github.com/spring-projects/spring-boot/issues/9616

But I still have questions of that.

  1. I am not using File Upload things in my app. But the log says that "Could not parse multipart servlet request" why is that? (I got the exception when my app uses RestTemplate (Post method)
  2. To solve the exception, I rebooted my app but It did not work right away. Although i rebooted my app, it had referenced the tomcat directory which was not exist. After a day after rebooting, it worked. I guess the directory was cached in somewhere in Spring or else..?

Please Help me out!

回答1:

  1. The http POST methods will use these temp locations to store the post data.
  2. Some OSs like centOS will delete the temp dir frequently. So, even you set that location's permission, after some time that dir will be removed by the OS. And after you reboot, the temp dir will be different.

You can set the multipart location in application.yml:

spring:
  http:
    multipart:
      location: /data/upload_tmp

Update

As per comment by Vivek Sethi above property didn't work for me but the below one.

spring.servlet.multipart.location=/data/upload_tmp


回答2:

Just restart your application in the server. It is a bug between spring and tomcat servers. Once the application restarts it consume a temp directory in the server.



回答3:

We've had this problem since long too, I just wanted to eloborate some stuff relating to 2) in above accepted answer.

So, the problem here is that tomcat's temp folders suddenly "disappears" and not for "POSTs in general" as is claimed but for multipart requests specifically. Thus

spring.servlet.multipart.location/spring.http.multipart.location

is involved here. As @Frankstar said above, in recent spring-boot code this is fixed by "always creating the tmp-folder if it's not there", works too of course if you're running a super-fresh spring-boot.

You can, as suggested as in the accepted answer, point it to somewhere else other than /tmp and it will work fine (though, regarding cleanup you should perhaps have a read here https://github.com/spring-projects/spring-boot/issues/9983 - you are now reliant on spring-boots cleanup which, though, should work fine).

But why did the folder actually disappear? Further down @Hasan Sawan says that "It is a bug between spring and tomcat servers". But is it really..?

For us the solution was to configure this stuff. OSes such as CentOS will use (see for instance https://www.thegeekdiary.com/centos-rhel-7-how-tmpfiles-clean-up-tmp-or-var-tmp-replacement-of-tmpwatch)) systemd for cleaning up /tmp - and anything not accessed within 10 days will be cleaned by the default setting.

Thus on our redhat servers we solved this be editing

/usr/lib/tmpfiles.d/tmp.conf

adding a line like

X /tmp/tomcat.* 

to solve this issue. You can verify this too using

# SYSTEMD_LOG_TARGET=console SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-tmpfiles --clean 2>&1 | grep tomcat 

where you will see that these directories will now be ignored.

There is also this fix for systems whereas tmpwatch is used instead https://javahotfix.blogspot.com/2019/03/spring-boot-micro-services-tmptomcat.html

Note : the solutions mentioned above to "restart" or to just # mkdir /tmp/tomcat.... were simply not accepted where I work.



回答4:

This Issue was fixed a couple of days ago.
Spring Boot: 2.1.4 or 1.5.20

This version bump fixes an issue when the tmp dir was deleted
by the OS and the spring boot app tries to handle a multifile
upload.

Issue: https://github.com/spring-projects/spring-boot/issues/9616

https://github.com/MeiSign/Copy-Pasta/commit/1200fb353a48a3d0c92038dee7cced7cebf3acfe



回答5:

Question has already been answered, but maybe I can help someone out. I had this problem as well, but none of the suggested solutions worked for me.

We use Spring boot in combination with Zuul, which boiled down to the following:

  1. Stop the application
  2. Stop Zuul
  3. Remove tomcat related folders in the /tmp folder (this is where our tomcat folders were stored, might be different for others)
  4. Restart Zuul
  5. Restart the application

Simply restarting the application did not work for us, as it was pointing to a non-existing folder: the name was cached somewhere.

When using Zuul, the request go through Zuul first and throw exception there.



回答6:

In micro services architecture, problem can be due to Zuul timeout. I faced the same issue and tried everything above discussed but did not work. After I increased timeout with dfs-bulk-service.ribbon.ReadTimeout=90000 configuartion in Zuul properties, it worked fine. Here dfs-bulk-service is my micro service name configured with Zuul as api gateway.



回答7:

You maybe encode the form body of the POST request by Content-Type: multipart/form-data http header .

You should send a Content-Type: application/x-www-form-urlencoded POST



回答8:

What I did to solve the issue was to relaunch the application adding -java.tmp.dir=/path/to/application/temp/ and creating a /temp/ folder in my application folder.



回答9:

For me it was using the correct dependency (if using java/maven)

       <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.6</version>
        </dependency>


回答10:

It is recommended to specify custom directory path for temp storage through spring (or server) configuration.

But quick hack would be to create the mentioned directory and provide the read/write permissions as

mkdir -p /tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT

chmod 755 /tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT

tomcat.xxxxxxxxxxxx.xxxx - This will be different on each server. Use this directory name from your server error.