Местоположение временной загрузки [/tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] недопустимо - PullRequest
Новая
       24

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

0 голосов
/ 25 мая 2018

Я использую версию 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

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

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

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

Ответы [ 8 ]

0 голосов
/ 13 августа 2019

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

Вы должны отправить Тип содержимого: application / x-www-form-urlencoded POST

0 голосов
/ 19 апреля 2019

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

0 голосов
/ 26 июля 2019

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

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

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 .... просто не были приняты, где я работаю.

0 голосов
/ 07 марта 2019

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

0 голосов
/ 17 августа 2018

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

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

  1. Остановитеapplication
  2. Stop Zuul
  3. Удаление папок, связанных с tomcat, в папке / tmp (здесь хранятся наши папки tomcat, могут отличаться для других)
  4. Перезапустить Zuul
  5. Перезапустите приложение

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

Когдаиспользуя Zuul, запрос сначала проходит через Zuul и выдает там исключение.

0 голосов
/ 27 июля 2018

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

0 голосов
/ 26 июля 2018

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

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

Вы можете установить местоположение из нескольких частей в application.yml: 

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