add option to serve gateway through werkzeug #10171
Conversation
thrau
added
the
semver: minor
thrau
force-pushed
the
gateway-server
branch
from
45c3c3f to
dcfeabe
Compare
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 3m 9s ⏱️ Results for commit dcfeabe. |
bentsku
left a comment
bentsku
left a comment
There was a problem hiding this comment.
Nice! This is looking good and really helpful to debug some issues we have.
Just the thread name of the handler is a bit weird while logging, but other than this minor thing, this looks nice for debugging purposes!
I've ran some benchmarks for fun on it 😅 (in host mode), it worked all right!
| run_simple(host, port, WsgiGateway(gateway), use_reloader=use_reloader, **kwargs) | ||
|
|
||
|
|
||
| class CustomWSGIRequestHandler(WSGIRequestHandler): |
There was a problem hiding this comment.
q: is there any way to specify the thread name of the threaded handler? Because right now it seems it gives something truncated like:
2024-02-26T17:17:44.123 DEBUG --- [uest_thread)] l.aws.protocol.serializer
There was a problem hiding this comment.
i looked into it and found that thread creation is controlled by socketserver.ThreadingMixin. This is the code they use:
def process_request(self, request, client_address):
"""Start a new thread to process the request."""
if self.block_on_close:
vars(self).setdefault('_threads', _Threads())
t = threading.Thread(target = self.process_request_thread,
args = (request, client_address))
t.daemon = self.daemon_threads
self._threads.append(t)
t.start()We could overwrite that, but the question is what to show. A running thread id would continue to increase for each request coming into to system. We could implement a thread pool on top of this actually, but all that seems a bit too much effort right now.
I'll keep it in mind though!
3 participants
Motivation
There have been several situations in the recent past where we needed to figure out whether certain issues come from our Gateway or Hypercorn. Because we have no alternative way of serving the gateway other than hypercorn, this is very difficult. This PR does some refactoring and provides a first alternative: a werkzeug dev server, that can be activated by setting
GATEWAY_SERVER=werkzeug.The werkzeug dev server integration for now is mostly for testing/development purposes. With werkzeug there are also some expected test failures (websockets, anything streaming or HTTP2 related). So I wouldn't run a test suite on this regularly. Here's a test run showing the remaining failing tests. AFAICT all those are expected since they involve streaming or websockets, or they are making unnecessarily strict assumptions on headers. The
test_s3_get_response_case_sensitive_headersshould probably be removed since it uses and old variable from thehttp2_server.It can be used to test whether some issues are related to hypercorn or not.
This is not something I would document right now or give to users, but can be useful for us internally for troubleshooting. The underlying refactoring also gives way to serious alternatives like twisted #9834.
Changes
GATEWAY_SERVERvariable that can be set to eitherhypercorn(default) orwerkzeug.Testing
start localstack with
GATEWAY_SERVER=werkzeug