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

Anton Kozlov akozlov at openjdk.org
Wed Jul 19 10:13:18 UTC 2023


On Wed, 19 Jul 2023 07:36:40 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> When the application does not close some file descriptors through Resources we can use `jdk.crac.resource-policies` pointing to a configuration file that might adjust the behaviour. The file uses a simple YAML-conformant format with individual rules separated by a line with `---`:
>> 
>> 
>> type: file
>> path: /path/to/*.txt
>> action: close
>> ---
>> type: socket
>> localAddress: 127.0.0.1
>> localPort: 8080
>> action: ignore
>> 
>> 
>> Available types:
>> * `file`: supports `path` with 'glob' pattern matching (see FileSystem.getPathMatcher() for details)
>> * `pipe`: anonymous pipes (named pipe is handled as `file`)
>> * `socket`: can be refined using `family`, `localAddress`, `localPort`, `localPath` (in case of Unix sockets), `remoteAddress`, `remotePort` and `remotePath`
>> 
>> Actions depend on each resource, defaulting to `error`, with common options `close` and `ignore`. Files have `reopen` action, too.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows tests

src/java.base/share/classes/java/io/FileDescriptor.java line 93:

> 91:                     case "ignore":
> 92:                         if (Boolean.parseBoolean(warn)) {
> 93:                             LoggerContainer.warn("File descriptor {0} was not closed by the application. Use 'warn: false' in the policy to suppress this message.", fd);

The suggestion is repeated for every ignored object, and for every ignored type. Is it possible to print the suggestion once and remove the duplication in the code as well?


Jul 19, 2023 12:50:13 PM jdk.internal.crac.LoggerContainer warn
WARNING: File descriptor 2 was not closed by the application. Use warn: false in the policy to suppress this message.
java.io.FileDescriptor$Resource(FD 1) beforeCheckpoint
Jul 19, 2023 12:50:13 PM jdk.internal.crac.LoggerContainer warn
WARNING: File descriptor 1 was not closed by the application. Use warn: false in the policy to suppress this message.
java.io.FileDescriptor$Resource(FD 0) beforeCheckpoint
Jul 19, 2023 12:50:13 PM jdk.internal.crac.LoggerContainer warn


src/java.base/unix/classes/sun/nio/ch/PipeImpl.java
70:                        LoggerContainer.warn("{0} was not closed by the application. Use 'warn: false' in the policy to suppress this message.", this);

src/java.base/share/classes/java/lang/Process.java
876:                        LoggerContainer.warn("{0} was not closed by the application. Use 'warn: false' in the policy to suppress this message.", this);

src/java.base/share/classes/java/io/FileDescriptor.java
94:                            LoggerContainer.warn("File descriptor {0} was not closed by the application. Use 'warn: false' in the policy to suppress this message.", fd);

src/java.base/share/classes/jdk/internal/crac/JDKFileResource.java
85:                    LoggerContainer.warn("File {0} was not closed by the application. Use 'warn: false' in the policy to suppress this message.", path);

src/java.base/share/classes/jdk/internal/crac/JDKSocketResourceBase.java
54:                        LoggerContainer.warn("Socket {0} was not closed by the application. Use 'warn: false' in the policy to suppress this message.", owner);

src/java.base/share/classes/java/io/FileDescriptor.java line 115:

> 113:                     }
> 114:                 }
> 115:                 String regex = params.get("regex");

Should it be `"descriptionRegex"`? as now it may appear appear the FD value will be matched as well.

src/java.base/share/classes/java/io/FileDescriptor.java line 117:

> 115:                 String regex = params.get("regex");
> 116:                 if (regex != null) {
> 117:                     return Pattern.compile(regex).matcher(nativeDescription).matches();

I think `.find()` instead `.matches()` will fit better. The matches() looks for the complete match, while find() will allow substring match specification. Complete match specification will still be possible with `^` and/or `$`.

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

PR Review Comment: https://git.openjdk.org/crac/pull/69#discussion_r1267851882
PR Review Comment: https://git.openjdk.org/crac/pull/69#discussion_r1267863100
PR Review Comment: https://git.openjdk.org/crac/pull/69#discussion_r1267860650


More information about the crac-dev mailing list