DefaultChannelId wants to know the process id (PID) and hostname for the running process. Spring Boot already knows at least one of those, so it could maybe stop Netty from having to find it out again.

Aside: I noticed this in a GraalVM native image, where Spring Boot correctly reports the PID, but netty moans that it can't find it:

2020-07-13 08:32:12.736  INFO 2280 --- [           main] app.main.SampleApplication               : Starting SampleApplication using Java 1.8.0_252 on eeac20422b96 with PID 2280 (/workspaces/spring-init/samples/func/target/func started by dsyer in /workspaces/spring-init/samples/func)
...
2020-07-13 08:32:12.754  WARN 2280 --- [           main] io.netty.channel.DefaultChannelId        : Failed to find the current process ID from ''; using a random value: 1437782447

Comment From: wilkinsona

Looks like it should be possible by setting the io.netty.processId system property to the value of new ApplicationPid().toString(). We do something similar for logging and the PID system property at the moment. Could you please try that in a native image and confirm that it does the trick?

Comment From: dsyer

I can confirm that the warning goes away if you System.setProperty("io.netty.processId", new ApplicationPid().toString()) in the application main(). Could a netty app do that in an initializer or a listener or something? Maybe share the PID globally somewhere?

Comment From: wilkinsona

Looking more closely, I don't understand why ApplicationPid works and Netty's DefaultProcessId does not. Both attempt to determine the PID by parsing the name of the RuntimeMXBean. Netty's code hasn't changed in several years so it doesn't look like it's a recent thing.

Have you got something in spring-graal-native that makes ApplicationPid work?

Comment From: dsyer

I think the difference might be that Netty uses reflection to instantiate the RuntimeMXBean and Spring Boot doesn't. AFAIK we don't do anything special in spring-graalvm.

Comment From: philwebb

Before we look at changing any Spring Boot code, I think it would be worth submitting a fix to Netty. Anything we add in Spring Boot will be quite unusual and since we ultimately call the same RuntimeMXBean method, I'd rather not have the maintenance burden in our code.

Comment From: philwebb

https://github.com/netty/netty/pull/10753 was merged so I'm going to close this one.