能否给volo-thrift的客户端添加一个连接池配置，限制最大连接数

[RFurina]

你好，我在使用volo-thrift编写一个数据库客户端，并发数非常高，volo-thrift给单个数据库节点创建了上万个连接，导致系统资源耗尽。我已经开启了多路复用选项，但事实是仅有少量连接传输数据，大部分连接处于TIME_WAIT状态。

[PureWhiteWu]

你好，根据 conn pool 的设计，只有当连接池中没有空闲连接时，才会新建连接。
你的场景下，并发数和延迟大概是多少呀，会导致创建这么多连接？

[RFurina]

我配置的rpc超时是30ms,数据库大概10ms不到能返回数据。但读数据库的qps可以达到几万以上

[PureWhiteWu]

如果限制了最大 conn，会导致请求积压，这个是预期之中的行为么？

[RFurina]

我认为应该允许请求适当等待，如果没有可用连接应该被取消。但我现在想了想，可能我遇到的是一个bug，而不是我真的需要这个功能。因为大部分的连接处于TIME_WAIT的状态，导致系统资源耗尽。因为哪怕20000的QPS也正在传输数据的连接也就几百来个，数万的TIME_WAIT应该是不正确的

[PureWhiteWu]

你是用的是 multiplex 模式，还是 pingpong 模式？

[RFurina]

两种模式都使用过了，都出现这个问题。

[PureWhiteWu]

在最新的 main 中优化了，可以试试看是否解决了问题

[RFurina]

非常感谢，这个问题成功得到了解决。但貌似出现了另一个bug，当断网时，rpc方法将不会返回，直到网络恢复。并且TimeoutLayer看起来没有发挥作用，所有请求在网络恢复后被发送并响应返回了迟来的正确结果，并没有触发超时。

[PureWhiteWu]

这个问题看起来有点奇怪，你有设置 timeout 么？
从原理上来说，这里的修改不会影响到 timeout layer，因为 timeout layer 是外层的行为，而这段逻辑在内层。

[RFurina]

我只设置了连接超时和读写超时，其他都没设置，在此前的版本中会报transport err

[PureWhiteWu]

那是符合预期的，你可以设置一下 rpc timeout，应该能解决你的问题

[RFurina]

确实是不会卡住了，但好像和此前版本不太一样，此前版本会报Transport下的ErrorKind::TimedOut。现在报的是Application的INTERNAL_ERROR RPC超时。这也是符合预期的吗

[PureWhiteWu]

你如果是 multiplex 的话，是符合预期的