Skip to content

Subscription is not reliably created when using native images #1122

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
klopfdreh opened this issue Mar 6, 2025 · 1 comment
Open

Subscription is not reliably created when using native images #1122

klopfdreh opened this issue Mar 6, 2025 · 1 comment

Comments

@klopfdreh
Copy link

klopfdreh commented Mar 6, 2025

Expected Behavior

The subscription is created and everthing is working like expected all the time.

Actual Behavior

Sometimes a subscription is not created and the related code just runs 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 of the subscription is not created reliably 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.

  1. Create a Deployment with a prometheus rsocket proxy server
  2. Create a service which delegates tcp port 7001 to the pods created with the deployment
  3. Run a native Spring Boot application with prometheus rsocket proxy client which connects to the prometheus rsocket proxy server via the service

Possible Solution

N/A

Your Environment

  • 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
@klopfdreh
Copy link
Author

When I set spring.threads.virtual.enabled=true and use Java 21 instead of Java 17 to compile the code the issue seems to be gone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant