Closed doctorpangloss closed 4 years ago
Looks like something in Jackson is triggering the need for reflection. Will investigate, thanks. In the meantime you can probably workaround by running the tracing agent on the project to identify what is using reflection. See https://medium.com/graalvm/introducing-the-tracing-agent-simplifying-graalvm-native-image-configuration-c3b56c486271
Tracing didn't change the story here unfortunately.
I'm getting this error posting to paths that just return and accept nothing. Also, I'm not sure why it's trying to encode JSON here, in a request, it hasn't gotten to the writing response part. It seems like there is a lot of indirection. I am trying now with RC1. But I think there's a lot that might be buggy with Introspection and Jackson.
If you can isolate it to a smaller easy to reproduce example app we can take a look
PS it seems to be caused by the fact that the app has the JAXB module on the classpath https://github.com/FasterXML/jackson-modules-base/tree/master/jaxb
Which frankly we have not tested not supported so far on GraalVM
This seems to have fixed the issue:
var application = Micronaut.run(Application.class);
var objectMapper = application.getBean(ObjectMapper.class);
objectMapper.setAnnotationIntrospector(new JacksonAnnotationIntrospector());
This basically removes the JaxB annotation inspector that the error message is telling us about. I'm not sure how it gets in there though, I think that's the bug.
I'll post a clear reproduction.
I'm getting closer to the underlying issue. It may be related to Graal's tracing agent putting service loader definitions in for the JaxB annotation processor.
{"pattern":"META-INF/services/com.fasterxml.jackson.databind.Module"}
The solution I posted here https://github.com/micronaut-projects/micronaut-core/issues/2611#issuecomment-583180870 will be sufficient for me!
Task List
Summary
A complex project throws an exception in the
JaxbAnnotationIntrospector
class when a POST request is made, regardless to which path that POST is made. The complexity of the project may be a red herring.Background
Spellsource is a video game server. Graal and Micronaut are being investigated to support Spellsource's computer opponent's AI move computation, deploying it as a serverless / lambda function instead of running in the same JVM as the rest of the multiplayer services to reduce memory usage.
To do this, it is using Micronaut as the harness around the code that actually computes the computer opponent's moves.
There are three interacting parts that probably contribute to this error:
native-image
compiled references uninstrumented JARs (i.e. works around #477) and the error reported in that issue re: fiber-instrumented bytecode does not occur here. Nonetheless since it referencesquasar-core
it's possible the problematic bytecodes are being compiled nonetheless and causing a different error. The game engine is tested in both fiber and native threads, and the AI opponent code does not appear to flow into a fiber-instrumented call.micronaut
.native-image
passes testsThe project is used in production for a few years now and has a healthy and active user community. Spellsource is developed by Hidden Switch, an experimental game studio. We take pride in trying out new technologies and we have a long history with Java as a games backend.
Expected Behaviour
The request should succeed like it does in the tests without
native-image
. Simply rungradle micro:test
to verify this behaviour.Actual Behaviour
CURL-ing a
native-image
built docker container will instead cause a repeating exception and a hung server.Environment Information
Example Application
https://github.com/hiddenswitch/Spellsource-Server.git
Steps to Reproduce
Clone the repository. with
git clone https://github.com/hiddenswitch/Spellsource-Server.git
. In its root...Executing the exact curl request from tests:
Repeating error in the docker container (you will have to stop the container with
docker stop
):