-
Notifications
You must be signed in to change notification settings - Fork 61
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
org.eclipse.microprofile.health.HealthCheckResponse leaks #128
Milestone
Comments
Hi @rmannibucau, could you provide a use case to justify this change that could impact perf ? |
Just take an environment with provider in apps, not in a flat classpath or shared container classloader. Perf will not be impacted if designed well enough - EE vendors do it since years without issues ;). |
antoinesd
added a commit
to antoinesd/microprofile-health
that referenced
this issue
Jul 20, 2020
…sponse leaks fixes eclipse#128 with multiple providers support addition Signed-off-by: Antoine Sabot-Durand <[email protected]>
antoinesd
added a commit
to antoinesd/microprofile-health
that referenced
this issue
Jul 20, 2020
…sponse leaks fixes eclipse#128 with multiple providers support addition Signed-off-by: Antoine Sabot-Durand <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
org.eclipse.microprofile.health.HealthCheckResponse uses a static var to store the provider, this doesnt enable to mix impl, it should be looked up each time and a cache is acceptable for perf reason while it ensures it releases the mem on gc (key can be a classloader like).
Alternative is to just let the builder factory be injected and let the impl provide the beam -> no static lookup :)
The text was updated successfully, but these errors were encountered: