pool icon indicating copy to clipboard operation
pool copied to clipboard

Connection pool for Go's grpc client with supports connection reuse.

Results 10 pool issues
Sort by recently updated
recently updated
newest added

目前只支持64位CPU,不支持32位。 原因是一些常量值编译会失败 ![image](https://user-images.githubusercontent.com/1747852/179485730-74695962-3291-48fa-974a-58def29e9dab.png)

现在链接的时候,没法改grpc的参数,最好可以自定义grpc参数

从代码可以看出index在每次get获取连接的时候会自动加1,而且是uint32类型, 但是没有在请求后进行原子性的-1操作,会造成隐患,那就是index的值一直增加最终将会导致超出范围异常的局面。 还请你检查一下,是不是可以在conn.close的时候进行即使的-1操作会更加合理。

看来一下你在知乎上的文章,感觉很不错,悄悄问一下,有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的结果,异步协程会清理掉“僵尸连接”并重新插入一个正常的连接