[crac] RFR: Handle open file descriptors with configurable policies [v9]

[Anton Kozlov]

On Tue, 4 Jul 2023 09:03:59 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileOutputStream.java line 489:
>> 
>>> 487:                 }
>>> 488:                 // FileOutputStream writes only forward, so it makes sense to reopen it appending
>>> 489:                 open(path, true);
>> 
>> This should be done depending on the initial mode, and in the non-appending mode, we should also store and restore the position (e.g `getChannel.position()`).
>
> This does not work; when creating the FileChannel (lazy) as an attempt to read the position I would create another JDKFileResource, and try to register it => this would get blocked as we're already in the FDs priority.
> 
> I could probably add in some exceptions to not create it on this codepath, but is it really worth it? I thought that the idea was to work we already have in the resource. And there's no difference in behaviour unless someone appends to that file during checkpoint.

Implicit change of append mode from false to true will surprise users of the channel. E.g. after automatic re-open, the position setting won't take effect anymore, while it was possible if the FOS was created in non-appending mode.

I'm fine to implement automatic re-opening only FOS originally opened with append. In general, re-opening a file in non-append will also require (optional) verification the file has not been changed, which may be pretty complex, so I don't think it should be implemented now for FOS or other Files.

>> src/java.base/unix/classes/sun/nio/ch/FileDispatcherImpl.java line 64:
>> 
>>> 62:         // might read configuration files with this or later priority.
>>> 63:         // It's difficult to trigger static initialization outside the package.
>>> 64:         Core.Priority.PRE_FILE_DESCRIPTORS.getContext().register(resourceProxy);
>> 
>> The change looks safe but not clear. The resourceProxy eventually calls FileDispatcherImpl.beforeCheckpoint, that closes preClose sockets, blocking FDI.preClose() operation. Does the problem appear when a configuration file is closed? Or is it just registration to NORMAL priority when it is being processed already?
>
> The problem with registration at NORMAL level is that this is the same level as OpenResourcePolicies registers to, in order to fetch the configuration just before the checkpoint (to allow dynamic configuration from within the app). When ORP.beforeCheckpoint opens the configuration file and this is the first moment FDI is used (triggering the static initialization) this results in FDI registering with the priority that is already being executed - depending on the context impl this either blocks or the FDI resourceProxy is not called.
> Ideally I would trigger clinit for FDI from FileDescriptor and ensure that it's already registered before checkpoint, but haven't found any simple way to do that.

Thanks for the clarification, makes sense.

-------------

PR Review Comment: https://git.openjdk.org/crac/pull/69#discussion_r1252217576
PR Review Comment: https://git.openjdk.org/crac/pull/69#discussion_r1252157120