shimingyah/pool

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

Pool

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

Pool provides additional features:

• Connection reuse supported by specific MaxConcurrentStreams param.
• Failure reconnection supported by grpc's keepalive.

Getting started

Install

Import package:

import (
    "github.com/shimingyah/pool"
)

go get github.com/shimingyah/pool

Usage

p, err := pool.New("127.0.0.1:8080", pool.DefaultOptions)
if err != nil {
    log.Fatalf("failed to new pool: %v", err)
}
defer p.Close()

conn, err := p.Get()
if err != nil {
    log.Fatalf("failed to get conn: %v", err)
}
defer conn.Close()

// cc := conn.Value()
// client := pb.NewClient(conn.Value())

See the complete example: https://github.com/shimingyah/pool/tree/master/example

Reference

• https://github.com/fatih/pool
• https://github.com/silenceper/pool

License

Pool is under the Apache 2.0 license. See the LICENSE file for details.

pool's Issues

Java版本

看来一下你在知乎上的文章，感觉很不错，悄悄问一下，有Java版实现吗？（逃

加锁吗？

p.RLock()
current := atomic.LoadInt32(&p.current)
p.RUnlock()

请问一下，使用了atomic为什么还需要加锁？加锁和原子化是不是其中有一个多余了呢？

自定义grpc参数

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

连接池中连接管理与使用的问题

连接池初始化时定义了MaxActive和MaxConcurrentStream，当达到MaxActive及MaxConcurrentStream时，若连接池reuse=true，那么还会使用Round-Robin算法选择已创建的连接进行数据传输，这个不是对已定义的MaxConcurrentStream矛盾了吗？是否应该追踪每一个线程的连接使用状态？

兼容32位CPU

目前只支持64位CPU，不支持32位。

原因是一些常量值编译会失败

options.go return value is a question

options.go return value is a question

连接池扩缩容机制

当并发请求数从少变多时，连接池物理连接数从 MaxIdle 翻倍扩容，一直达到 MaxActive；
当并发请求数从多变少时，却需要等到逻辑连接数为 0 时从当前物理连接数降到 MaxIdle。

连接池缩容机制能否按扩容机制一般逐步下降？

代码存在一个问题index 请求的标记

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

Conn.Value() 获取到的 *grpc.ClientConn 如果执行了一个 Close 方法，这个池子里就存在了一个不可用连接

如题：应用层调用 Conn.Value() 获取到的 *grpc.ClientConn 如果执行了一个 Close 方法，这个池子里就存在了一个不可用连接。