Skip to content
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

introduce mode where asynchrony is determined solely from method's return type #428

Closed
Ladicek opened this issue May 31, 2021 · 0 comments · Fixed by #453
Closed

introduce mode where asynchrony is determined solely from method's return type #428

Ladicek opened this issue May 31, 2021 · 0 comments · Fixed by #453
Milestone

Comments

@Ladicek
Copy link
Contributor

Ladicek commented May 31, 2021

Currently, we determine whether a method is asynchronous (for the purpose of fault tolerance) based on an annotation (MP FT @Asynchronous or SRye Common @Blocking/@NonBlocking), together with the method's return type. This is to maintain close correspondence to MP FT.

However, there's a lot of libraries and APIs, especially in Quarkus, that determine asynchrony solely from method's return type: MP RestClient, MP Reactive Messaging, JAX-RS, etc. Fault Tolerance is an outlier.

We could introduce a mode (based on a global config property) that doesn't require the annotation and just looks at the return type. That would be off by default (there's a test in MP FT TCK that verifies that a CompletionStage-returning method without @Asynchronous is handled synchronously), but could be turned on by a user.

Quarkus could potentially turn it on by default, and users could turn it off. That would of course technically be a breaking change, but probably for the better.

@Ladicek Ladicek added this to the 5.2.0 milestone Jul 1, 2021
@Ladicek Ladicek changed the title introduce mode where asynchrony is determined solely from method's return type (?) introduce mode where asynchrony is determined solely from method's return type Jul 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant