Details
-
Bug
-
Resolution: Fixed
-
Major
-
8.4.4, 9.0-rc-1
-
None
-
Integration
-
Unknown
-
N/A
-
N/A
-
Description
Steps to reproduce:
Preparation (not necessary to reproduce the bug):
- Create a page with an attachment that is sufficiently large (at least 1 MB to be sure)
- Export the page as a XAR archive
- Go to Content -> Import in the admin area
- Upload the exported XAR
Reproduction:
- Run readlink -f /proc/$PID/fd/* 2>/dev/null | grep deleted or another command for getting open files, filtering for deleted files.
- Import the exported XAR
- Immediately re-run readlink -f /proc/$PID/fd/* 2>/dev/null | grep deleted or another command for getting open files, filtering for deleted files.
Expected result:
There are no deleted open files reported, neither before nor after the import.
Actual result:
After the import, there is at least one deleted open file like attachment14823327115021904565.bin (deleted) inside the Servlet container's temporary directory.
The reason for this is that the output stream to which the attachment is written temporarily is never closed. During garbage collection, those files are eventually closed by the JDK, making it unlikely to have a bigger impact unless you're running huge imports with a lot of attachments on a system without much garbage collection pressure. The code for that was introduced in XWIKI-13950.
Attachments
Issue Links
- is caused by
-
XWIKI-13950 XAR input filter should not load the entire attachment in memory
-
- Closed
-