Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define what timeout are configurable #8

Open
ttddyy opened this issue Apr 17, 2019 · 1 comment
Open

Define what timeout are configurable #8

ttddyy opened this issue Apr 17, 2019 · 1 comment

Comments

@ttddyy
Copy link
Member

ttddyy commented Apr 17, 2019

According to reactor/reactor-pool#34, I read there are 3 timeout:

  1. Timeout for getting actual resource from allocator. (connection from ConnectionFactory).
    => use PoolBuilder.from(allocator.timeout())
  2. the pool is depleted and resources have reached to the max size, so no more new resource allocation. thus, timeout for waiting a resource to be released.
    => use pool.acquire(Duration) (the new method)
  3. Both of above
    => use pool.acquire().timeout()

pool-timeout

@simonbasle is this correct understanding?

While thinking this, I'm thinking what would be good for connection pooling.

Currently in r2dbc-pool, timeout for 2 and 3 are configureable. (maxCreateConnectionTime is for 2 and maxAcquireTime for 3)

From connection-pool perspective, I think it is sufficient for making 2 and 3 configurable.

Q1: But is it too much configurable? Should we only make 3 configureable? OR, it's less, make all 1,2,3 configureable?

Q2: Validation. Currently, a user can set timeout for 3 to 10sec and 2 to 30sec.
Should we put validation logic that timeout for 2 should be less than equal to timeout for 3?

My opinion is timeout for 2 and 3 are sufficient. Maybe good to have warning message for validation.
Wondering what others think :)

@simonbasle
Copy link

@ttddyy that is correct for the various timeouts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants