IllegalStateException "The current thread cannot be blocked: vert.x-eventloop-thread-1" in kafka topic message processing while invoking SecurityIdentity.getPrincipal()
See original GitHub issueDescribe the bug Using Quarkus 1.9.2 the very same code was working fine which is now failing with 1.10.3. I found a similar issue “OIDC 1.10.0.CR1 - event loop thread blocked #13249” but it was closed so I am not sure whether it is really the same problem.
We implemented a process which is receiving a message from a kafka topic and in that process we try to retrieve the name of the user if there is one with the following snippet (I mean, in this case there is no user, but in other cases where the code is used we have a user, and this class does more than just retrieving the name).
...
@Inject SecurityIdentity securityIdentity;
...
if (securityIdentity.getPrincipal() != null) {
lastChangedBy = securityIdentity.getPrincipal().getName();
}
...
Quarkus started to throw an exception with 1.10 release:
2020-12-11 08:04:58,991 WARN [io.sma.rea.mes.kafka] (vert.x-eventloop-thread-1) SRMSG18228: A failure has been reported for Kafka topics '[homologation-ui--feature-technical-value-ui-ci--ci-document-create]': java.lang.IllegalStateException: The current thread cannot be blocked: vert.x-eventloop-thread-1
at io.smallrye.mutiny.operators.UniBlockingAwait.await(UniBlockingAwait.java:29)
at io.smallrye.mutiny.groups.UniAwait.atMost(UniAwait.java:61)
at io.smallrye.mutiny.groups.UniAwait.indefinitely(UniAwait.java:42)
at io.quarkus.security.runtime.SecurityIdentityAssociation.getIdentity(SecurityIdentityAssociation.java:61)
at io.quarkus.security.runtime.SecurityIdentityAssociation_ClientProxy.getIdentity(SecurityIdentityAssociation_ClientProxy.zig:250)
at io.quarkus.security.runtime.SecurityIdentityProxy.getPrincipal(SecurityIdentityProxy.java:23)
at io.quarkus.security.runtime.SecurityIdentityProxy_ClientProxy.getPrincipal(SecurityIdentityProxy_ClientProxy.zig:370)
...
_SmallRyeMessagingInvoker_onMessage_f8d68f1a2268557ef7868a4206f95f280de86952.invoke(InformationDocumentCreationResource_SmallRyeMessagingInvoker_onMessage_f8d68f1a2268557ef7868a4206f95f280de86952.zig:48)
Expected behavior getPrincipal() should return null in case no user can be retrieved.
Actual behavior Exception is thrown
To Reproduce In above mentioned issue you are describing that all await need to be removed. I checked this SecurityIdentityAssociation class, there are still some awaits. So I feel that maybe a reproducer might not be required as maybe the issue is clear. But if this is a different problem I can work on a reproducer, please let me know.
Environment (please complete the following information): Output of uname -a or ver: Microsoft Windows [Version 10.0.17763.1282] Output of java -version: openjdk version “11” 2018-09-25 GraalVM version (if different from Java): Quarkus version or git rev: 1.10.3.Final Build tool (ie. output of mvnw --version or gradlew --version): Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Issue Analytics
- State:
- Created 3 years ago
- Comments:15 (12 by maintainers)
Top Related StackOverflow Question
Hey Clement @cescoffier I promise I can repeat it if someone wakes me up at night and asks, what you should not do with
Uni? 😃 I’ve learned my lesson after one of my infamous PRs got merged earlier 😃This is because of the changes around lazy authentication.
Basically lots of places that were using SecurityIdentity are now using Uni<SecurityIdentity>, as there is a chance that authentication has not actually happened yet, and subscribing to the Uni would trigger the authentication attempt. When proactive auth is in use (the default) await will never block.
I should be able to fix this, but the resulting code won’t be quite as clean.