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

r2d2 threads remain alive for up to 30s after pool shutdown #99

Open
arthurprs opened this issue Feb 25, 2020 · 2 comments
Open

r2d2 threads remain alive for up to 30s after pool shutdown #99

arthurprs opened this issue Feb 25, 2020 · 2 comments

Comments

@arthurprs
Copy link

Due to the way scheduled-thread-pool word and the usage of the reaper r2d2 threads remain around for up to 30s (the non-configurable reaper period).

I looked it up and it didn't look trivial to fix.

Even if we hold the job handle and reaper_job.cancel() on drop, that won't wake up the waiting thread, as cancel is just an atomic flag.

@link2xt
Copy link

link2xt commented Apr 16, 2022

Is there at least a way to wait until all threads are stopped? I drop connection pool, but then I don't know how long should I wait until database files are released so I can move them on Windows.

link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
In execute_migration transaction first update the version, and only
then execute the rest of the migration. This ensures that transaction
is immediately recognized as write transaction and there is no need
to promote it from read transaction to write transaction later, e.g.
in the case of "DROP TABLE IF EXISTS" that is a read only operation if
the table does not exist. Promoting a read transaction to write
transaction may result in an error if database is locked.

When removing an account, try 5 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
In execute_migration transaction first update the version, and only
then execute the rest of the migration. This ensures that transaction
is immediately recognized as write transaction and there is no need
to promote it from read transaction to write transaction later, e.g.
in the case of "DROP TABLE IF EXISTS" that is a read only operation if
the table does not exist. Promoting a read transaction to write
transaction may result in an error if database is locked.

When removing an account, try 5 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
When removing an account, try 5 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
When removing an account, try 5 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
When removing an account, try 60 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 which may result in 30
seconds delay until all connections are closed [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
When removing an account, try 60 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 which may result in 30
seconds delay until all connections are closed [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
When removing an account, try 60 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 which may result in 30
seconds delay until all connections are closed [1].

[1] sfackler/r2d2#99
link2xt added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 17, 2022
When removing an account, try 60 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 which may result in 30
seconds delay until all connections are closed [1].

[1] sfackler/r2d2#99
hpk42 pushed a commit to deltachat/deltachat-core-rust that referenced this issue Apr 19, 2022
When removing an account, try 60 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 which may result in 30
seconds delay until all connections are closed [1].

[1] sfackler/r2d2#99
hpk42 pushed a commit to deltachat/deltachat-core-rust that referenced this issue Apr 19, 2022
When removing an account, try 60 times with 1 second sleep in between
in case removal of database files fails. This happens on Windows
platform sometimes due to a known bug in r2d2 which may result in 30
seconds delay until all connections are closed [1].

[1] sfackler/r2d2#99
@phatblat
Copy link

phatblat commented Feb 1, 2023

Looks like #74 was an attempt to shorten this timeout.

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

3 participants