-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kotlin Coroutines Breaks Jackson Serialization #7999
Comments
@geoand ☝️ |
Thanks for reporting @sherl0cks. IIUC, co-routines don't work at all on native-image, right? If that is the case, I don't know what we can do. |
@geoand they work, but there are issues for sure. I think from a Quarkus perspective, there needs to be clear guidance to Kotlin users how to do nonblocking and async. If not coroutines, then what? Should users incorporate vert.x? Stick to completeable future without the coroutines bridge? IMO - adding this to the Kotlin guide with a strong opinion is important. Otherwise users like my team will fall into the void. That said, when coroutines work, they are great! So it would nice to also put some pressure on oracle from the quarkus side to get it working well (see the comments in the bottom of oracle/graal#366). |
Thanks for the input @sherl0cks. cc @emmanuelbernard @n1hility for input on how we should frame our suggestions in the guide |
I'll just add that out general reactive strategy is focused on Vert.x and Mutiny |
@emmanuelbernard @n1hility bumping this. It would be really nice to have clear guidance on the kotlin guide here. I'm happy to submit a PR, but I don't know how you want to frame this. Also worth noting that there is now progress with Graal and kotlin coroutines which should be released in Graal 20.1 oracle/graal#1330. The other item that came to mind is the way the AWS lambda integration is written, and my understanding is that it is blocking by design (e.g. cannot handle multiple lambda events at once, unlike the native Node.js lambda runtime). So @patriot1burke may have input there. |
On the co-routine aspect I would frame it as such. GraalVM and Kotlin co-routines are work in progress blah blah. You can use them in Quarkus apps but native executable support is hit and miss. The Quarkus way to do reactive is via Mutiny and vert.x as it brings more to the table than co-routines. See https://blog.softwaremill.com/will-project-loom-obliterate-java-futures-fb1a28508232 for a great in depth article. Whether we want to bring some co-routine friendly APIs to Mutiny (if that is even a thing), I'd defer to @evanchooly (with @cescoffier guidance). |
Vert.x actually has pretty decent support for Kotlin's co-routines already and I hope it works well on GraalVM in the future. 🤞 |
Stumbled upon this issue as I ran into a similar problem. After a bit of testing, it appears that it is not related to coroutines at all, but rather that the Jackson Kotlin module is missing or broken in the native build. If the code can be made to run without the jackson kotlin module, it works both on jvm and native. With and without coroutines. A simple example, without coroutines, that works on jvm and fails native:
The error message presented when trying the native build, is the same as one would get on jvm if the kotlin module for jackson is removed. The above code can be made to run without the kotlin module by changing the Address class to
In which case the native build also works. If the code is wrapped in a coroutine, the actual error is hidden by the kotlin reflect stuff. Hopefully you are able to get the jackson kotlin module working also in a native build :) |
Still experiencing this with Quarkus 2.4.1, Kotlin 1.5.31 using compiler target 16 and Mandrel 21.3-java17 |
Don't know if it's directly related to this ticket, but maybe helps: Native app starts, but on first operation it fails with the beloved BUT: Building with the |
@heubeck I am not sure I understand under which cases it works and which it doesn't |
Hey @geoand pardon me, I've obviously named the wrong containers and can't reproduce it right now. At a certain point in time (around begin of November 2021), the container based native image build produced binaries, that failed with the error shown above. Trying it now makes no difference, also without having an builder image configured, it defaults to Pardon me for the confusion, I assume there's no issue anymore (or never has been, and it was just me). Was there a change of the default builder image used? |
No problem at all. The name of the image itself has not changed, but the image itself has. See https://github.com/quarkusio/quarkus-images/commits/main/quarkus-native-image.yaml for more details |
It looks like this one can be closed then? |
Let's close for now. If the issue persists, comments are welcome |
Describe the bug
See https://github.com/sherl0cks/kotlin-coroutines-quarkus-graal-jackson-reproducer/blob/master/README.md
It is possible that this should be opened up in https://github.com/oracle/graal. If so, I would appreciate some assistance on that from the Quarkus team as you all have been very responsive and probably have better contacts with Graal than I do.
Expected behavior
Jackson works in coroutines like it does without coroutines.
Actual behavior
Some variation of the below exception depending on the versions of libraries:
To Reproduce
See https://github.com/sherl0cks/kotlin-coroutines-quarkus-graal-jackson-reproducer/
Environment (please complete the following information):
See https://github.com/sherl0cks/kotlin-coroutines-quarkus-graal-jackson-reproducer/
Additional context
Kotlin coroutines and graal already have known issues: oracle/graal#366
The text was updated successfully, but these errors were encountered: