max idle time and max lifetime have confusing semantics

in JDBC-based connection pools such as Hikari or Tomcat, idle time applies to connection that are not in use and the max lifetime is checked for connections after they have been returned to the pool.

r2dbc-pool defaults max idle time to 30 minutes. this means that any applications that use connections for long periods of time (such as using the LISTEN feature in PostgreSQL) will have their in use connections unexpectedly terminated.

ideally, the two times would act similar to JDBC-based pools, limiting confusing for users with JDBC experience. alternatively, consider changing the names of the options to clearly indicate that they apply to in use connections.

(I do realize that the concepts here build upon reactor-pool’s notion of idle and life times; I think there’s an argument for enhancing reactor-pool to report on in-use vs idle discretely so it’s consumers can have differing behavior)

[mp911de]

r2dbc-pool defaults max idle time to 30 minutes. this means that any applications that use connections for long periods of time (such as using the LISTEN feature in PostgreSQL) will have their in use connections unexpectedly terminated.

That shouldn’t be the case since a connection using the LISTEN feature is expected to be acquired and therefore it’s not idle.

How would you use LISTEN with Postgres? Would you acquire all connections, issue a LISTEN statement and put the connection back to the pool expecting it remains subscribed?

FWIW, I added a test that verifies that the idle timeout does not apply to connections that are acquired.

[mp911de]

Thanks for raising this issue. It makes sense to align with JDBC pools regarding semantics.