On 21/06/2022 13:25, Rémy Maucherat wrote:
kOn Tue, Jun 21, 2022 at 12:41 PM Mark Thomas <ma...@apache.org> wrote:
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?
Not really. I don't understand what's the process for selecting
Windows when you're designing a R/W webapp. Sure it might work.
Sometimes.
:)
ACK.
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.
You say you're going to use Unsafe, in which case it could cause
problems eventually. Cleaning up native stuff in completion handlers
or cleaners works well, indeed.
Fair enough. I'll put the warning in place for now. If this becomes a
larger issue over time, we can always look again at using Unsafe.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
