blocking API

[epgsql]

blocking API

[mdaguete]

+1

[seth]

I'd be interested to hear some of the ways you are using pooler and the reasons for wanting the blocking approach.

In writing pooler, I chose to avoid the blocking approach because it both simplifies the implementation and makes it easier to detect an overloaded pool (which in a blocking implementation can hide as added latency).

That said, I'm not opposed to enhancing the pool to make it more useful to more folks. But want to better understand the goals. So. Can you provide some background on why you'd like a blocking approach? Are there other features that are keeping you with pooler instead of poolboy?

[rlipscombe]

We're currently using poolboy, but I'm evaluating pooler as an alternative. We have a specific case where our clients don't particularly care if a database query takes a long time (they'll wait, and they don't timeout). If, however, we return an error or otherwise drop the connection, the client will disconnect and come back immediately. This is expensive (reconnect incurs a whole bunch of DB queries, which, as you can imagine, just snowballs).

Thus, it's better for our particular case, if DB congestion causes blocking (even at the expense of extra latency), rather than errors.

We'd be prepared to monitor the increased latency by looking at reported metrics. As it stands, we have metrics wrappers for poolboy that report the time taken to check out a pool member, so that's not a big problem for us.

[seth]

@rlipscombe thanks for the background. I can see the benefit and am considering adding the queue feature.

Though also curious, since you are currently using poolboy and that lib has the queuing, what's driving the evaluation of pooler?

[rlipscombe]

A couple of reasons:

Poolboy doesn't have a mechanism for temporarily keeping idle workers around; pooler does. Including this functionality in poolboy has been rejected (see devinus/poolboy#30), but that issue includes various ways to implement this. In the end, I went for a variation of the technique that Zotonic uses: https://github.com/zotonic/zotonic/blob/master/src/db/z_db_pgsql.erl#L91-117

Pooler has better support for reporting metrics through (e.g.) folsom; I think that there are a couple of open issues for this in poolboy, and it wasn't that hard to implement ourselves (though you have to be careful about decrementing waiting/active counters if the caller crashes), but having it built in to the pooling library would have been useful.

Also, until poolboy 1.2.2, workers were stored in a queue, meaning that older workers (from the original pool) were returned before newer (overflow) workers; we think that this could lead to disconnect/connect churn (e.g. when talking to postgresql) when operating in pool overflow.

The other feature missing from poolboy (I haven't checked pooler yet) is the ability to resize the pool at runtime. We would find that useful to avoid restarting things in production.

Oh, and the pool groups feature in pooler looks interesting, though I've not really played with it much.

At this point, we'll probably be sticking with poolboy, but I hope this explains why I was evaluating pooler as an alternative.

[seth]

Hi all,

Thanks to @oferrigni, pooler now has optional queuing when all members are in use. See tag 1.3.0.

[arjan]

Nice!

[redink]

Long-awaited, thanks!