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

Support for reconnecting to different host with TcpClient #302

Closed
rstoyanchev opened this issue Mar 1, 2018 · 8 comments
Closed

Support for reconnecting to different host with TcpClient #302

rstoyanchev opened this issue Mar 1, 2018 · 8 comments

Comments

@rstoyanchev
Copy link
Contributor

Based on an older request (originally reactor/reactor#412), we still have an outstanding request to be able to reconnect to a different host. While the retry operator could be used with the current API, I'm not sure how to combine that with reconnecting to a different host.

For more on the underlying motivation see https://jira.spring.io/browse/SPR-12452.

@smaldini
Copy link
Contributor

smaldini commented Mar 1, 2018

Each retry will trigger a new Supplier<InetSocketAddress>#get. It is segregated so any stage downstream can safely retry without dealing with providing a new address. A Load Balancing supplier could be implemented as an extra facility.

@filiphr
Copy link

filiphr commented Mar 1, 2018

I didn't reply back into the SPR ticket. Honestly, I don't quite get what the older reactor/reactor#412 issue is about. What I did now is to use my own implementation of the Reactor2TcpClient which supports the Supplier<InetSocketAddress>. And I have a round robin supplier (not sure whether that would scale, but I suppose if one is done it will retry the next one). I am talking about the 4.3.x branch. Haven't looked into 5.0. From my understanding of the code I've looked even the 4.3.x branch uses Supplier<InetSocketAddress> and it calls #get on each retry.

From what I could quickly see ReactorNettyTcpClient should be a replacement for the Reactor2TcpClient. With this one it seems it is easier to provide ClientOptions.Builder that would use a Supplier<InetSocketAddress>.

@rstoyanchev
Copy link
Contributor Author

Ah, I see now. reactor/reactor#412 was about an issue with the Reconnect strategy, passed into the open method, which ignored the IP address. What you're using is the Supplier<InetSocketAddress> on TcpClientSpec. Assuming you've confirmed that works, I'll update SPR-12452 and we can add your suggestion to 4.3.x.

@rstoyanchev
Copy link
Contributor Author

Resolving this since it sounds like it should just work in the latest Reactor Netty.

@georgeyanev
Copy link

@rstoyanchev What is the proper way to configure TcpClient in order to reconnect to the same host in case the server has disconnected? I didn't find methods like open method or Reconnect interface in current reactor-netty code base.

@alexe13
Copy link

alexe13 commented Feb 27, 2019

@georgeyanev I was struggling with reconnect too. Finally I made it work using observe() method, see following gist for example: https://gist.github.com/alexe13/c4afef6be7309447b690cfcd2cc60695
I'm not sure if this is the correct way to handle automatic reconnects, but reactor-netty documentation is pretty scarce so that's better than nothing I guess.

@georgeyanev
Copy link

georgeyanev commented Mar 2, 2019

@alexe13 That is interesting, I will try this. After all if there is no response here we have to manage it ourselves.

@violetagg
Copy link
Member

@georgeyanev Something similar to the snippet above (provided by @alexe13) can be achieve with

https://github.com/reactor/reactor-netty/blob/master/src/main/java/reactor/netty/Connection.java#L282

See the test cases above.

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

No branches or pull requests

6 participants