Non-blocking I/O support

[rstml]

As per our discussion with @adriancole in #24 , it would be good to add non-blocking I/O support to Feign.

This can be particularly beneficial for the scenarios with API gateways or microservice API composition.

[yairogen]

I would also like to see this supported.

[shimib]

+1

[igreenfield]

+1

[bahirsch]

+1

[codefromthecrypt]

can someone in favor of this describe the api they wish to be non-blocking? or is it simply that they want the buffered http request that's invoked synchronously, to use a non-blocking library underneath?

[igreenfield]

First we want to use lib that use nio as underlying implementation.

in manner of async API I would like to pass to the feign a callback that will handle the response. in this case the API will return void.

[codefromthecrypt]

such a proposal will end up with some severe api changes. Is anyone interested in working on this? I think there are several related issues where people ask for the same thing (which is what feign isn't designed for). Since we have OpenFeign org now, I'm happy to create a repo for someone to experiment with this. IOTW volunteer wanted!

[yairogen]

What do you mean by "which is what feign isn't designed for"?

[codefromthecrypt]

What do you mean by "which is what feign isn't designed for"?

Feign's is not designed for asynchronous invocation or zero-copy i/o.

For example, requests are buffered up-front, and all i/o operations are
blocking.
Core concepts such as interceptors and exception handlers were not designed
for asynchronous invocation.
The Client interface (required by all http backends) is a synchronous api.
Internal dispatch assumes synchronous apis, as well many try/catch blocks
associated with it.
RetryHandler assumes synchronous invocation

I could go on, but there are a lot of internals that are simpler because
synchronous is assumed. When someone changes the invocation model, they
must break api or certain things won't work. Also, depending on what's
desired
from nio, the contents of requests and responses may also need to be
changed.

Hope this helps.

ps the associated issues are #24 #25 #220 as well as others that were
closed dupe (as this probably should as it highly overlaps with #24)

[yairogen]

got it. don't think I can commit to so much work at the moment.

[daniellavoie]

Hi !

I understand Feign has not been designed with non blocking in mind. Maybe a new project is a better target. I would suggest using reactive stream as a standard way to handle IO events. First I am wondering if there is any proper reactive lightweight HTTP client out there.

[codefromthecrypt]

probably want to collaborate on https://github.com/OpenFeign/feign-vertx
for starters

On Sat, Sep 3, 2016 at 3:24 PM, Daniel Lavoie [email protected]
wrote:

Hi !

I understand Feign has not been designed with non blocking in mind. Maybe
a new project is a better target. I would suggest using reactive stream as
a standard way to handle IO events. First I am wondering if there is any
proper reactive lightweight HTTP client out there.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#361 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD61xREV5wavu_C1_M4X4DIEQp7-O2Vks5qmSDDgaJpZM4Hx9G3
.

[daniellavoie]

Thanks @adriancole sounds interesting. I'll check it out.

[phymbert]

Hello,
I submitted a new feature to support java8 streams, it will allow to handle response body asynchronously or without waiting for the full body before to process.

Although request support IO is still blocking, response input stream handling can take benefits of java8 streams.
Please vote in #586 if it solves your issue.

[shenliuyang]

+1

[beihaifeiwu]

+1

[maheshmahadevan]

+1

[oldprofile]

+1

[SerJey]

+1

[iischwuerfl]

+1

[paskos]

+1

[spencergibb]

Please stop +1 in comments and use the 'Add your reaction' feature in the original description.

[dieppa]

+1

[stv8]

+1

[dieppa]

+1

[Ged0]

+1.
Our client always cost 6~10s to wait for response from a provider. It is impossible to shorten the waiting time.

[bluntviola]

+1

[scarter93]

+1

[jmoney]

@adriancole - what are the versions of Java that OpenFeign supports? Could this not be completed by having the Client interface return CompletableFuture<Object>? Then based on the Contract and return type determined in the MethodHandler(It's called `SynchronousMethodHandler so probably needs a rename as part of this) unwraps the CompletableFuture or leaves it alone. Let me know if i'm going down the wrong track on that. I think that's the least invasive approach but is still breaking api compatibility and pins OpenFeign to jdk8+.

Alternative is to use callbacks i guess and detect them in the parameter list of the feign annotated interface and pass down to the Client. The CompletableFuture feels more clean.

[tshah010-zz]

Hi, I am using spring-cloud-starter-openfeign 2.0.1 and I am trying to make several http API calls asynchronously using org.springframework.scheduling.annotation.EnableAsync and org.springframework.scheduling.annotation.Async on methods annotated with @FeignClient. But none of the methods run async.
Is it because @FeignClient is not allowing new threads to be spun up?
Alternatively, I tried using on CompletableFuture on my FeignClient method but method never returns completed.
What's the best way to make async calls when I am using spring-cloud-starter-openfeign? Thanks for your help.

[kdavisk6]

@tshah010

Feign does not support async execution modes currently. You can't do this yet. It's on our road map.

[tshah010-zz]

@kdavisk6
thanks for quick response, but Feign documentation for Hystrix here - https://github.com/OpenFeign/feign/tree/master/hystrix clearly says we can use CompletableFuture. But my methods never complete with and without @async.
Is that what you mean by "does not support"? Thanks Kevin.

[kdavisk6]

@tshah010

I mean that Feign has not been tested or built to support use within any async or non-blocking IO execution mode. The only fully-supported mode is blocking. The one note-able exception is Hystrix, however support is limited to use cases supported by Hystrix, such as using fallbacks and the HystrixFeign builders as the request management is delegated to Hystrix.

I'm afraid that's all I can offer you right now.

[motinis]

Please take a look at the the following pull request

[wangzihaogithub]

Does the current version work with CompleteableFuture?
I can't find a use case.

[motinis]

Yes, it does. The pull request was merged after review and modifications. This enables the use of async clients with Feign.

On Mon, 28 Sep 2020 at 19:11 王子豪 ***@***.***> wrote: Does the current version work with CompleteableFuture? I can't find a use case. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEAZAM2QANCWRHY7EH5QTK3SICYTRANCNFSM4B6H2G3Q> . --

‏נשלח מ-Gmail לנייד

[michalko]

+1

[velo]

Anyone willing to write a first draft for this?

[bob-bbb]

+1

[icarodemorais]

+1

[velo]

Yeah, still waiting on volunteers to either spear head this initiative or to fund it.

[wplong11]

@velo I worked on coroutine support(#1706) with minimal effort, and now I want to support full asynchronous features, and increase the stability level of AsyncFeign from Experimental to Stable. I'm not knowledgeable perfectly about Feign, but I've seen almost all of the internal implementations of Feign, FeignX, and ReactiveFegin, and I think I can try a few.

I plan to

1. Refactor the internal implementation to support full asynchronous functionality while reusing most of the code.
2. Add full asynchronous functionality
3. Clean up AsyncFeign Api Design

[velo]

@wplong11 feel free to reach me any time you find a blocker

[wplong11]

@velo Do you have any thoughts on what additional work must be done to increase the stability level of AsyncFeign from Experimental to Stable?

What I'm thinking of is:

• Modify AsyncFeign.AsyncBuilder to extend Feign.Builder or Modify Feign to support the features of AsyncFeign
  • It is intended to be used when customizing Feign.Builder in Spring Cloud OpenFeign.
• Modify CoroutineFeign.CoroutineBuilder to extend Feign.Builder

[wplong11]

@velo @motinis Is the parameter Optional<C> requestContext important? I understand the intention(#1174), but are you actually using it? It is not being used by AsyncClient implementation.

feign/core/src/main/java/feign/AsyncClient.java

Line 41 in f71849d

CompletableFuture<Response> execute(Request request, Options options, Optional<C> requestContext);

I have some problem to integrating AsyncFeign and Feign.
It would be nice if Feign could support non-blocking asynchronous methods without AsyncFeign as well,
but it's not easy to make appropriate changes while keeping the parameters.
There's room for a little more thought, and I have something to explain more, but before that, I'd like to ask a quick question.

[kdavisk6]

It is possible to use CompleteableFuture in a blocking mode to achieve asynchronous and blocking support. Here's an example: https://github.com/OpenFeign/feignx/blob/main/core/src/main/java/feign/impl/AbstractTargetMethodHandler.java

However, for true non-blocking support, we'll need to move past CompleteableFuture and into the realm of Event Loops, like Netty, which is the most prominent form today. It's more than likely that Asynchronous, Blocking, and Non-Blocking are going to be different implementations entirely.

The idea of a Context provides information to the components executing in the processing chain that would normally be available on the same Thread in blocking scenarios. Without it, or something like it, the state of the processing chain will need to be managed elsewhere. The approach I use in feignx is start with a RequestSpecification and then move it into an immutable Request. This is very similar to how we do things today, where we start with a RequestTemplate and end with a Request. I think the key areas to deal with first are the mutability of RequestTemplate and the possible places where additional context is required.

[wplong11]

@kdavisk6

we'll need to move past CompleteableFuture and into the realm of Event Loops

Does that mean we should discard using CompletableFuture approach, and then use Event Loops?

[motinis]

It is for use cases where you need different behaviors or isolation. For example, if an API relies on cookies and those need to be separated per user. The actual implementation there would be client specific.

On Mon, 10 Oct 2022 at 17:18 Donghyeon Kim ***@***.***> wrote: @velo <https://github.com/velo> @motinis <https://github.com/motinis> Is the parameter Optional<C> requestContext important? I understand the intention, but are you actually using it? It is not being used by AsyncClient implementation. https://github.com/OpenFeign/feign/blob/f71849d38746fdc7871bf3b0609c488b36459687/core/src/main/java/feign/AsyncClient.java#L41 I have some problem to integrating AsyncFeign and Feign. It would be nice if Feign could support non-blocking asynchronous methods without AsyncFeign as well, but it's not easy to make appropriate changes while keeping the parameters. There's room for a little more thought, and I have something to explain more, but before that, I'd like to ask a quick question. — Reply to this email directly, view it on GitHub <#361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEAZAM3PW2BHFYORR3TBAALWCQXWFANCNFSM4B6H2G3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ‏נשלח מ-Gmail לנייד

[islom-kh]

Hi. any news about non-blocking feign ? @motinis @rstml

[caleb-cushing0-kr]

another yearly what's going on here?

[velo]

another yearly what's going on here?

Same as last year. Needs people to take charge and do it.

There was a massive effort by @motinis #1174 , wplong11 #1755 and many others https://github.com/OpenFeign/feign/pulls?q=async

Feel free to add your effort into this initiative. I will be here to review, request changes, merge and release.

[gromspys]

There is already library feign-reactive with non-blocking I/O: https://github.com/PlaytikaOSS/feign-reactive

[DanielYWoo]

We probably don't need it anymore since the latest JDK 21 supports virtual threads, if it blocks, let it block.

[ducnbyu]

Is there anything wrong with this solution?

Async call of a FeignClient Springboot with CompletableFuture

It seems to be working for me

[DanielYWoo]

Is there anything wrong with this solution?

Async call of a FeignClient Springboot with CompletableFuture

It seems to be working for me

this is async flavor programming model from programmer's angle, it's not a non-blocking implementation like nio/aio to improve performance under heavy load.