reactor-tcp-epoll not reliably created when using native images

[klopfdreh]

Expected Behavior

The thread pool is created and everthing is working like expected

Actual Behavior

Sometimes the thread pool is not created and the rsocket subscription is just running in a timeout - I just thought this is a problem of the specific implementation of Prometheus RSocket Proxy, but the more I digg into it the more I think this is an issue that the reactor-tcp-epoll pool is not created within native images created with graalvm - for more information see: micrometer-metrics/prometheus-rsocket-proxy#94

Steps to Reproduce

I created a setup to create native images and to test it against a local running Prometheus RSocket Proxy: https://github.com/klopfdreh/prometheus-rsocket-native-test - but sadly I was not able to reproduce it without K8 setup.

Possible Solution

N/A

Your Environment

• Reactor version(s) used:
• reactor-core 3.7.3
• GraalVM: bellsoft-liberica-vm-openjdk23+38-24.1.0+1-linux-amd64.tar.gz
• Prometheus RSocket Proxy 2.0.0-RC1
• Netty 4.1.118.Final
• Spring Boot 3.4.3

[chemicL]

Hey, @klopfdreh. Can you explain why do you think this issue belongs in the reactor-core repo? reactor-tcp-epoll is not a pool created nor managed using reactor-core. I have seen in micrometer-metrics/prometheus-rsocket-proxy#94 that there was no feedback from maintainers yet, so perhaps we can close this issue and reopen in case you get some pointers and find a reproducer without external dependencies that shows reactor-core is at fault.

[klopfdreh]

Hey @chemicL - thanks for the your fast answer. So I first created the ticket at prometheus-rsocket-proxy because this is the framework we use and which shows the issue. I did some code refactoring to see what's going on which is a good improvement. After some debugging I just saw that that all related code which should be executed and is not in case of that error was executed in a thread pool mentioning reactor-tcp*. Because of this I thought it is not that specific implementation of prometheus-rsocket-proxy, but the underlying frameworks, but it also affects prometheus-rsocket-proxy. That's the reason why I opened the ticket here.

So maybe it could also be an issue of io.rsocket.core as it only uses reactor to implement the subscription behavior based on rsocket protocol. That I don't know for sure.

[chemicL]

If you can reproduce this with bare RSocket but not the underlying libraries, perhaps the issue is best suited in the RSocket issue tracker. RSocket also uses reactor-netty. So there is some narrowing down required. Once we can isolate the issue to something that can be shown, using a minimal reproducer, that is a reactor-core bug, I'd be happy to investigate. For now, I'll close the issue. Please reopen if you have such a reproducer. Thanks.

[klopfdreh]

I created a ticket at io.rsocket: rsocket/rsocket-java#1122

If this ticket is going to be required as you mention, I am going re-open it. Thanks a lot for your help 👍

[klopfdreh]

Hey @chemicL - just wanted to let you know that we tested to switch to Java 21 and Virtual Threads and compiled native images of those binary files which fixed this issue.

[chemicL]

@klopfdreh thanks for the heads-up. Did you manage to find the root cause of the issue with Java 17? I wonder if any of the involved libraries could fix something.

[klopfdreh]

@chemicL sadly not - it can be prometheus-rsocket-proxy over io.rsocket all the way down to te thread implementation of JDK / JRE 21