Introduced a single header file "py2py3.h" to handle python2/3 difference in bjoern and enable full python3 support on top of python2 support.

This port heavily referenced the existing bjoern-py3 implementation: https://github.com/isaiah/bjoern-py3

but removed the bytesio.c/h completely.

I trid to build this server from source on my FreeBSD8.2 system, but found a problem make this impossible. Error happened in the "server.c" file. Because BSD use libc as default, so the <sys/sendfile.h> include will go wrong( this file is a linux feature by glibc). In BSD,there is a sendfile() function works just the same as in the Linux but has few more parameters. The do_sendfile() function wrapped the sendfile() function in your code, so I think this make its easier to port to BSD. Thanks for your excellent job!!

This is my first Python C extension development experience, and frankly I don't work with C very often, but I thought this would be a fun way to practice.

So if you have time and don't mind reviewing this, I would love to know what could be improved, etc.

I didn't see a good way to implement option 2 in the PEP 3333 suggested mechanisms for handling Expect/Continue, so I went with option 1 (i.e., if Expect is encountered and the value is "100-continue", just go ahead and write it). It would probably be better to allow the client code to make this determination, but, although we could pass the client_fd as a PyFile to the client, it doesn't really have access to the header until the entire request is parsed, and by that time, it's too late. Please correct me if I'm wrong.

Thanks!

Hi @jonashaag ,

Here is a first step to build wheels as requested by #121. This PR is a small step : it does not change release process, does not change tests, does not add CI, does not support every binary platform.

To upload wheel, you need docker-compose and twine. Then, simply run make upload. There is two new Make targets : distclean (just cleaning dist dir) and packages to build without uploading.

$ make distclean packages
...
$ tree dist/
dist/
├── bjoern-3.1.0-cp27-cp27mu-manylinux1_x86_64.whl
├── bjoern-3.1.0-cp27-cp27mu-manylinux2010_x86_64.whl
├── bjoern-3.1.0-cp35-cp35m-manylinux1_x86_64.whl
├── bjoern-3.1.0-cp35-cp35m-manylinux2010_x86_64.whl
├── bjoern-3.1.0-cp35-cp35m-manylinux2014_x86_64.whl
├── bjoern-3.1.0-cp36-cp36m-manylinux1_x86_64.whl
├── bjoern-3.1.0-cp36-cp36m-manylinux2010_x86_64.whl
├── bjoern-3.1.0-cp36-cp36m-manylinux2014_x86_64.whl
├── bjoern-3.1.0-cp37-cp37m-manylinux1_x86_64.whl
├── bjoern-3.1.0-cp37-cp37m-manylinux2010_x86_64.whl
├── bjoern-3.1.0-cp37-cp37m-manylinux2014_x86_64.whl
├── bjoern-3.1.0-cp38-cp38-manylinux1_x86_64.whl
├── bjoern-3.1.0-cp38-cp38-manylinux2010_x86_64.whl
├── bjoern-3.1.0-cp38-cp38-manylinux2014_x86_64.whl
└── bjoern-3.1.0.tar.gz

0 directories, 15 files
$

libev IS embedded in wheel. I'm wondering if this will trigger issue like with psycopg2 and libpq. The workaround is to use source tarball rather than wheel.

Each wheel is pen tested in a virtualenv with test_wsgi_compliance.py.

I hit a bug with cp27m. Instead of fighting this, I choose to blacklist it for now. Users will still use sources.

The docker-compose.yml should be easy to translate to a CI job matrix, using either CircleCI, GitHub Action, Travis, Azure pipelines and/or appveyor.

@jonashaag what do you think of this ?

cc @hoefling

First of all - thanks for making this code - I find it really good approach to wsgi gateway. I wanted to give it a shot on pre-production new kind of service that I've launched recently - it's low latency rest endpoint.

After some tests we find out that bjoern falls in active wait on epool (monitored with strace), but still handling requests right. I assume it's a bug because falling back to uwsgi solved this problem.

launched with reuse_port, like this: bjoern.run(wsgi.application, 'localhost', 8000, reuse_port=True)

My question is what kind of input do You need to debug?

Is it possible to create a bjoern backend for chaussette ?

I doesn't look that complicated but I don't know where to start.

Refs mozilla-services/chaussette#26

I am currently working on a platform that uses the microservice architecture and I am testing the use of bjoern as http server for our microservices. Our microservices are behind envoy proxy and under high stress I get timeouts for about 5% of the connections.

It seems to be a bjoern issue with the "keep-alive" flow.

Current behavior in bjoern:

• From time to time, after a request is served on a keep-alive connection, the new request triggers the accept_watcher/ev_io_on_request which puts bjoern in "accept mode", therefore the previous connection is terminated.

Implemented behavior:

• After a new client is accepted, the accept_watcher is disabled. The watcher is enabled again only on the close_connection use case.

This has been tested with the version 3.0.1.

Hello, I'm assembling some performance results and found that Bjoern is much faster on macOS than on Linux.

I get one eighth the performance on Linux benchmarking with wrk. Is this by design? Is macOS the preferred platform or is something wrong?

Interestingly enough, a fresh install still produces errors. The process:

1. Install Mac OS X 10.6.
2. Install Xcode 4 Build 4A225.
3. Install latest Python 2.7 from .pkg installer.
4. Install homebrew and run: brew install libev
5. Install virtualenv for 2.7, create a new environment, and enter it.
6. Run: pip install bjoern

The pip.log is: http://dpaste.de/wDGo/

Again it seems like I'm dealing with architecture (x86 vs. x64) issues. I'll have to see if there's a way to make brew install universal (dual 32-bit and 64-bit) versions.

I've added metrics wherever they made sense to me, these are all simple increment metrics counting the number of times an event happened.

There is scope for gauge and timer too but I'm not sure those will be as helpful inside bjoern, almost all of these can also be exposed from the WSGI app.

I don't write C a lot so please feel free to suggest code design changes.

closes #167

Python 2.7, latest Snow Leopard, libev 3.9 installed via ports. Installed via:

sudo port install libev virtualenv --no-site-packages --distribute sandbox cd sandbox ; . bin/activate pip install bjoern

The result is that ev.h can't be found and thus a whole slew of errors and warnings are displayed. The version of Python, operating system, and the exact errors/warnings I believe are irrelevant to this problem; ports likely installed libev in /usr/local instead of /usr.

How would I tell pip (or, if I clone the repo, setup.py) to check a different location for includes/libraries?

Hi! This PR attempts to implement per the recommendation in this comment https://github.com/jonashaag/bjoern/issues/91#issuecomment-493710529. The commit message provides more detail on exactly

Note that one distinct difference from the suggested implementation is that the listener socket is closed after the backlog is drained. For my use case (running many instances of my HTTP server using SO_REUSEPORT) this works better, as it will ensure that any new connections will go to other instances ASAP and ensure this given instance can shutdown relatively quickly. Based on further discussion on the issue, I think this would be the most beneficial behavior for others too. If you'd like that behavior to be configurable as well, just let me know and I can add another config flag for it.

(hopefully) fixes #91.

How we can call from command line like gunicorn... web: gunicorn main:application --workers=13 --threads=2 --worker-connections=1000 --keep-alive=1800 --worker-class=uvicorn.workers.UvicornWorker --timeout 3600 --log-level=debug this how we are using to call your application inside aws elastic bean stack inside the Procfile..

I am new to this, Please guide me.

I'm on macOS 11.5.2. After stopping the server via SIGHUP and then starting again on the same Unix socket I get the following error:

OSError: [Errno 48] Address already in use

Is this expected? I currently have to keep changing the Unix socket path every time I restart the server from my IDE.

Traceback:

`Repl.it: Updating package configuration

--> python3 -m poetry add Bjoern Using version ^3.1.0 for Bjoern

Updating dependencies Resolving dependencies...

Package operations: 1 install, 0 updates, 0 removals

• Installing Bjoern (3.1.0)

[EnvCommandError] Command ['/opt/virtualenvs/python3/bin/pip', 'install', '--no-deps', 'bjoern==3.1.0'] errored with the following return code 1, and output: Collecting bjoern==3.1.0 Using cached https://files.pythonhosted.org/packages/8f/d9/729bed4f535574bd2ca7d541e88f94f5ae678c341f4df153a70a3ff3a695/bjoern-3.1.0.tar.gz Building wheels for collected packages: Bjoern Building wheel for Bjoern (setup.py): started Building wheel for bjoern (setup.py): finished with status 'error' ERROR: Command errored out with exit status 1: command: /opt/virtualenvs/python3/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-sntn21hu/bjoern/setup.py'"'"'; file='"'"'/tmp/pip-install-sntn21hu/bjoern/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-rsvbklsv --python-tag cp38 cwd: /tmp/pip-install-sntn21hu/bjoern/ Complete output (20 lines): running bdist_wheel running build running build_py creating build creating build/lib.linux-x86_64-3.8 copying bjoern.py -> build/lib.linux-x86_64-3.8 running build_ext building '_bjoern' extension creating build/temp.linux-x86_64-3.8 creating build/temp.linux-x86_64-3.8/http-parser creating build/temp.linux-x86_64-3.8/bjoern x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DSIGNAL_CHECK_INTERVAL=0.1 -DWANT_SIGNAL_HANDLING=yes -DWANT_SIGINT_HANDLING=yes -Ihttp-parser -Istatsd-c-client -I/usr/include/libev -I/opt/local/include -I/opt/virtualenvs/python3/include -I/usr/include/python3.8 -c http-parser/http_parser.c -o build/temp.linux-x86_64-3.8/http-parser/http_parser.o -std=c99 -fno-strict-aliasing -fcommon -fPIC -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -g x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DSIGNAL_CHECK_INTERVAL=0.1 -DWANT_SIGNAL_HANDLING=yes -DWANT_SIGINT_HANDLING=yes -Ihttp-parser -Istatsd-c-client -I/usr/include/libev -I/opt/local/include -I/opt/virtualenvs/python3/include -I/usr/include/python3.8 -c bjoern/_bjoernmodule.c -o build/temp.linux-x86_64-3.8/bjoern/_bjoernmodule.o -std=c99 -fno-strict-aliasing -fcommon -fPIC -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -g In file included from bjoern/wsgi.h:2:0, from bjoern/_bjoernmodule.c:3: bjoern/request.h:4:10: fatal error: ev.h: No such file or directory #include <ev.h> ^~~~~~ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

ERROR: Failed building wheel for Bjoern Running setup.py clean for bjoern Failed to build bjoern Installing collected packages: bjoern Running setup.py install for bjoern: started Running setup.py install for bjoern: finished with status 'error' ERROR: Command errored out with exit status 1: command: /opt/virtualenvs/python3/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-sntn21hu/bjoern/setup.py'"'"'; file='"'"'/tmp/pip-install-sntn21hu/bjoern/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /tmp/pip-record-kbxfyffj/install-record.txt --single-version-externally-managed --compile --install-headers /opt/virtualenvs/python3/include/site/python3.8/bjoern cwd: /tmp/pip-install-sntn21hu/bjoern/ Complete output (20 lines): running install running build running build_py creating build creating build/lib.linux-x86_64-3.8 copying bjoern.py -> build/lib.linux-x86_64-3.8 running build_ext building '_bjoern' extension creating build/temp.linux-x86_64-3.8 creating build/temp.linux-x86_64-3.8/http-parser creating build/temp.linux-x86_64-3.8/bjoern x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DSIGNAL_CHECK_INTERVAL=0.1 -DWANT_SIGNAL_HANDLING=yes -DWANT_SIGINT_HANDLING=yes -Ihttp-parser -Istatsd-c-client -I/usr/include/libev -I/opt/local/include -I/opt/virtualenvs/python3/include -I/usr/include/python3.8 -c http-parser/http_parser.c -o build/temp.linux-x86_64-3.8/http-parser/http_parser.o -std=c99 -fno-strict-aliasing -fcommon -fPIC -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -g x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DSIGNAL_CHECK_INTERVAL=0.1 -DWANT_SIGNAL_HANDLING=yes -DWANT_SIGINT_HANDLING=yes -Ihttp-parser -Istatsd-c-client -I/usr/include/libev -I/opt/local/include -I/opt/virtualenvs/python3/include -I/usr/include/python3.8 -c bjoern/_bjoernmodule.c -o build/temp.linux-x86_64-3.8/bjoern/_bjoernmodule.o -std=c99 -fno-strict-aliasing -fcommon -fPIC -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -g In file included from bjoern/wsgi.h:2:0, from bjoern/_bjoernmodule.c:3: bjoern/request.h:4:10: fatal error: ev.h: No such file or directory #include <ev.h> ^~~~~~ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 ---------------------------------------- ERROR: Command errored out with exit status 1: /opt/virtualenvs/python3/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-sntn21hu/bjoern/setup.py'"'"'; file='"'"'/tmp/pip-install-sntn21hu/bjoern/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /tmp/pip-record-kbxfyffj/install-record.txt --single-version-externally-managed --compile --install-headers /opt/virtualenvs/python3/include/site/python3.8/bjoern Check the logs for full command output. WARNING: You are using pip version 19.3.1; however, version 21.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command.

exit status 1

Repl.it: Package operation failed.`

I just started using bjoern on my project and it's been going great so far. What I'd like to know is if there's a way to globally set a timeout for requests.

My project is a very simple API with a few endpoints, but sometimes the request will take too long and I'd like to set a timeout for all endpoints

the code looks something like this:

from flask import Flask

app = Flask(__name__)
host = "0.0.0.0"
port = 5000

@app.route("/up", methods=["POST"])
def up():
    res = doSomething()
    return(res)

@app.route("/down", methods=["POST"])
def down():
    res = doSomethingElse()
    return(res)

if __name__ == "__main__":
    import bjoern
    bjoern.run(app, host, port)

what I'd like to happen is to end the connection if either /up or /down takes more than 20s. is that possible?

bjoern seems to keep the connection alive as long as possible and doesn't have a limitation of how many connections to keep. And I didn't find a way to disable, control or limit the keep-alive behavior (without editing and recompile the code)

It become an issue when there are tons of clients trying keeping the connection alive, since that's the default behavior, but it's a burden to the server since most connection are just idling.