You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2022/06/21 07:13:18 UTC
MappedByteBuffer, Windows and locked files
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.
7. Something else...
Thoughts?
Mark
[1]
https://tomcat.markmail.org/thread/se75bjn2dskrfpls#query:+page:1+mid:vjrhogrpyhzobenj+state:results
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: MappedByteBuffer, Windows and locked files
Posted by Rémy Maucherat <re...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: MappedByteBuffer, Windows and locked files
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: MappedByteBuffer, Windows and locked files
Posted by Rémy Maucherat <re...@apache.org>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: MappedByteBuffer, Windows and locked files
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: MappedByteBuffer, Windows and locked files
Posted by Rémy Maucherat <re...@apache.org>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org