Skip to content

Conversation

@joeydewaal
Copy link
Contributor

Does your PR solve an issue?

Fixes #3513,#3315,#3132,#2848

Ive read through the issues and I think this is the solution like proposed in #2848. However I don't think this is done yet. Should the connect_timeout be a part of the public api? Is 30 seconds a good default?

Copy link
Collaborator

@abonander abonander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good start, but strictly speaking it doesn't fix #2848 because it doesn't retry the idle queue once it decides to connect. That's the problem there.

Once it passes its permit to the spawned task, it could try to acquire another and race to see which completes first. Since the connection is happening in a background task, the attempt won't be wasted, as it'll just return to the idle queue.

@joeydewaal
Copy link
Contributor Author

joeydewaal commented Sep 21, 2024

Now the pool tries to get an idle connection while opening a new connection. It has a backoff mechanism (taken from connect) but I'm not sure if this is necessary?

@abonander
Copy link
Collaborator

Thank you for your effort, but after some thought I realized that Pool needed significant internal changes to improve its behavior. So this has been superceded by #3582.

@abonander abonander closed this Oct 29, 2024
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

Successfully merging this pull request may close these issues.

Pool should spawn a task when connecting in acquire()

2 participants