当max_connections 调小，对应闲置的tcp链接并没有被释放

[kaede11]

`

CoTask ServiceGroup::checkConnectionsRegularly() {

while (true) {

XLOGF(DBG9, "server@{} check connections", fmt::ptr(this));

ioWorker().checkConnections(Address{0, 0, Address::RDMA}, config_.connection_expiration_time());

co_await folly::coro::sleep(config_.check_connections_interval().asMs());

}
}

`
代码中只针对RDMA进行了链接释放，并没有对TCP 链接进行释放。而实现上，RDMA是需要TCP来传递device信息

[SF-Zhou]

We do not consider TCP connections necessary to actively release. There are cases where RDMA connections are broken on the client side while the server side remains unaware, so periodic cleanup is required.

[kaede11]

We do not consider TCP connections necessary to actively release. There are cases where RDMA connections are broken on the client side while the server side remains unaware, so periodic cleanup is required.

为什么不考虑？比如一个场景，应对大促，业务侧需要临时调大max_connections，大促过后，在调整回来，这会导致这些链接还占用资源，也属于一种资源泄漏吧？

[kaede11]

We do not consider TCP connections necessary to actively release. There are cases where RDMA connections are broken on the client side while the server side remains unaware, so periodic cleanup is required.

client侧确实存在这个问题,尤其在storage node平滑退出场景，可以让client提前感知broken connection，即滚动升级对业务无感

[lcxywfe]

We do not consider TCP connections necessary to actively release. There are cases where RDMA connections are broken on the client side while the server side remains unaware, so periodic cleanup is required.

为什么不考虑？比如一个场景，应对大促，业务侧需要临时调大max_connections，大促过后，在调整回来，这会导致这些链接还占用资源，也属于一种资源泄漏吧？

因为3fs本身就是为了training的场景设计的