Comments (6)
If it's mounted on the host, then the host can clean it up I guess? What is the maximum capacity? It should only be limited by the size of the physical disk it is on, right? Do you have any concrete data / samples that actually display this problem? I can't think why a Spring Boot app, in general, would be writing a lot of data to /tmp. I think it might be used by Tomcat in a small way, but nothing that would grow continuously AFAIK.
from gs-spring-boot-docker.
I was just wondering because we use multipart file uploads and AFAIK tomcat or the servlet engine used by spring boot stores these files in the temp directory. Since we are running the spring boot containers on a managed platform (previously Pivotal Web Service, currently AWS Fargate) I have neither influence on the physical size of that directory nor can I IMHO rely on the host cleaning this directory up.
from gs-spring-boot-docker.
I doubt if it's a very common issue - we've been running Spring Boot in containers in CloudFoundry for literally years and no-one brought this up before. Maybe long-running apps with file uploads is an uncommon use case. The best I can say is - you probably need to restart the container to be sure (not the app, the container). I know some OSes have services that clean up tmp dirs (Fedora for sure), so maybe those would be something you could add to your container.
from gs-spring-boot-docker.
@rreitmann To be clear, multipart uploads are piped to the application's running directory, not /tmp
. (Unless you explicitly store them in /tmp
).
Being inside a container implies you're in a cloud native world, which means if you're managing local files, you really need to own that task.
Given that Tomcat explicitly needs a /tmp
folder to run, and since you don't appear to leveraging a cloud friendly mechanism like S3, I'd pick some subfolder to host all your files. And implement some form of "reaping" mechanism up front, e.g. any file more than 48 hours old is deleted or archived elsewhere. Something.
You cannot depend upon Tomcat starting/stopping to handle it, nor the container itself. You could run into unpredicted optimizations. So periodically clean things out.
BTW, if you run 2+ instances of your application, you now have ANOTHER problem.
If this is starting to sound complex, welcome to the problem of storing your own files in the cloud. And the reason S3 (or GridFS) has become very popular.
from gs-spring-boot-docker.
@gregturn Thanks for the clarification regarding multipart uploads. We do use MongoDB's GridFS for almost all files we create and we clean up GridFS ourselves. However there is one case in which we store an uploaded file by transferring it to a temp file created with Files.createTempFile
for further processing. I will refactor this part.
However I still think that spring boot or tomcat should clean up the files they create in tmp
when running in a container.
from gs-spring-boot-docker.
AFAIK Spring Boot does not create files in /tmp. Tomcat only does if you use certain features (JSP maybe?). And we donβt expect those to be especially leaky. If you want to pursue that though, please open an issue in Spring Boot.
from gs-spring-boot-docker.
Related Issues (20)
- Failed jar extraction on command
- Remove references to deprecated boot2docker
- Different java versions in pom and docker
- https://spring.io/guides/gs/spring-boot-docker/ gives 404 HOT 1
- Spring-boot HOT 1
- Invalid or corrupt jarfile /application.jar
- Process 'command 'docker'' finished with non-zero exit value 2 HOT 1
- Improve the note regarding the external volume for /tmp in the Dockerfile HOT 4
- Add a note about the effect on classpath ordering of exploding the jar
- s
- COPY failed: stat /var/lib/... no such file or directory HOT 1
- How to achieve Key Vault feature in azure-keyvault-secrets-spring-boot by deploying in appservice as a docker image HOT 1
- docker --build-args vs --build-arg HOT 1
- az acr login && mvn compile jib:build fails with I/O error for image HOT 2
- Update this guide with Boot 2.3 features HOT 5
- Update Guide For zsh users(gradle dockerizing not working)
- zsh: no matches found: JAR_FILE=build/libs/*.jar
- Documentation improvement regarding image building options
- documentation - README.adoc
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gs-spring-boot-docker.