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 notifications@github.com
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.