Redesign of the connpool module

[Konstantin Nazarov]

Abstract:

I believe zone support and monitoring have nothing to do with connection pooling. They are artifacts of leaky abstractions of the sharding module. I propose to redesign the API of connpool to conform to a Single Responsibility Principle, e.g. pooling connections to tarantool instances. Everything else should be moved to other modules.

Proposed API

local connpool = require('connpool').new()

-- conn1 is a net.box conneciton object
local conn1 = connpool.connect("user:pass@localhost:3301")

-- conn2 will be the same net.box object
local conn2 = connpool.connect("user:pass@localhost:3301")

conn1:close()

-- conn3 is the new net.box object
local conn3 = connpool.connect("user:pass@localhost:3301")

Configuration options

connpool.ttl = 200 -- number of seconds after which stale connections will be closed
connpool.table_size = 1000 -- number of connections in connpool table (LRU)

Expected client behavior

• Every time the client app needs a connection, it does connpool.connect()
• If the connection is in the pool, the client will receive it immediately
• The client must then check for all errors when doing requests through that connection
• If the connection fails during one of the client requests, the client should re-establish it with connpool.connect()

[Roman Tsisyk]

Hi,
I agree that zones support is a "leaked abstraction" from https://github.com/tarantool/shard and they should be removed from connpool and integrated back to shard. In this case connpool will have the only feature - pooling connections to tarantool instances. Since our net.box reconnects automatically, connpool module will be a simple Lua table with net.boxes. I don't think that we need a wrapper for Lua table (10-50 LLOC) as a separate module, so I propose to remove connpool completely.