On 21/06/2022 08:53, Rémy Maucherat wrote:
On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas <ma...@apache.org> wrote:
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.
I would choose this one, also since it's only until GC occurs.
Memory mapping seems more efficient than other techniques (less
copying, also it's a direct buffer).
You don't think it is worth trying to fix this if running on Java 12 or
later?
My expectation is that it should be relatively low risk since we know
when the completion handler has finished and we could clear the
references then.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
