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

sqlx 0.5.2 with a pool size of 1 fails to respond to simultaneous queries #1210

Closed
D1plo1d opened this issue May 2, 2021 · 1 comment
Closed

Comments

@D1plo1d
Copy link
Contributor

D1plo1d commented May 2, 2021

After upgrading to sqlx 0.5.2 whenever I run more then one SQL query in parallel one (or possibly more) of the queries will time out after 30 seconds with:

pool timed out while waiting for an open connection

Downgrading to sqlx 0.5.1 resolves the issue and these same queries complete within an imperceptible amount of time.

I'm using Sqlite with the following configuration:

    // Connect to the database
    let db_options = db_url.parse::<SqliteConnectOptions>()?
        .synchronous(sqlx::sqlite::SqliteSynchronous::Normal);

    let db = SqlitePoolOptions::new()
        .max_connections(1)
        .connect_with(db_options)
        .await?;

Could this be related to the pool changes in #1149 ?

Also downgrading to 0.5.1 was made slightly more difficult because sqlx-core and sqlx-macros were not locked to the same patch release as sqlx. If it would be possible to lock those to the same releass as sqlx, eg. "=0.5.1" that might be handy in debugging future patch release regressions.

D1plo1d added a commit to PrintSpool/PrintSpool that referenced this issue May 2, 2021
@D1plo1d D1plo1d changed the title sqlx 0.5.2 with a pool size of 1 fails to respond to simeltaneous queries sqlx 0.5.2 with a pool size of 1 fails to respond to simultaneous queries May 2, 2021
@abonander
Copy link
Collaborator

Yeah commented on this here: #622 (comment)

abonander added a commit that referenced this issue May 6, 2021
* a task that is marked woken but didn't actually wake will instead wake the next task
in the queue

* a task that wakes but doesn't get a connection will put itself back in the queue instead of waiting until it times out with no way to be woken

* the idle reaper won't run if there are tasks waiting for a connection, and also uses
the proper `SharedPool::release()` to return validated connections to the pool so waiting tasks get woken

closes #622, #1210

(hopefully for good this time)

Signed-off-by: Austin Bonander <austin@launchbadge.com>
abonander added a commit that referenced this issue May 6, 2021
* a task that is marked woken but didn't actually wake before being cancelled will instead wake the next task in the queue

* a task that wakes but doesn't get a connection will put itself back in the queue instead of waiting until it times out with no way to be woken

* the idle reaper now won't run if there are tasks waiting for a connection, and also uses
the proper `SharedPool::release()` to return validated connections to the pool so waiting tasks get woken

closes #622, #1210

(hopefully for good this time)

Signed-off-by: Austin Bonander <austin@launchbadge.com>
abonander added a commit that referenced this issue May 18, 2021
* a task that is marked woken but didn't actually wake before being cancelled will instead wake the next task in the queue

* a task that wakes but doesn't get a connection will put itself back in the queue instead of waiting until it times out with no way to be woken

* the idle reaper now won't run if there are tasks waiting for a connection, and also uses
the proper `SharedPool::release()` to return validated connections to the pool so waiting tasks get woken

closes #622, #1210

(hopefully for good this time)

Signed-off-by: Austin Bonander <austin@launchbadge.com>
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