GRPC -Streamobserver -Threads hat keinen CDI -Kontext in Jakarta ee Open Liberty Server ⇐ Java

[Anonymous]

Ich habe einen offenen Liberty-Server (23.0.0.9), der Jakarta 10 mit CDI 3.0 ausführt, mit dem ich ein GRPC-Kanal mit Push-Pull-basierten Streams auf einem externen Server ausführe. Ein ManagedServiceExecutor wird dem Kanal geliefert, der die Streams lascht, die die vom Container verwalteten Threads theoretisch verwaltet und CDI -Kontext haben. Es scheint nicht der Fall zu sein oder mein Verständnis dafür ist falsch. Die Streams werden auf normal

Code: Select all

ManagedChannelBuilder.forAddress(grpcHost, port)
.enableRetry()
.keepAliveWithoutCalls(true)
.executor(executorService)
.build();

PubSubGrpc.newStub(channel).withCallCredentials(credentials).subscribe(responseObserver);
< /code>
und der ResponseBserver wie folgt < /p>
public StreamObserver getDefaultResponseStreamObserver() {

return new StreamObserver() {

@Override
public void onNext(FetchResponse fetchResponse) {
for (ConsumerEvent ce : fetchResponse.getEventsList()) {
try {

injectedBean.methodThatRequiresCDI(ce);  // This method does not work

} catch (Exception e) {
logger.info(e.toString());
}

}

if (fetchResponse.getPendingNumRequested() == 0 && subscriptionReference.isActive()) {
subscriptionReference.getRequestObserver().onNext(FetchRequest.newBuilder().setNumRequested(100).build());
}

}

@Override
public void onError(Throwable t) {
subscriptionReference = subscriptionReference.closedSubscription();
logger.info("big bad error :(");

}

@Override
public void onCompleted() {
subscriptionReference = subscriptionReference.closedSubscription();
logger.info("Call completed by server. Closing AsyncSubscriptionFactory. Goodbye.");
}
};

Der "methodeTheatRequirescdi" ruft CDI.Current () nachgeschaltet in einer anderen Bibliothek auf, die ich nicht ersetzen kann, was eine illegale StateException wirft. Um die Frage nicht zu verschmutzen. Wann immer ONNEXT () durch eine Antwort aus dem GRPC-Stream aufgerufen wird, funktioniert CDI.Current () nicht und kein Kontext ist aktiv.

Code: Select all

java.lang.IllegalStateException: Could not find deployment
at com.ibm.ws.cdi.impl.AbstractCDIRuntime.getCDI(AbstractCDIRuntime.java:163)
at jakarta.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:78)
at jakarta.enterprise.inject.spi.CDI.current(CDI.java:65)
at ----.subscribe.control.ExampleSubscriber$1.onNext(ExampleSubscriber.java:107)
at ----.subscribe.control.ExampleSubscriber$1.onNext(ExampleSubscriber.java:100)
at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(ClientCalls.java:466)
at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
at io.openliberty.grpc.internal.client.monitor.GrpcMonitoringClientCallListener.onMessage(GrpcMonitoringClientCallListener.java:59)
at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
at io.grpc.ForwardingClientCallListener.onMessage(ForwardingClientCallListener.java:33)
at io.grpc.internal.DelayedClientCall$DelayedListener.onMessage(DelayedClientCall.java:447)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInternal(ClientCallImpl.java:661)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(ClientCallImpl.java:646)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
at com.ibm.ws.threading.internal.PolicyTaskFutureImpl.run(PolicyTaskFutureImpl.java:762)
at com.ibm.ws.threading.internal.PolicyExecutorImpl.runTask(PolicyExecutorImpl.java:1172)
at com.ibm.ws.threading.internal.PolicyExecutorImpl$GlobalPoolTask.run(PolicyExecutorImpl.java:198)
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)

Die Methode läuft in jedem anderen Kontext gut (wie erwartet) gut, beispielsweise als Teil der JAX-RS-Anforderung oder durch einen MDB, solange CDI.Current () funktioniert und BeanManager auf die Aufruf der oben genannten Methode zugreifen kann. fein. Im Moment ist es applicationscoped und ich möchte es so halten. Ich beabsichtige, viele verschiedene Bohnen aufzurufen, und ich habe nicht das Bedürfnis, sie alle in EJB -Singletons zu ändern. Dies funktioniert auch und CDI.Current () wird in dieser Methode und anschließend in der nachgeschalteten Methode gut ausgeführt. Der Nachteil ist, dass es eine seltsame Indirektion hinzufügt und sich wie ein Hack anfühlt, damit es funktioniert. Auch schwieriger zu neu zu übertragen, wenn es viele verschiedene Arten von Abonnements gibt, müsste ein Ereignis abfeuern und für jeden eine @Obserserves -Methode hinzufügen. Ich hatte erwartet, dass ich dieses Problem nicht hätte, solange ich den Container die Threads erstellen lasse, die die Aufgaben ausführen, die ich mit einem ManagEtexecutorService einreiche. Haben auch unter Verwendung eines ManagedThreadFactory getestet, die Aufgabe an einen ManagedThreadManager im OnNext () -Method übermittelt und @ActivateRequestContext und mehrere andere Optionen ohne Verfügbarkeit hinzugefügt.