Connections & Pooling

The C# driver supports two types of connections. A single connection and a pool of connections.

A single connection is a basic TCP connection to a RethinkDB server. A pool of connections is a set of connections to a RehtinkDB cluster. The advantage of a pooled connection is redundancy and load balancing. When a connection to a node is interrupted, queries are routed to a different nodes that are readily available. Additionally, pooled connections can be used to distribute query workloads in a cluster.

Each .connect() method has an associated .connectAsync() for asynchronous establishment of a connection.

Single Connection (No Pooling)

To create a connection (without pooling):

var conn = r.connection()
            .hostname(AppSettings.TestHost)
            .port(AppSettings.TestPort)
            .timeout(60)
            .connect();
            
int result = r.now().run<DateTimeOffset>(conn);

The connection can be shared by multiple threads. The returned connection is ready to be used.

---

Note: Currently, the Java driver does not support connection pooling. The following APIs are subject to change.

Connection Pool (Round-Robin)

To create a connection pool using a round-robin node selection strategy:

var conn = r.connectionPool()
            .seed(new[] {"192.168.0.11:28015", "192.168.0.12:28015"})
            .poolingStrategy(new RoundRobinHostPool())
            .discover(true)
            .connect();

int result = r.now().run<DateTimeOffset>(conn);

The connection can be used by multiple threads. The .connect() method returns when at least one connection to a cluster node has been successfully established.

The .seed() method seeds the driver with a set of well-known cluster nodes. If .discover(true), the driver attempts to discover new hosts when they are added to the RethinkDB cluster. It does this by setting up a change feed on a system table and listens for changes.

The .poolingStrategy(new RoundRobinHostPool()) establishes a round-robin node selection strategy when sending queries.

There are two construction arguments for RoundRobinHostPool that control reconnection intervals. Initially, when a host goes down the pool supervisor will wait retryDelayInitial time span before reconnecting to the node. If the reconnect fails, the retry delay is doubled. Doubling of the retry delay reaches a maximum when the retry delay is greater than retryDelayMax; thereafter, every subsequent retry is retryDelayMax.

• retryDelayInitial - The initial retry delay when a host goes down. How long to wait before immediately retrying the connection. Default is 30 seconds.
• retryDelayMax - The maximum retry delay. Default is 15 minutes.

---

Connection Pool (Epsilon Greedy)

Another connection pooling strategy is Epsilon Greedy. Epsilon Greedy is an algorithm that allows the pool to not only to track failure state, but also to learn about "better" options in terms of speed, and to pick from available hosts based on how well they perform. This gives a weighted request rate to better performing hosts, while still distributing requests to all hosts (proportionate to their performance).

A good overview of Epsilon Greedy is here http://stevehanov.ca/blog/index.php?id=132

To setup an epsilon greedy host pool:

var conn = r.connectionPool()
       .seed(new[] { "192.168.0.11:28015" })
       .poolingStrategy(
           new EpsilonGreedyHostPool(decayDuration, EpsilonCalculator.Linear())
        )
       .discover(true)
       .connect();

• decayDuration - The amount of time to cycle through all EpsilonBuckets (0...120). This decay duration is divided by EpsilonBuckets (default: 5 min / 120 buckets = 2.5 seconds per bucket). IE: The average will be taken every decayDuration/EpsilonBuckets seconds. To use the default decayDuration pass null for this argument.
• EpsilonCalculator - Given the weighted average among EpsilonBuckets slot measurements, calculate the host's EpsilonValue using EpsilonCalculators.Linear/Logarithmic/Polynomial(exponent).