Exceptions on dev mode reload (with multiple inbound requests?) #29646
Labels
Milestone
Comments
|
I thought we already put connections on hold while restarting the application |
|
Hm, the actual restart should be performed during invocation of
Is it the SPA or the haproxy? |
|
It's the SPA and my UI colleague says it's fine. |
|
I know that it's probably difficult but could you try to build a simple reproducer app? |
|
I quickly tried hammering |
You can try to add some |
|
@mkouba "app init"? Where would you put it exactly? Thanks! |
Maybe a |
|
Ok, vanilla app level events then (I thought you were after some more extension-level kind of delay). I played around with sleep in |
|
FTR, this still happens with 2.16.5. I'll try to continue with my reproducer efforts. |
|
Still happens with 3.2.3, e.g.: and then after the restart: Next F5 is ok. |
|
3.3.2, bit different: |
|
Also facing the last one @famod posted "No CDI container is available". On 3.2.6.Final. |
|
Still an issue in Quarkus 3.14.4. Trace looks a bit different now, but still OIDC in the mix: /cc @sberyozkin PS: Haven't had any time to try harder with a reproducer, unfortunately. |
|
Thanks for checking |
|
So I was able to reproduce this!
diff --git a/security-openid-connect-client-quickstart/src/main/java/org/acme/security/openid/connect/client/FrontendResource.java b/security-openid-connect-client-quickstart/src/main/java/org/acme/security/openid/connect/client/FrontendResource.java
index cf87223f6..d60ebb0b4 100644
--- a/security-openid-connect-client-quickstart/src/main/java/org/acme/security/openid/connect/client/FrontendResource.java
+++ b/security-openid-connect-client-quickstart/src/main/java/org/acme/security/openid/connect/client/FrontendResource.java
@@ -47,7 +47,10 @@ public class FrontendResource {
@Produces("text/plain")
public Uni<String> getUserNameWithOidcClientTokenHeaderParam() {
return tokenHelper.getTokens(oidcClientCreator.getOidcClient()).onItem()
- .transformToUni(tokens -> restClientWithTokenHeaderParam.getUserName("Bearer " + tokens.getAccessToken()));
+ .transformToUni(tokens -> {
+ System.out.println("AccessToken: " + tokens.getAccessToken());
+ return restClientWithTokenHeaderParam.getUserName("Bearer " + tokens.getAccessToken());
+ });
}
@GET
/cc @sberyozkin |
|
I'm under the impression that oidc is only a victim of a timing issue (?) in |
|
I've another reproducer for this: In quarkiverse/quarkus-renarde#266 a user reported an issue which happens when triggering multiple connections during a live reload. Apparently, according to As such, what's happening is that the user makes a change, hits reload, but it's probably taking too long, so they hit reload again, and the second connection is served while the first is still handling the hot reload. But midway during the request serving, the reload is happening and we're shutting down the Arc Container so the request fails with a really weird and confusing exception. I could fix the symptom, but that's a waste of time because other applications would fail in different ways. We could either make new connections (after the hot reload started) wait for the hot reload to be finished, or we could make them serve an error page mentioning that a hot reload is in progress. I suspect the first option is more user-friendly. To reproduce:
This should be easy to reproduce with a hot reload test if we make sure the reload takes an artificially long time (not sure how, perhaps a 1s sleep during a custom build step, or a startup bean?). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
After changing a file, I often see one or more exceptions when hitting F5 in my UI (Vue.js SPA -> haproxy -> Quarkus).
Those exceptions are mostly related to some NPEs in ArC, but I also had datasource issues like
Stream closed.For whatever reason, the SPA fires off two requests to the same endpoint, the second one apparently before waiting for the first one to finish.
Example exceptions (click me)
OIDC
RR exception mapping
Expected behavior
No request should be processed while dev mode is being restarted.
Actual behavior
It seems that the first request triggers the reload and before that is finished, the second request catches Quarkus in an inconsistent state.
How to Reproduce?
Update: #29646 (comment)
Output of
uname -aorverNo response
Output of
java -versionNo response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.14.2
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: