Hi all,
See [1] for further background.
The current sendfile implementation for async HTTP/2 uses a
MappedByteBuffer as the source.
Unfortunately, MappedByteBuffer has some problematic side effects on
Windows. The underlying file is locked until the MappedByteBuffer is
GC'd. This causes problems with some usage patterns such as:
- GET file to review it
- file delivered by sendfile
- DELETE file as it is unwanted
- delete fails because file is locked
We have multiple options to address this. These include:
1. Switch to using FileChannel like NioEndpoint
2. Switch to using FileChannel like NioEndpoint when running on Windows
3. Disable HTTP/2 sendfile when running on Windows
4. On Windows with Java 12 onwards, use jdk.internal.misc.Unsafe to
clear the references held by the MappedByteBuffer once the file has been
sent.
5. Disable HTTP/2 sendfile when running on Windows unless Java 12
onwards is used in which case use jdk.internal.misc.Unsafe
6. Document the issue when running on Windows so users can disable
sendfile if their usage pattern is going to be problematic.
7. Something else...
Thoughts?
Mark
[1]
https://tomcat.markmail.org/thread/se75bjn2dskrfpls#query:+page:1+mid:vjrhogrpyhzobenj+state:results
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
