-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Pinned thread on Vault fetch secret #41313
Comments
This issue is caused by the synchronized block in the internal implementation of the I honestly don't know if it makes sense at all to try to fix this issue, but if so I don't think we can get rid of that |
thanks for the investigation @mariofusco
|
WDYT @radcortez ? |
(the much better solution would for |
Consider that |
it is not an issue to have a |
We should reconsider how the REST Client builds / retrieves the configuration. Usually, a config object is populated at the start of the application. This allows us to validate the configuration and ensure we have everything we need. In this case, the boundary seems blurred because CDI creates injected REST Clients before the application starts, but this creates an invisible dependency between Config and CDI, which shouldn't exist. If we get rid of that, there is no need to keep a |
@radcortez I'd like to help fixing this issue but
it is not cleat at all to me how this is happening. Are you aware of any integration test reproducing this behavior or could you give me a few hints on how to develop a reproducer on my own? |
Yes, check here: These are the CDI parts that shouldn't be there:
Here the configuration is being created manually:
What we should do is remove any manual configuration creation and let the config system handle it. If we need to access the configuration values, we should use |
The pinned event is troublesome not because of the |
Yes, it will take a while to redo the REST Client configuration. |
I believe this issue can be closed since it has been structurally fixed with this commit 4f31e0d |
I agree. we will reopen if we see new occurences after we upgrade. thanks for the effort @radcortez and @mariofusco |
Describe the bug
I detected the following thread pinning:
we have not identified any native blocking calls in our business code.
what could cause this pinning?
I tried creating a reproducer, with no luck.
may be that is an issue with the vault extension, but I do not see any native call. or in the business code?
how can we investigate this issue?
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Output of
uname -a
orver
No response
Output of
java -version
No response
Quarkus version or git rev
3.9.5
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: