一个stream卡住导致其他连接也无法建立

[pavel2003]

Describe the bug (描述bug)

client和server端建立stream用于传输数据，建好后直接sleep，此时重启server

这个时候client的其他线程再和这个server端建立stream的时候，报 [E112]Not connected to

查看对应socket状态

This is a broken Socket

version=1
shared_part={
ref_count=1
socket_pool=null
creator_socket=1244
in_size=71033083
in_num_messages=8986
out_size=139334
out_num_messages=3799
}
nref=3
nevent=1

感觉是sleep的线程通过stream使用socket的引用计数+1，在sleep结束，close stream前，这个socket无法回收

后续建立stream的时候都使用这个socket，但是这个socket是broken的

To Reproduce (复现方法)

Expected behavior (期望行为)
这种情况是否应该强制回收stream和socket

Versions (各种版本)
OS:
Compiler:
brpc:
protobuf:

Additional context/screenshots (更多上下文/截图)

[chenBright]

连接断开后，client会close stream的。on_closed执行了吗？

[pavel2003]

分析了流程，应该是我们使用的有点问题

为了流控，我们在stream的on_recevie函数中做了事件等待，由于故意手动的sleep导致on_recevie的队列满了后，会等待着

此时重启server后，client端会收到socket断链的时间，reset所有stream

但是reset stream是通过调用Stream::BeforeRecycle ---> execution_queue_stop

由于Stream::Consume需要被调用才能处理stop事件，清理底层的socket，由于之前的Consume还阻塞在流控对应的事件中，而对应的事件由于故意的sleep导致无法触发，就陷入死锁了

这种有没有好的办法呢？
1）需要做流控
2）一个stream的处理逻辑中可能会卡死（处理时间非常长的情况）
3）此时重启机器

清理socket操作是不是不要依赖Stream::Consume的调用？ 这个会调用用户自己设置的on_recevie函数，一旦卡住，就影响了整个底层的清理功能了

[chenBright]

没办法，实现上必须保证Stream析构了才能对Socket进行健康检查或者回收。