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. > 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. Rémy > > Mark > > --------------------------------------------------------------------- > 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
