You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: