Quarkus: Failed to inject redis client

Created on 10 Aug 2020  路  7Comments  路  Source: quarkusio/quarkus

Describe the bug
I'm trying to inject Redis client into grpc service and get an error.

@Singleton
class MyServiceGrpc(
        private val redisClient: ReactiveRedisClient
) : MutinyMyGrpc.MyImplBase() {

Error:

javax.enterprise.inject.CreationException: Synthetic bean instance not initialized yet: io_vertx_core_Vertx_97d170e1550eee4afc0af065b78cda302a97674c

I guess that's related to the scope being @Singleton instead of @ApplicationScoped because in other places where I have ApplicationScoped annotation it works just fine. But I guess no choice, but to use Singleton for grpc services.

Quarkus version: 1.7.0.CR2

Expected behavior
Bean is injected successfully

Actual behavior
Error:

2020-08-11 00:10:56,342 ERROR [io.qua.application] (Quarkus Main Thread) Failed to start application (with profile dev): javax.enterprise.inject.CreationException: Synthetic bean instance not initialized yet: io_vertx_core_Vertx_97d170e1550eee4afc0af065b78cda302a97674c
    at io.vertx.core.Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.create(Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.zig:115)
    at io.vertx.core.Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.create(Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.zig:138)
    at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:88)
    at io.quarkus.arc.impl.ComputingCache$CacheFunction.lambda$apply$0(ComputingCache.java:99)
    at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:26)
    at io.quarkus.arc.impl.ComputingCache.getValue(ComputingCache.java:41)
    at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:25)
    at io.vertx.core.Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.get(Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.zig:170)
    at io.vertx.core.Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.get(Vertx_7c31d5064e6d5db248fafa10f188ca6323f3f983_Synthetic_Bean.zig:186)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_Bean.create(RedisAPIProducer_Bean.zig:277)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_Bean.create(RedisAPIProducer_Bean.zig:301)
    at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:88)
    at io.quarkus.arc.impl.ComputingCache$CacheFunction.lambda$apply$0(ComputingCache.java:99)
    at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:26)
    at io.quarkus.arc.impl.ComputingCache.getValue(ComputingCache.java:41)
    at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:25)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_ClientProxy.arc$delegate(RedisAPIProducer_ClientProxy.zig:92)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_ClientProxy.arc_contextualInstance(RedisAPIProducer_ClientProxy.zig:110)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.create(RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.zig:127)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.create(RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.zig:145)
    at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:88)
    at io.quarkus.arc.impl.ComputingCache$CacheFunction.lambda$apply$0(ComputingCache.java:99)
    at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:26)
    at io.quarkus.arc.impl.ComputingCache.getValue(ComputingCache.java:41)
    at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:25)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.get(RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.zig:177)
    at io.quarkus.redis.client.runtime.RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.get(RedisAPIProducer_ProducerMethod_reactiveRedisClient_778496ebf1f3c589f39a8959826ac95fa3d910d1_Bean.zig:193)
    at com.example.MyServiceGrpc_Bean.create(MyServiceGrpc_Bean.zig:189)
    at com.example.MyServiceGrpc_Bean.create(MyServiceGrpc_Bean.zig:316)
    at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:88)
    at io.quarkus.arc.impl.ComputingCache$CacheFunction.lambda$apply$0(ComputingCache.java:99)
    at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:26)
    at io.quarkus.arc.impl.ComputingCache.getValue(ComputingCache.java:41)
    at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:25)
    at com.example.MyServiceGrpc_Bean.get(MyServiceGrpc_Bean.zig:348)
    at com.example.MyServiceGrpc_Bean.get(MyServiceGrpc_Bean.zig:364)
    at io.quarkus.arc.impl.InstanceImpl.getBeanInstance(InstanceImpl.java:210)
    at io.quarkus.arc.impl.InstanceImpl.access$200(InstanceImpl.java:32)
    at io.quarkus.arc.impl.InstanceImpl$InstanceIterator.next(InstanceImpl.java:246)
    at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
    at java.base/java.util.stream.ReduceOps$5.evaluateSequential(ReduceOps.java:257)
    at java.base/java.util.stream.ReduceOps$5.evaluateSequential(ReduceOps.java:248)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.count(ReferencePipeline.java:605)
    at io.quarkus.grpc.runtime.GrpcServerRecorder.hasNoServices(GrpcServerRecorder.java:197)
    at io.quarkus.grpc.runtime.GrpcServerRecorder.initializeGrpcServer(GrpcServerRecorder.java:68)
    at io.quarkus.deployment.steps.GrpcServerProcessor$build215158828.deploy_0(GrpcServerProcessor$build215158828.zig:94)
    at io.quarkus.deployment.steps.GrpcServerProcessor$build215158828.deploy(GrpcServerProcessor$build215158828.zig:40)
    at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:730)
    at io.quarkus.runtime.Application.start(Application.java:90)
    at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:92)
    at io.quarkus.runtime.Quarkus.run(Quarkus.java:61)
    at io.quarkus.runtime.Quarkus.run(Quarkus.java:38)
    at io.quarkus.runtime.Quarkus.run(Quarkus.java:106)
    at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
    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 io.quarkus.runner.bootstrap.StartupActionImpl$3.run(StartupActionImpl.java:145)
    at java.base/java.lang.Thread.run(Thread.java:834)
areredis kinbug

Most helpful comment

I think that the problem is that Vertx (which is a dependency of RedisAPIProducer) is initialized at runtime whereas the grpc components are initialized during STATIC_INIT. @michalszynkiewicz is that correct? Is there a particular reason to init the grpc endpoints during STATIC_INIT?

If we want to fix this we would have to change the beans produced by RedisAPIProducer to @ApplicationScoped which are created lazily, once needed. Or move the grpc endpoints instantiation to RUNTIME_INIT.

In any case, it's more a general problem that needs to be addressed. Therefore, I've created https://github.com/quarkusio/quarkus/issues/11337 to track this kind of problems.

All 7 comments

/cc @machi1990, @gsmet, @cescoffier

Hi @parkee thanks for reporting the issue. Do you have a reproducer so that the team can have a look?

I guess that's related to the scope being @Singleton instead of @ApplicationScoped because in other places where I have ApplicationScoped annotation it works just fine. But I guess no choice, but to use Singleton for grpc services.

I'd need @mkouba inputs on this as it look CDI related (maybe from the way the Redis client bean was setup).

Hi @machi1990
Not yet, but I can try to prepare one in 1-2 days if needed.

Hi @machi1990
Not yet, but I can try to prepare one in 1-2 days if needed.

Sure, that would be really helpful in trying to understand what's going on.

I think that the problem is that Vertx (which is a dependency of RedisAPIProducer) is initialized at runtime whereas the grpc components are initialized during STATIC_INIT. @michalszynkiewicz is that correct? Is there a particular reason to init the grpc endpoints during STATIC_INIT?

If we want to fix this we would have to change the beans produced by RedisAPIProducer to @ApplicationScoped which are created lazily, once needed. Or move the grpc endpoints instantiation to RUNTIME_INIT.

In any case, it's more a general problem that needs to be addressed. Therefore, I've created https://github.com/quarkusio/quarkus/issues/11337 to track this kind of problems.

Hm, I looked at the stack trace again and it's really weird. The gRPC endpoints are actually created during RUNTIME_INIT, and the Vertx instance should be available at that time (because this build step depends on VertxBuildItem).

.. and the Vertx instance should be available at that time (because this build step depends on VertxBuildItem).

Yeap, just checked this fact. Current the RedisProcessor does not make use of VertxBuildItem, do you think that could be related ?

I think that the problem is that Vertx (which is a dependency of RedisAPIProducer) is initialized at runtime whereas the grpc components are initialized during STATIC_INIT. @michalszynkiewicz is that correct? Is there a particular reason to init the grpc endpoints during STATIC_INIT?

If we want to fix this we would have to change the beans produced by RedisAPIProducer to @ApplicationScoped which are created lazily, once needed.

Sure. Let me prepare a PR for this.

Was this page helpful?
0 / 5 - 0 ratings