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

X-Pool blocks if too many resource creations timeout #7

Open
cressie176 opened this issue Aug 27, 2023 · 0 comments
Open

X-Pool blocks if too many resource creations timeout #7

cressie176 opened this issue Aug 27, 2023 · 0 comments

Comments

@cressie176
Copy link
Member

cressie176 commented Aug 27, 2023

X-Pool tries hard not to create more resources than the max pool size, and therefore considers in progress acquiring requests when deciding whether to block. When a resource creation times out, the task is left in the _inProgressAcquireTasks list since it may eventually resolve with a valid resource, however until it resolves it will take up one resource allocation in the pool. This means that if the task never resolves the allocation will be gone permanently, and that if enough tasks timeout permanently, the pool will be blocked forever.

This differs from how X-Pool works when destroying tasks. When a destroy task times out, the resource is quarantined in a badResources list where it will continue to take up space. If the task eventually resolves, the bad resource will be removed. However, the user also has the option of calling pool.evictBadResources() and so can prevent the pool from choking on too many bad resources if they so choose.

A second consequence of this problem is that permanently timed out acquisition requests will block pool.shutdown() until the shutdownTimeout is exceeded.

Candidate Solution 1

Should we change X-Pool so that it disregards timed out acquisition requests when calculating availability, even though it will mean that we could create more resources than the max pool size?

Candidate Solution 2

An alternative would be to give the user the option of evicting timed out acquire requests if the pool becomes blocked with them. I'm not sure if this is practical though, since it is likely that new requests will also timeout.

Candidate Solution 3

Yet another alternative (which could be combined with 1 or 2) is to differentiate timed out acquire requests, and potentially signal to the user when they are choking the pool.

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

1 participant