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

fix issue116: limit the reconnect times or duration #117

Merged
merged 7 commits into from
Apr 25, 2024

Conversation

No-SilverBullet
Copy link

@No-SilverBullet No-SilverBullet commented Apr 17, 2024

What this PR does:

1.客户端在read EOF时,停止重连维护连接池的行为
2.reconnect增加最大次数,当重连次数超过设定的连接数时,退出。
Which issue(s) this PR fixes:

Fixes #116

Special notes for your reviewer:
1.session增加了新的attribute(ignoreReconnectKey),用于标识是否重连
2.最大重连次数设定为用户设定的连接数
Does this PR introduce a user-facing change?:

NONE

…onnection times exceeds the connection numbers
client.go Outdated Show resolved Hide resolved
session.go Outdated Show resolved Hide resolved
@AlexStocks
Copy link

总体改的挺好,把 import 格式恢复下

client.go Outdated Show resolved Hide resolved
@AlexStocks AlexStocks changed the title PR of issue116(https://github.com/apache/dubbo-getty/issues/116) fix issue116: limit the reconnect times or duration Apr 17, 2024
@No-SilverBullet
Copy link
Author

@No-SilverBullet 加下我微信 Alex_Stocks

好的 import格式已经修改 编译器自己格式化了 :(

client.go Outdated Show resolved Hide resolved
@Lvnszn
Copy link

Lvnszn commented Apr 19, 2024

检验一下逻辑,然后贴一下结果就行。

@No-SilverBullet
Copy link
Author

检验一下逻辑,然后贴一下结果就行。

测试了一下,客户端的连接数设置 > 服务端可用连接数,抓包时间一分钟。使用现在的dubbo-getty1.4.9版本,TCP连接2421个,服务端TIME_WAIT 2584个。
image-20240419114522302
image-20240419113859896
使用当前PR修改后的代码,TCP连接数量大幅减少,且没有不断重连的现象。
image-20240419134431210
image-20240419134222612

@AlexStocks AlexStocks merged commit 6a6e1d1 into apache:master Apr 25, 2024
1 check passed
@No-SilverBullet No-SilverBullet deleted the fix/reconnect branch April 26, 2024 02:09
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

Successfully merging this pull request may close these issues.

Is it correct to continue to maintain the connection pool when a connection encounters an error?
3 participants