-
Notifications
You must be signed in to change notification settings - Fork 23.1k
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
[IMP][POC] server: check signaling in parent process #91253
base: master
Are you sure you want to change the base?
[IMP][POC] server: check signaling in parent process #91253
Conversation
cc @odony |
da1c12a
to
ae57ea9
Compare
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.
For the record, this completely makes sense to me.
I suggest to test it in real-world conditions before merging.
Makes the server die pretty quickly, after a few minutes max. Judging by the semi-random errors, I'd say that we're sharing the db connections through multiple processes (after fork), therefore bypassing the ConnectionPool locks and corrupting the connection states.
|
ae57ea9
to
1eaf3a3
Compare
When started with -d, registries are pre initialized before the workers are spawned. This means that the parent process will have some registries in memory that will be available to the workers after the fork. If the parent process never checks signaling and the sequence changes, the copied registry will be reset at the first request. This means that a new registry will be create after the fork everytime a worker is recycled. By checking the registry in the parent worker, we ensure that the forked process will have a registry up to date (except if another change is made during the fork...).
1eaf3a3
to
ca1b6d2
Compare
@odony not so long ago you told me that we do not recycle http workers after x requests, can you confirm it? |
Note that with https://github.com/odoo/odoo/compare/ae57ea9c54bc634543e554b6a5b3f965b52f9a49..ca1b6d2600ca4a3cb2833523d602a066035fb6ab the previous issue should be solved if it is still useful |
yes, we basically set the request limit very high in order to avoid recycling workers too often - if we don't have any reason to do so, it's just wasteful |
When started with -d, registries are pre initialized before the workers
are spawned.
This means that the parent process will have some registries in memory
that will be available to the workers after the fork.
If the parent process never checks signaling and the sequence changes,
the copied registry will be reset at the first request.
This means that a new registry will be create after the fork everytime a
worker is recycled.
By checking the registry in the parent worker, we ensure that the forked
process will have a registry up to date (except if another change is
made during the fork...).