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.

[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 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 https://github.com/OpenFeign/feign/issues/361#issuecomment-1273472902, 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 https://github.com/OpenFeign/feign/pull/1174 , wplong11 https://github.com/OpenFeign/feign/pull/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.