Временное местоположение загрузки [/tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] недействительно

Я использую версию Spring Boot 1.5.13.

Я получил сообщение об исключении, как показано ниже.

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

Я обнаружил эту проблему в Spring Github Issues. https://github.com/spring-projects/spring-boot/issues/9616

Но у меня все еще есть вопросы об этом.

Я не использую вещи загрузки файлов в моем приложении. Но в журнале написано, что "Не удалось разобрать многочастный запрос сервлета", почему это так? (Я получил исключение, когда мое приложение использует RestTemplate (метод Post)
Чтобы устранить исключение, я перезагрузил свое приложение, но оно не сработало сразу. Хотя я перезагрузил свое приложение, оно ссылалось на каталог tomcat, которого не было. Через день после перезагрузки все заработало. Я думаю, что каталог был кэширован где-то spring или еще..?

Пожалуйста, помогите мне!

Ответ 1

Методы http POST будут использовать это временное местоположение для хранения данных сообщения.
Некоторые ОС, такие как centOS, часто удаляют временный каталог. SO даже если вы установили это разрешение местоположения, через некоторое время этот каталог будет удален ОС. После перезагрузки временный каталог будет отличаться.

Вы можете установить многостраничное местоположение в application.yml:

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

Ответ 2

Просто перезапустите приложение на сервере. Это ошибка между серверами Spring и tomcat. После перезапуска приложения он использует временный каталог на сервере.

Ответ 3

Эта проблема была исправлена пару дней назад.
Spring Boot: 2.1.4 или 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.

Проблема: https://github.com/spring-projects/spring-boot/issues/9616

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

Ответ 4

На вопрос уже ответили, но, возможно, я могу кому-нибудь помочь. У меня тоже была эта проблема, но ни одно из предложенных решений не помогло мне.

Мы используем Spring boot в сочетании с Zuul, который сводился к следующему:

Остановить приложение
Стоп Зуул
Удалите связанные с tomcat папки в папке /tmp (это место, где хранились наши папки tomcat, может отличаться для других)
Перезапустите Зуул
Перезапустите приложение

Простой перезапуск приложения у нас не сработал, так как указывал на несуществующую папку: имя где-то кешировалось.

При использовании Zuul запрос сначала проходит через Zuul и выдает там исключение.

Ответ 5

У нас уже давно была эта проблема, я просто хотел высказать некоторые вещи, относящиеся к 2) в принятом выше ответе.

Итак, проблема здесь в том, что временные папки tomcat внезапно "исчезают", и не для "POST вообще", как утверждается, а именно для составных запросов. Таким образом

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

участвует здесь. Как сказал выше @Frankstar, в недавнем весеннем загрузочном коде это исправлено "всегда создавая tmp-папку, если ее там нет", это тоже работает, конечно, если вы используете супер-свежую весеннюю загрузку.

Вы можете, как предложено в принятом ответе, указать его где-то еще, кроме /tmp, и он будет работать нормально (хотя, что касается очистки, вам, возможно, следует прочитать здесь https://github.com/spring-projects/spring-boot/issues/9983 - теперь вы зависите от очистки весенних сапог что, впрочем, должно работать нормально).

Но почему папка действительно исчезла? Далее Хасан Саван говорит, что "это ошибка между серверами Spring и Tomcat". Но так ли это?..

Для нас решением было настроить этот материал. Операционные системы, такие как CentOS, будут использовать (см., Например, https://www.thegeekdiary.com/centos-rhel-7-how-tmpfiles-clean-up-tmp-or-var-tmp-replacement-of-tmpwatch)) systemd для очистки /tmp - и все, к чему не было доступа в течение 10 дней, будет очищено по умолчанию.

Таким образом, на наших серверах redhat мы решили это редактировать

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

добавление строки типа

X /tmp/tomcat.*

чтобы решить эту проблему. Вы также можете проверить это с помощью

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

где вы увидите, что эти каталоги теперь будут игнорироваться.

Это также исправлено для систем, тогда как вместо них используется tmpwatch https://javahotfix.blogspot.com/2019/03/spring-boot-micro-services-tmptomcat.html

Примечание: решения, упомянутые выше для "перезапуска" или просто # mkdir/tmp/tomcat.... просто не были приняты там, где я работаю.

Ответ 6

Я решил перезапустить приложение, добавив -java.tmp.dir=/path/to/application/temp/ и создав папку /temp/ в папке своего приложения.

Ответ 7

В архитектуре микросервисов проблема может быть связана с таймаутом Zuul. Я столкнулся с той же самой проблемой и попробовал все выше обсужденное, но не работало. После того, как я увеличил время ожидания с помощью конфигурации dfs-bulk-service.ribbon.ReadTimeout = 90000 в свойствах Zuul, все заработало нормально. Здесь dfs-bulk-service - это мое имя микросервиса, настроенное с использованием Zuul в качестве шлюза API.

Ответ 8

Вы можете закодировать тело формы запроса POST с помощью Content-Type: multipart/form-data Заголовок http.

Вы должны отправить Content-Type: application/x-www-form-urlencoded POST