pool
pool copied to clipboard
Connection pool for Go's grpc client with supports connection reuse.
目前只支持64位CPU,不支持32位。 原因是一些常量值编译会失败 
options.go return value is a question
现在链接的时候,没法改grpc的参数,最好可以自定义grpc参数
从代码可以看出index在每次get获取连接的时候会自动加1,而且是uint32类型, 但是没有在请求后进行原子性的-1操作,会造成隐患,那就是index的值一直增加最终将会导致超出范围异常的局面。 还请你检查一下,是不是可以在conn.close的时候进行即使的-1操作会更加合理。
Java版本
看来一下你在知乎上的文章,感觉很不错,悄悄问一下,有Java版实现吗?(逃
连接池初始化时定义了MaxActive和MaxConcurrentStream,当达到MaxActive及MaxConcurrentStream时,若连接池reuse=true,那么还会使用Round-Robin算法选择已创建的连接进行数据传输,这个不是对已定义的MaxConcurrentStream矛盾了吗?是否应该追踪每一个线程的连接使用状态?
加锁吗?
``` p.RLock() current := atomic.LoadInt32(&p.current) p.RUnlock() ``` 请问一下,使用了atomic为什么还需要加锁?加锁和原子化是不是其中有一个多余了呢?
如题:应用层调用 Conn.Value() 获取到的 *grpc.ClientConn 如果执行了一个 Close 方法,这个池子里就存在了一个不可用连接。
当并发请求数从少变多时,连接池物理连接数从 `MaxIdle` 翻倍扩容,一直达到 `MaxActive`; 当并发请求数从多变少时,却需要等到逻辑连接数为 `0` 时从当前物理连接数降到 `MaxIdle`。 连接池缩容机制能否按扩容机制一般逐步下降?
[add] Add stale connection checker to replace broken connections 针对 https://github.com/shimingyah/pool/issues/11的 修复 增加了一个异步扫描连接池的协程,用于维护连接池的健康 检测到类似的“僵尸连接”(不可用连接)会清理并重新插入 如下图的test所示,创建了一个只有一个连接的连接池,直接调用grpc的close()关闭连接之后,再次获取连接池中的连接将不再可用 这是引入此次pr的结果,异步协程会清理掉“僵尸连接”并重新插入一个正常的连接