Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
erp5
erp5
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Merge Requests 136
    • Merge Requests 136
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Jobs
  • Commits
  • nexedi
  • erp5erp5
  • Merge Requests
  • !883

Merged
Opened Jun 03, 2019 by Bryton Lacquement@bminusl🚪
  • Report abuse
Report abuse

Add WSGI support

This first work on WSGI is only to stop using ZServer (Medusa), which is a required step before moving to Zope 4. This means that Zope should behave almost exactly the same way as before, notably:

  • We don't take advantage yet of what WSGI offers, like IPv6.
  • There's extra code to handle errors the same way as before (this is something we'll have to change for Zope 4).

The most significant change in behaviour is that the chosen WSGI server (waitress) does some of the HTTP work in worker threads (Medusa does it entirely in the IO thread), and the biggest consequence concerns the deadlock debugger that is now run from the worker thread:

  • it does not work if all threads are blocked
  • doing better would require to patch waitress in a quite ugly way

About TimerService, we simplify things by removing the egg. In zope.conf, it's possible to import from the product.

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch origin
git checkout -b wsgi origin/wsgi

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout origin/master
git merge --no-ff wsgi

Step 4. Push the result of the merge to GitLab

git push origin master

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

  • Discussion 62
  • Commits 7
  • Changes 15
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
0
Labels
None
Assign labels
  • View project labels
Reference: nexedi/erp5!883

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7