You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the docs for Builder::idle_timeout, "idle connections in excess of min_idle will be closed at the next reaping after remaining idle past this duration." To me, this implies that connections that are not in excess of min_idle are kept alive; in my opinion, this is desirable, since creating a connection could be expensive.
However, it appears that the reaper closes any connections that have been alive or idle for too long; based on max_lifetime and idle_timeout, respectively. It then respawns enough connections to have min_idle connections available. This seems to be inconsistent with the docs, and is also less desirable in my opinion. My use case is:
Creating connections is expensive
I would like to keep one connection open at all times (min_idle == 1)
I would like to close extra connections relatively quickly (for instance, idle_timeout == Duration::from_secs(1))
However, this means that even if my application never requests a connection, the idle connection is refreshed basically every time the reaper is scheduled.
The text was updated successfully, but these errors were encountered:
Adds a new boolean option to Builder named `reap_all_idle_connections`. If true (the default value), the current behavior of the pool is maintained. However, if false, the reaper will not close any idle connections if it results in there being fewer than `min_idle` connections, even if the connections have been idle for longer than `idle_timeout`.
This option would best be disabled if connections are expensive to establish and/or are generally stable over time.
This is actually pretty common with poolers of any kind (e.g. PgBouncer). Some settings are competing with others, creating edge cases like this one. There is no way to resolve this to one's satisfaction, really I think. min_idle means "keep at minimum that many connections open", but max_lifetime is very clear as well: "close a connection older than this". So, creating an exception to max_lifetime for min_idle will satisfy your requirement, but for other users, e.g. me, this will be the wrong behavior.
According to the docs for
Builder::idle_timeout
, "idle connections in excess ofmin_idle
will be closed at the next reaping after remaining idle past this duration." To me, this implies that connections that are not in excess ofmin_idle
are kept alive; in my opinion, this is desirable, since creating a connection could be expensive.However, it appears that the reaper closes any connections that have been alive or idle for too long; based on
max_lifetime
andidle_timeout
, respectively. It then respawns enough connections to havemin_idle
connections available. This seems to be inconsistent with the docs, and is also less desirable in my opinion. My use case is:min_idle == 1
)idle_timeout == Duration::from_secs(1)
)However, this means that even if my application never requests a connection, the idle connection is refreshed basically every time the reaper is scheduled.
The text was updated successfully, but these errors were encountered: