On Tue, Jun 21, 2022 at 8:47 PM Mark Thomas <ma...@apache.org> wrote: > > 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.
+1, that's a good compromise. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
