oidc-client, ContextNotActiveException in new thread #22477
Comments
|
/cc @pedroigor, @sberyozkin |
|
Hi @mkouba @stuartwdouglas Can you comment please, FYI, the filter which has and it is used in this code:
I think the executor should be created differently, using the one provided by Quarkus ? |
Yes, a manually created executor does not propagate the CDI request context. You'll need to add the |
|
@mkouba Thanks for your suggestions. |
I see. But from the stack trace I can see that this bean probably injects a rest client which expects the context to be active. So I'd say that the injected |
|
+1, Martin is right. The executor needs to come from SR context propagation. It can be either injected or created via the builder pattern. Injection is the recommended and simpler approach. |
|
I Injected the ManagedExecutor but then I got another fault, see code and stacktrace below, any more suggestions? ` } ` javax.ws.rs.ProcessingException: java.util.concurrent.CompletionException: java.lang.InterruptedException |
|
@lthasle Interesting. I think it might be related to the fact that the My guess Martin @mkouba, Matej @manovotn - is it indeed the case that @lthasle, @mkouba @manovotn Can you recommend any other options ? May be we can configure @lthasle I'll also look at introducing a simple |
|
I am not aware of ME not being able to serve blocking tasks. But I cannot really investigate now (on PTO and travelling). |
|
@manovotn sure, enjoy it, happy holidays :-) |
|
@sberyozkin Thanks for your effort and suggestions so far! |
|
Same problem with the latest quarkus version: 2.6.0.Final I also had to change quarkus-test-artemis dependency: io.quarkiverse.artemis quarkus-test-artemis 1.0.3 test |
|
@lthasle Np, with many people on PTO, myself signing off later today as well, it is unlikely we'll have a solution before the end of the year :-). But at least we know how to approach it: 1) investigate how |
|
Same problem with the latest quarkus version: 2.6.1.Final |
No it's not, this is directly backed by the Quarkus worker thread pool, so you can block. |
|
The real question is why is the thread interrupted? And perhaps there are some bits which should handle the interruption? |
@FroMage @manovotn May be because the injection is happening on the IO thread while injected tokens producer is blocking. |
|
@sberyozkin thanks for your proposal but adding: |
|
@lthasle Sorry, I forgot that it is a global property, https://github.com/quarkusio/quarkus/blob/main/extensions/oidc-client/runtime/src/main/java/io/quarkus/oidc/client/runtime/AbstractTokensProducer.java#L21, it is not a client tenant specific, can you please try |
|
@sberyozkin |
|
Hmm... I'm out of the ideas right now. |
|
@sberyozkin But the stacktrace is different related to the class AbstractTokensProducer which you talk about:
|
|
@lthasle Sorry about all of it, I'll try to have a look when I'm back; So it all works if it is not a new thread - but if it is a new thread provided by Hi @mkouba @manovotn @FroMage - if you have any other ideas why it can be the case then please comment - this is the only difference, the client request filter which has a blocking |
|
@sberyozkin |
|
@sberyozkin Required change: java.util.concurrent.CompletionException: java.lang.InterruptedException |
|
I might be misreading this, but why would a request made from the scheduler be expected to be able to retrieve OIDC token from the current request (which doesn't exist)? |
|
Hi @geoand the filter which is applied to the rest client retrieves this token from the remote OIDC server and it is failing; I'll need to add a test to reproduce |
|
Ah okay. I misunderstood what it does then. Thanks |
|
Hi @lthasle I've finally found the time to add a test, please see #22987. It works fine. (I tested the default filter as well separately) The only significant difference between your code and the test which I see is that you inject the client (and the factory) directly into Something else might be contributing to the failure in your case. Note, @stuartwdouglas has just improved |
|
@sberyozkin Thanks for your effort, but I get the same fault when I use 2.7.0.CR1 javax.ws.rs.ProcessingException: java.util.concurrent.CompletionException: java.lang.InterruptedException |
|
@lthasle Hi, missed your comment, reopened. I don't know what else can be done - can you please create a specific reproducer, with a test similar to the one I added in my PR ? (The client calls the frontend endpoint, this endpoint, in turn, from a Runnable task calls the downstream endpoint). But it can't really work - the downstream target and OIDC server URLs are the same. How about checkout out Quarkus and modifying the test I've added until you reproduce the problem - everything is already set up there except for the broker ? |
|
Is there a guide which shows how I can setup my environment to run your test? ` ` |
|
@lthasle Did you checkout the main branch and built it, see https://github.com/quarkusio/quarkus/blob/main/CONTRIBUTING.md ? CC @gsmet |
|
Looks like you did, sorry |
|
You just need to add an Note that if you run the test you will still see a different exception as Quarkus will shutdown before the startup task is complete (once the test is run quarkus shuts down, but the run method is async). I think this can be closed. |
|
@sberyozkin @stuartwdouglas THANKS! It works with @ActivateRequestContext |
|
@stuartwdouglas Thanks Stuart, I've learned something new :-) |
Describe the bug
It seams like Context is lost in the new thread when using Tokens from oidc-client
See also:
#22273
Expected behavior
Usage of io.quarkus.oidc.client.Tokens should work, ie. have a value
Actual behavior
Usage(@Inject) of io.quarkus.oidc.client.Tokens is causing: ContextNotActiveExceptionThe result from running: MyResourceTest.fail:
javax.ws.rs.ProcessingException: javax.enterprise.context.ContextNotActiveException at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:780) at org.jboss.resteasy.microprofile.client.impl.MpClientInvocation.filterRequest(MpClientInvocation.java:75) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:491) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invokeSync(ClientInvoker.java:152) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:115) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76) at com.sun.proxy.$Proxy107.updatestate(Unknown Source) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.jboss.resteasy.microprofile.client.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:146) at com.sun.proxy.$Proxy108.updatestate(Unknown Source) at org.my.StreamService.lambda$0(StreamService.java:26) at org.my.AbstractMeglerService.execute(AbstractMeglerService.java:17) at org.my.StreamService.updateState(StreamService.java:26) at org.my.StreamService_ClientProxy.updateState(Unknown Source) at org.my.QConsumer.run(QConsumer.java:35) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: javax.enterprise.context.ContextNotActiveException at io.quarkus.arc.impl.ClientProxies.getDelegate(ClientProxies.java:46) at io.quarkus.oidc.client.runtime.TokensProducer_MidtNorge_ProducerMethod_produceTokens_494654c3bfa2346b017c24e2e2c4fcfc99087d0e_ClientProxy.arc$delegate(Unknown Source) at io.quarkus.oidc.client.runtime.TokensProducer_MidtNorge_ProducerMethod_produceTokens_494654c3bfa2346b017c24e2e2c4fcfc99087d0e_ClientProxy.getAccessToken(Unknown Source) at org.my.StreamAuthenticationFilterMidtNorge.filter(StreamAuthenticationFilterMidtNorge.java:21) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:767) ... 22 moreHow to Reproduce?
It is based on: https://quarkus.io/guides/rest-client
I added my stuff in the package: org.my
The problem can be verified by running the test: MyResourceTest.fail
The other test: MyResourceTest.ok is doing the same, BUT in same thread (that is not via a Q, as the other test),
but it requires proper values in: application.properties to succeed.
Output of
uname -aorveruname -a Linux hty80028.sb1a.sparebank1.no 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Mon Nov 8 13:30:15 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -versionopenjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.5.4.Final
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
rest-client-quickstart.zip
The text was updated successfully, but these errors were encountered: