Open madocx opened 10 months ago
@scrocquesel are you aware of this issue?
@scrocquesel are you aware of this issue?
No, could it be move to the quarkiverse aws repo ?
@madocx is it a regression from a previous version ?
What also fix the issue is to force running the completionStage back to the initial thread context.
public Uni<Fruit> get(String name) {
Key partitionKey = Key.builder().partitionValue(name).build();
// capture context
Context context = Vertx.currentContext();
return Uni.createFrom().completionStage(() -> fruitTable.getItem(partitionKey))
.emitOn(command -> context.runOnContext(x -> command.run())) // Restore the context
.call(result -> Uni.createFrom().item(logResults(result)));
// .invoke(result -> Uni.createFrom().item(logResults(result)));
}
I don't have enough knowledge of how quarkus dev mode manage Thread and TCL to see what going on. But it certainly comes from the fact that aws crt is creating thread from the JNI context.
@scrocquesel I'm happy to move it there if you believe that's where it belongs. The error was coming from QuarkusConfigFactory so figured I'd start here, but if its a problem with the extension that definitely makes sense.
This code was running on 2.16.9.Final before, but was not using the awc-crt http client at that time.
Could stay here, it's more related to quarkus intrinsics
I had the same problem working with the quarkus-mongo-client. My code was:
getCollection().insertOne(doc)
.map(checkDocResult(doc));
Adding the -Dmutiny.disableCallBackDecorators=true
system property solves the problem. But it may cause another problem if you are working with context on mutiny.
I've made some progress on this one and believe it is related to the one fixed for S3CRT by wrapping the FUTURE_COMPLETION_EXECUTOR to restore a previously captured TCCL (PR linked above). I'll explore what can be done for aws-crt in the quarkus-amazon-service extension, as it should be the same solution.
If you don't use the extension, I guess you will have to do something similar as I'm not aware of a way to fix that globally at the quarkus core level. The issue is that the completion callback is called from a JNI thread, and the classloader is not set automatically for those threads. I don't have enough knowledge on how threading works in Java regarding JNI. I know @stuartwdouglas did some magic with the default ForkJoinPool, but I guess AWS SDK is creating its own thread pool for processing the request, and we don't have control over it.
Describe the bug
Quarkus dev mode classloader seems to have issues with the aws-crt http client that can be used with dynamodb. Everything works perfectly when compiled natively, but in dev mode get a strange QuarkusConfigFactory error. Looking at some old threads with similar errors, it seems like classloading is typically the culprit.
The issues appear to be limited to certain mutiny methods, as using "invoke" vs "call" does not produce the error.
Expected behavior
Operation returns successfully, just as it does when using netty-nio http client in dev mode, or the same as it does when using aws-crt client in native executable.
Actual behavior
Below error occurs when attempting to work with the Uni created from the aws sdk's response. Same thing occurs if using their SDKPublisher methods.
How to Reproduce?
Reproducer: https://github.com/madocx/quarkus-reproducer
To eliminate error, either change http client to netty-nio, or replace call inocation with invoke.
Output of
uname -a
orver
Linux a-20b6iv5ait3pg 5.15.122-77.145.amzn2.x86_64 #1 SMP Tue Aug 1 20:49:01 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
openjdk version "11.0.14.1" 2022-02-08 OpenJDK Runtime Environment Temurin-11.0.14.1+1 (build 11.0.14.1+1) OpenJDK 64-Bit Server VM Temurin-11.0.14.1+1 (build 11.0.14.1+1, mixed mode)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.2.4.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)apache-maven-3.9.4 (also occurs with older versions)
Additional information
No response