Max & idle connection lifetime

[Sytten]

Hi!
I was wondering if you plan to implement maximum and idle lifetimes in the pool? Right now it seems like the checking for bad connections is done lazily at connection fetch. I know for example that sqlx runs a low priority task to check the health of connections in the background and respect the max/idle lifetimes.
Thanks!

[bikeshedder]

This feature is partly described in #167

I don't want this feature to be a builtin feature of deadpool but rather add some hatches for 3rd party code to inspect and manipulate the pool internals.

So yes, it is a planned feature. I just haven't found the time to properly implement it. Some time ago I added an experimental version of this feature (see #131), but I didn't like the way it turned out. That's why it never got merged and is just there to remind me that some serious thought needs to be done to get this right.

My current thoughts on how this could be implemented is the following:

• Add a Pool::purge method that takes a predicate function to decide whether to remove an object from the pool or not.
• Add a Pool::try_create method which behaves similar to Pool::get but only creates new objects and returns None if the max_size has already been reached.
• Add a configurable return callback that can intercept the return of objects to the pool. More advanced implementations could spawn a task and recycle the object ahead of time.
• Add a Object::ready boolean which can be used to check if an object is ready to be used or needs recycling prior its next use.

With those two methods, the return callback and Object::ready flag it should be rather trivial to write a background tasks that purges old objects from the pool and/or creates objects ahead of time.

[Sytten]

That seems like a good plan.
I would still provide some implementations like one with the background task.

One thing to consider is how to avoid locking the whole inner when the checking is done. I know the SQLx pool has some decent design for that where the checker task yields to the get of connection task.

Also need to consider maybe not checking the connection state (with a select 1 I mean) on every get when you have a background check. That should help reduce latency of getting a connection.

I worked on mobc to try to improve that, so I kinda know the edge cases and its certainly not a simple problem.

[bikeshedder]

Also need to consider maybe not checking the connection state (with a select 1 I mean) on every get when you have a background check. That should help reduce latency of getting a connection.

That's what I meant by adding a Object::ready field. A background task would recycle the objects ahead of time and return the objects with ready=True causing the pool not to recycle the objects the next time they are fetched from the pool.

It's not that simple though. An object might have been unused for a long period of time until it is retrieved from the pool again. So objects should probably get some kind of valid_until information instead of just a simple ready flag. If the current time exceeds valid_until the object needs to be recycled again.

I worked on mobc to try to improve that, so I kinda know the edge cases and its certainly not a simple problem.

That's quite interresting. What edge cases did you run into?

Deadpool started as a "dead simple" pool implementation and has seen a bit of feature creep. I still consider the core of it to be rather simple, but it is by no means "dead simple" anymore. Timeouts, Hooks, Resizing, ... it all has made the core of it more complex.

I would prefer to add ahead of time recycling and connection health checks as an add-on.

[Sytten]

Ha make sense! I like the approach of valid_until, never seen that before.

Mostly race conditions and few bad designs

• Connection limit not being respected for re-entrant requests
• Wrong prioritization of pending connection requests (it needs to be a FIFO to be fair)
• No background task for lifetime/health check resulting in bad connections being returned to the caller
• A lot of contention on the lock that holds the connections, leading to poor performances under load

[JosiahParry]

I just wanted to piggy back off of this. It's likely that I have misread or missed the documentation, but how can one specify how long a connection in the pool can sit without being used before being killed / dropped? Right now I can spawn many connections in my pool but I do not see any simple or clever way of killing the connection if it's sitting there for too long without being used.

[JosiahParry]

After digging quite a bit I've found #131 which, in the comments indicate to use Pool::retain() which has a good example that I think will solve my needs. But 1) I think this should either be mentioned in the managed module or 2) be implemented in an easier to use interface in the managed module

[bikeshedder]

Tracking issue for ahead of time object creation/recycling:

• Ahead of time object creation/recycling #167