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). Rémy > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
