Allow for more narrowed netty ResourceLeakDetector customization

[mipo256]

Currently, spring-boot allows for the configuration of netty's leak detection strategy. Althought that is very useful, but for debugging purposes in tests, it is not enough.

ResourceLeakDetector itself also has the targetRecords property, that basically allows for batching the errors related to leak detection. And that sometimes is very, very useful to configure this property for tests to 1 for instance to ease the debugging the memory leakage problems in applications that use netty.

So I propose to at least add the targetRecords configuration option, and, probably, the samplingInterval should also be configurable as well. Althought, I personally did not used to tackle it in tests or in general.

P.S: I can assit with the solution for this issue

[philwebb]

Unfortunately It looks like ResourceLeakDetector initializes that value by reading a System property in a static initializer. As such, I don't think we'd have a reliable way of setting it ourselves. It looks like it's really indented to be set as a -D property directly by the user.

@mipo256 How do you currently use this property? Do you set it before all your tests run or on a test-by-test basis and hope that the first test to initialize ResourceLeakDetector has the correct system property set?

[mipo256]

Unfortunately It looks like ResourceLeakDetector initializes that value by reading a System property in a static initializer

That is correct, @philwebb. And yes, in general, in cases where it is required, we have a separate maven-surefire-plugin execution task for launching specific tests with -D options.

Setting it before all the tests somehow via System.setProperty is just not going to work, since ResourceLeakDetector is loaded way before the tests are even considered.

This kind of lack of customization is described here, in the corresponding netty issue. I think that currently, indeed, for spring-boot it is unreasonable to try to set it. Maybe before the property is allowed for customization on the netty's side, we can consider this issue as blocked

[philwebb]

Thanks @mipo256. I'm going to close this one for now rather than waiting. We can reopen it if netty/netty#15350 is addressed.