web-dev-qa-db-fra.com

L'emplacement de téléchargement temporaire [/tmp/Tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] n'est pas valide.

J'utilise la version de Spring Boot 1.5.13.

J'ai le message d'exception comme ci-dessous.

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

J'ai découvert ce problème dans Spring Github Issues. https://github.com/spring-projects/spring-boot/issues/9616

Mais j'ai encore des questions à ce sujet.

  1. Je n'utilise pas d'objets de téléchargement de fichier dans mon application. Mais le journal indique que "Impossible d'analyser la demande de servlet en plusieurs parties", pourquoi? (J'ai eu l'exception lorsque mon application utilise RestTemplate (méthode Post)
  2. Pour résoudre l'exception, j'ai redémarré mon application mais cela n'a pas fonctionné tout de suite. Bien que j'ai redémarré mon application, celle-ci avait référencé le répertoire Tomcat qui n'existait pas. Après un jour après le redémarrage, cela a fonctionné. Je suppose que le répertoire a été mis en cache quelque part au printemps ou autre ..?

Sil te plait aide moi!

springspring-bootembedded-tomcat-8
17
Sooyoung Park
  1. Les méthodes http POST utiliseront ces emplacements temporaires pour stocker les données de publication.
  2. Certains OS, comme centOS, suppriment fréquemment le répertoire temporaire. SO même si vous définissez l'autorisation de cet emplacement, ce répertoire sera supprimé au bout d'un certain temps par le système d'exploitation. Après le redémarrage, le répertoire temporaire sera différent.

Vous pouvez définir l'emplacement multipart dans application.yml:

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

Redémarrez simplement votre application sur le serveur. C'est un bug entre les serveurs Spring et Tomcat. Une fois que l'application redémarre, elle consomme un répertoire temporaire sur le serveur.

8
Hasan Sawan

Ce problème a été résolu il y a quelques jours.
Botte à ressort: 2.1.4 ou 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.

Problème: https://github.com/spring-projects/spring-boot/issues/9616

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

1
Frankstar

On a déjà répondu à la question, mais je peux peut-être aider quelqu'un. J'ai eu ce problème aussi, mais aucune des solutions suggérées n'a fonctionné pour moi.

Nous utilisons Spring Boot en combinaison avec Zuul, qui se résumait comme suit:

  1. Arrête l'application
  2. Arrêtez Zuul
  3. Supprimez les dossiers liés à Tomcat dans le dossier/tmp (c'est là que nos dossiers Tomcat ont été stockés, ils peuvent être différents pour d'autres)
  4. Redémarrer Zuul
  5. Redémarrer l'application

Redémarrer simplement l'application ne fonctionnait pas pour nous, car il pointait vers un dossier inexistant: le nom était mis en cache quelque part.

Lors de l'utilisation de Zuul, la requête passe d'abord par Zuul et y jette une exception.

1
Edwin Lambregts

Vous pouvez peut-être encoder le corps du formulaire de la demande POST) par Content-Type: multipart/form-data en-tête http.

Vous devez envoyer un Content-Type: application/x-www-form-urlencoded POST

0
Green Lei

Cela fait aussi longtemps que nous avons ce problème, je voulais juste préciser quelques éléments relatifs à la réponse acceptée 2) ci-dessus.

Le problème ici est donc que les dossiers temporaires de Tomcat "disparaissent" soudainement et non pas pour les "POST en général" comme cela est prétendu, mais pour les demandes multiparties en particulier. Ainsi

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

est impliqué ici. Comme @Frankstar l'a dit plus haut, dans le dernier code print-boot, ceci est corrigé en "créant toujours le dossier tmp s'il n'y est pas", fonctionne aussi bien sûr si vous utilisez une botte de printemps super fraîche.

Vous pouvez, comme suggéré dans la réponse acceptée, le diriger vers un autre emplacement que/tmp et cela fonctionnera correctement (cependant, en ce qui concerne le nettoyage, vous devriez peut-être lire ici https://github.com/spring -projects/spring-boot/issues/998 - vous dépendez maintenant du nettoyage de spring-boots qui, cependant, devrait fonctionner correctement).

Mais pourquoi le dossier a-t-il réellement disparu? Plus bas @ Kasan Sawan dit que "c'est un bug entre les serveurs Spring et Tomcat". Mais est-ce vraiment ..?

Pour nous, la solution consistait à configurer ce matériel. Des OS tels que CentOS utiliseront (voir par exemple https://www.thegeekdiary.com/centos-rhel-7-how-tmpfiles-clean-up-tmp-or-var-tmp-replacement-of- tmpwatch )) systemd pour nettoyer/tmp - et tout élément non utilisé dans les 10 jours sera nettoyé par le paramètre par défaut.

Ainsi, sur nos serveurs redhat, nous avons résolu ce problème

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

ajouter une ligne comme

X /tmp/Tomcat.*

pour résoudre ce problème. Vous pouvez aussi le vérifier en utilisant

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

où vous verrez que ces répertoires seront maintenant ignorés.

Il existe également ce correctif pour les systèmes alors que tmpwatch est utilisé à la place https://javahotfix.blogspot.com/2019/03/spring-boot-micro-services-tmptomcat.html

Remarque: les solutions mentionnées ci-dessus pour "redémarrer" ou simplement # mkdir/tmp/Tomcat .... n'ont tout simplement pas été acceptées là où je travaille.

0
Ola Aronsson

Dans l'architecture des micro-services, le problème peut être dû au délai d'attente de Zuul. J'ai fait face au même problème et j'ai essayé tout ce qui a été mentionné ci-dessus, mais cela n'a pas fonctionné. Après avoir augmenté le délai d'attente avec dfs-bulk-service.ribbon.ReadTimeout = 90000 configuartion dans les propriétés Zuul, cela a bien fonctionné. Ici, dfs-bulk-service est le nom de mon micro-service configuré avec Zuul en tant que passerelle api.

0
Rajdeep

Ayant le même problème sur mon application, ce que j'ai fait pour résoudre le problème a été de relancer l'application en ajoutant -Java.tmp.dir =/chemin/à/application/temp/et en créant un dossier/temp/dans mon dossier d'application.

0
user3450862