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
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.
The text was updated successfully, but these errors were encountered:
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 callingpool.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 theshutdownTimeout
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.
The text was updated successfully, but these errors were encountered: