Why would Quarkus/Smalrye messaging consumer nack on on blocked vertx thread?

Question

I though this message was for warning, so why would the consumer nack it? Also adding @Blocking to the process function below seems to "fix" the issue.

I have my processor like so...

@Incoming("topic-in")
public void process(String event) {
    // This call Http rest Clients underneath 
    someService.update(event);
}

java.lang.IllegalStateException: The current thread cannot be blocked: vert.x-eventloop-thread-0
    at io.smallrye.mutiny.operators.uni.UniBlockingAwait.await(UniBlockingAwait.java:30)
    at io.smallrye.mutiny.groups.UniAwait.atMost(UniAwait.java:65)
    at io.smallrye.mutiny.groups.UniAwait.indefinitely(UniAwait.java:46)
    at io.quarkus.cache.runtime.CacheResultInterceptor.intercept(CacheResultInterceptor.java:116)
    at io.quarkus.cache.runtime.CacheResultInterceptor_Bean.intercept(Unknown Source)
    at io.quarkus.arc.impl.InterceptorInvocation.invoke(InterceptorInvocation.java:41)
    at io.quarkus.arc.impl.AroundInvokeInvocationContext.perform(AroundInvokeInvocationContext.java:41)
    at io.quarkus.arc.impl.InvocationContexts.performAroundInvoke(InvocationContexts.java:32)
    at xxxxxx.service.AuthService_Subclass.authenticate(Unknown Source)
    at xxxxxx.service.SomeService.update(SubscriberService.java:46)
    at xxxxxx.service.SomeService_Subclass.update$$superforward1(Unknown Source)
    at xxxxxx.service.SomeService_Subclass$$function$$3.apply(Unknown Source)
    at io.quarkus.arc.impl.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:54)
    at io.smallrye.faulttolerance.FaultToleranceInterceptor.lambda$syncFlow$3(FaultToleranceInterceptor.java:253)
    at io.smallrye.faulttolerance.core.InvocationContext.call(InvocationContext.java:20)
    at io.smallrye.faulttolerance.core.Invocation.apply(Invocation.java:29)
    at io.smallrye.faulttolerance.core.retry.Retry.doApply(Retry.java:88)
    at io.smallrye.faulttolerance.core.retry.Retry.apply(Retry.java:42)
    at io.smallrye.faulttolerance.FaultToleranceInterceptor.syncFlow(FaultToleranceInterceptor.java:255)
    at io.smallrye.faulttolerance.FaultToleranceInterceptor.intercept(FaultToleranceInterceptor.java:182)
    at io.smallrye.faulttolerance.FaultToleranceInterceptor_Bean.intercept(Unknown Source)
    at io.quarkus.arc.impl.InterceptorInvocation.invoke(InterceptorInvocation.java:41)
    at io.quarkus.arc.impl.AroundInvokeInvocationContext.perform(AroundInvokeInvocationContext.java:41)
    at io.quarkus.arc.impl.InvocationContexts.performAroundInvoke(InvocationContexts.java:32)
    at xxxxxx.service.SubscriberService_Subclass.update(Unknown Source)
    at xxxxxx.messaging.MyProcessor.updateCustomer(CustomerProcessor.java:6262)
    at xxxxxx.messaging.MyProcessor.update(CustomerProcessor.java:6204)
    at xxxxxx.messaging.MyProcessor.process(CustomerProcessor.java:6162)
    at xxxxxx.messaging.MyProcessor_ClientProxy.process(Unknown Source)
    at xxxxxx.messaging.MyProcessor_SmallRyeMessagingInvoker_process_bd386abe989418e778612ad8212523c81d813d5e.invoke(Unknown Source)
    at io.smallrye.reactive.messaging.providers.AbstractMediator.invoke(AbstractMediator.java:95)
    at io.smallrye.reactive.messaging.providers.AbstractMediator.lambda$invokeOnMessageContext$1(AbstractMediator.java:103)
    at io.smallrye.reactive.messaging.providers.locals.LocalContextMetadata.lambda$invokeOnMessageContext$0(LocalContextMetadata.java:34)
    at io.smallrye.reactive.messaging.providers.locals.LocalContextMetadata.lambda$invokeOnMessageContext$2(LocalContextMetadata.java:55)
    at io.smallrye.context.impl.wrappers.SlowContextualConsumer.accept(SlowContextualConsumer.java:21)
    at io.smallrye.mutiny.operators.uni.builders.UniCreateWithEmitter.subscribe(UniCreateWithEmitter.java:22)
    at io.smallrye.mutiny.operators.AbstractUni.subscribe(AbstractUni.java:36)
    at io.smallrye.mutiny.operators.uni.UniOnItemOrFailureFlatMap.subscribe(UniOnItemOrFailureFlatMap.java:27)
    at io.smallrye.mutiny.operators.AbstractUni.subscribe(AbstractUni.java:36)
    at io.smallrye.mutiny.converters.uni.UniToMultiPublisher$UniToMultiSubscription.request(UniToMultiPublisher.java:74)
    at io.smallrye.mutiny.operators.multi.MultiFlatMapOp$FlatMapInner.onSubscribe(MultiFlatMapOp.java:601)
    at io.smallrye.mutiny.converters.uni.UniToMultiPublisher.subscribe(UniToMultiPublisher.java:26)
    at io.smallrye.mutiny.groups.MultiCreate$1.subscribe(MultiCreate.java:163)
    at io.smallrye.mutiny.operators.multi.MultiFlatMapOp$FlatMapMainSubscriber.onItem(MultiFlatMapOp.java:193)
    at io.smallrye.mutiny.operators.multi.MultiMapOp$MapProcessor.onItem(MultiMapOp.java:50)
    at io.smallrye.mutiny.subscription.MultiSubscriber.onNext(MultiSubscriber.java:61)
    at io.smallrye.mutiny.subscription.SafeSubscriber.onNext(SafeSubscriber.java:99)
    at io.smallrye.mutiny.helpers.HalfSerializer.onNext(HalfSerializer.java:31)
    at io.smallrye.mutiny.helpers.StrictMultiSubscriber.onItem(StrictMultiSubscriber.java:85)
    at io.smallrye.mutiny.operators.multi.MultiOperatorProcessor.onItem(MultiOperatorProcessor.java:100)
    at io.smallrye.reactive.messaging.providers.locals.ContextDecorator$ContextMulti$ContextProcessor.lambda$onItem$1(ContextDecorator.java:78)
    at io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100)
    at io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:63)
    at io.vertx.core.impl.EventLoopContext.lambda$runOnContext$0(EventLoopContext.java:38)
    at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503)
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.base/java.lang.Thread.run(Thread.java:829)

score 1 · Accepted Answer · answered Jun 10 '22 at 18:23

1

@Blocking seems to fix in your case because it indicates to quarkus that this operation is blocking, it makes quarkus happy. But when you don't put it, and still do a blocking operation, quarkus complains.

I believe your http rest endpoint call is not reactive, that's why quarkus complains. Try replacing it by any reactive operation and try again.

If it's working, your solution simply is to use reactive http client to make your calls.

Check quarkus http reactive rest client documentation

answered Jun 10 '22 at 18:23

Jacouille

951
8
14

Yes I understand I can use reactive client. But I'm asking why the process is catching this exception and nacking it? I thought that the blocking thread was a warning on the background. Or is that blocked error different from the "Vertx thread has been blocked for XXXX ms" warning message? – user432024 Jun 10 '22 at 19:18
Exception is thrown because you are not allowed to block this thread. It's different from the warning about long-running task blocked thread. – Jacouille Jun 10 '22 at 19:27
And nack is because exception is thrown and processing cannot complete – Jacouille Jun 10 '22 at 19:28
Ok so if I switch to reactive client I can remove the @Blocking but I need to make sure the above process function returns Uni? – user432024 Jun 10 '22 at 19:41
yes if you switch to reactive http client you can remove the @Blocking annotation. But Uni<> is not reactive, its part of Mutiny. It can be used with or without reactive – Jacouille Jun 10 '22 at 19:46
But I mean if I switch to reactive http client my consumer returns void. Do I need to switch the method signature to return Uni and ack/nack based on the completion of the reactive http call? – user432024 Jun 12 '22 at 16:11
Yes you could do that, i was just trying to make it clear that Reactive != Mutiny, but in your case you seem to use both. For Ack/Nack i believe quarkus is doing it automatically, that's why you encountered auto nack on exception throwing – Jacouille Jun 12 '22 at 17:17
You confused me more than anything... The process function for my consumer returns void, I call a blocking function so the process function acks only after the blocking function finishes (Hence the blocking errors and the @Blocking fix). It's only bliocking cause I'm not using anything reactive. If I switch the doSoemthing() function to reactive it means I need to switch my process signature to reactive as well no? As in return Uni or CompletionStage which means I need to manually run ack or nack based on what doSomethingReactive() – user432024 Jun 13 '22 at 14:32

Why would Quarkus/Smalrye messaging consumer nack on on blocked vertx thread?

1 Answers1