-
Notifications
You must be signed in to change notification settings - Fork 117
Improve queue race conditions #455
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
Improve queue race conditions #455
Conversation
set manually, just like `async`
and don't reuse the same session every time. Create a new one as needed.
1 similar comment
|
@davidcaron is there a difference if we use sqlite or postgres? Would that influence the current PR? |
|
I can't review this PR but these issues have caused us some trouble lately. We'd be really glad if this could be fixed. |
|
@cehbrecht I tested both postgres and sqlite, and I found that postgres handles concurrent connections better than sqlite... which isn't surprising, but sqlite should at least do the job. This PR improves connections using both sqlite and postgres, but in my tests, I found that sqlite had more problems than postgres, and I couldn't pinpoint what caused sqlite to crash. I got file corruption error messages from sqlite. Keep in mind that I was sending short bursts of 4-5 requests at the same time, and I never got any issue when the request has time to start processing before receiving another one. |
cehbrecht
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double checked locally with Emu WPS. Code looks fine.
|
@davidcaron @jachym I don't have much insight in the database handling but since it improves the situation I will merge it. |
|
@davidcaron done. Thanks :) |
Overview
When I tested sending lots of small requests to pywps:
I found that making Pywps completely threadsafe and multi-process safe is challenging. When I started using locks, the forked Pywps workers would copy the opened lock to the forked process, leading to a deadlock.
Another solution would be to spawn processes instead of forking them. But this is Python 3.4+ only.
So I fixed a few things so that race conditions are less likely to happen.
Related Issue / Discussion
Also, I think 24f48dd fixes #450
Additional Information
Contribution Agreement
(as per https://github.com/geopython/pywps/blob/master/CONTRIBUTING.rst#contributions-and-licensing)