The temporary upload location [/tmp/tomcat.4296537

Question

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!

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.