Open venkata2395 opened 3 weeks ago
@venkata2395 I fear we need a full reproducer for this one. We cannot reproduce it.
Another occurrence, but this time when calling ObjectIO.ping()
:
2024-11-13 10:04:31,661 ERROR [org.pro.ser.cat.ObjectStoresHealthCheck] (executor-thread-1) Failed to ping warehouse 'nessie-playground', error ID f814a805-3e4d-4101-8e9f-b339d684d7a2: jakarta.enterprise.context.ContextNotActiveException: RequestScoped context was not active when trying to obtain a bean instance for a client proxy of PRODUCER_METHOD bean [class=org.projectnessie.server.catalog.CatalogProducers, id=IoYBgW3_kRGTU-USRbZWANKDXPA]
- you can activate the request context for a specific method using the @ActivateRequestContext interceptor binding
at io.quarkus.arc.impl.ClientProxies.notActive(ClientProxies.java:70)
at io.quarkus.arc.impl.ClientProxies.getSingleContextDelegate(ClientProxies.java:30)
at org.projectnessie.catalog.files.api.CatalogProducers_ProducerMethod_objectIO_Ed95GkFIhtTZERiabosXvHelB7Q_ClientProxy.arc$delegate(Unknown Source)
at org.projectnessie.catalog.files.api.CatalogProducers_ProducerMethod_objectIO_Ed95GkFIhtTZERiabosXvHelB7Q_ClientProxy.ping(Unknown Source)
at org.projectnessie.server.catalog.ObjectStoresHealthCheck.call(ObjectStoresHealthCheck.java:61)
This is strange because it means that the request scope was active when calling LakehouseConfig.catalog()
but not when calling ObjectIO.ping()
.
I wonder if ObjectStoresHealthCheck
shouldn't be annotated with @RequestScoped
instead of @ApplicationScoped
.
Currently, ObjectStoresHealthCheck
is @ApplicationScoped
, but its config object are proxies that implement the @RequestScoped
logic. When the proxies are accessed within a request context they return correct data.
That is how it normally works. So, my impression is that it's a Quarkus bug rather than application code bug.
That said, changing the top-level obj to @RequestScope
might help as a "workaround", but I wonder whether it might be preferable to upgrade Quarkus first.
Issue description
We noticed below issue when using Nessie snapshot version - 0.99.1. This appears only during the nessie startup log but works fine with the read/write operations later when pod is ready. Please provide insights on how to overcome this issue.
Health check log provided below: