What this is about
Files can be large, and large files cost memory, network and time. Size matters in three places: when uploading, when downloading and in the file storage.
The limits at a glance
| Where | Limit | Configurable? |
|---|---|---|
| one file (multipart or Base64) | 25 MB | yes, spring.servlet.multipart.max-file-size |
| all files of a request | 500 MB | yes, spring.servlet.multipart.max-request-size |
| parts of a multipart request | 500 | yes, server.tomcat.max-part-count |
| download | whole file in memory, per running download | – |
| file size overall | 2 GiB, because fileSize is an integer up to 2³¹−1 | no |
| file storage per tenant | no quota | – |
The values are chosen so that an operation can send all of its files in one request, for example an inspection with 100 photos of 5 MB each. A request is stored completely or not at all. Files uploaded one by one could be left half-distributed after an interruption.
For Base64, the size of the file counts, not that of the text. CDMS works it out from the length of the text before decoding anything. All Base64 files of a request together may be at most as large as the request limit.
What happens with a file that is too large
| What is too large? | Way | Answer |
|---|---|---|
| nothing | all | is stored |
| one file | multipart or Base64 | 413 file-too-large|<bytes> |
| all files together | multipart or Base64 | 413 request-too-large|<bytes> |
| the number of parts | multipart | 413 too-many-parts|<count> |
The number after the | is the limit: in bytes for files and requests, as a count for parts. So file-too-large|26214400 means “at most 25 MB per file”. In each of these cases nothing is stored. Repeating the request unchanged fails the same way.
If the server cannot name a limit, the answer is 413 upload-too-large.
Configuring the limits
CDMS brings the defaults itself. If your application sets one of the values, its own applies. In the application.yaml:
spring:
servlet:
multipart:
max-file-size: 50MB
max-request-size: 1GB
server:
tomcat:
max-part-count: 1000SPRING_SERVLET_MULTIPART_MAX_FILE_SIZE=50MB
SPRING_SERVLET_MULTIPART_MAX_REQUEST_SIZE=1GB
SERVER_TOMCAT_MAX_PART_COUNT=1000The request limit has to be at least as large as the file limit, otherwise it takes effect first. -1 means unlimited.
Why downloads are the real limit
When downloading, CDMS reads the whole file into memory and then sends it. The need is therefore roughly:
concurrent downloads × file size
Ten concurrent downloads of a 200 MB file need about 2 GB of memory, just for the files. That is why CDMS is designed for files up to about 25 MB: documents, images, scans. For videos or large archives, a separate store that CDMS only points to is better suited.
Pitfalls
What comes next
- How an upload is built: Uploading
- How a download works: Downloading
- Where the files live: Storage backends