Port osrm-routed to use boost::beast#7328
Conversation
There was a problem hiding this comment.
Pull request overview
This PR ports the osrm-routed HTTP server from a custom HTTP parser implementation to use Boost.Beast, a modern HTTP library that's part of Boost. This is a significant modernization of the HTTP stack.
Changes:
- Replaces custom HTTP parser with Boost.Beast HTTP implementation
- Migrates from custom request/reply structures to Beast's native HTTP types
- Updates connection handling to use Beast's tcp_stream with built-in timeout support
- Simplifies server acceptor logic using Beast patterns
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/server/request_parser.cpp | Removed - custom HTTP parser no longer needed |
| src/server/http/reply.cpp | Removed - replaced by Beast response types |
| include/server/request_parser.hpp | Removed - custom parser header |
| include/server/http/request.hpp | Removed - replaced by Beast request types |
| include/server/http/reply.hpp | Removed - replaced by Beast response types |
| include/server/http/header.hpp | Removed - Beast handles headers natively |
| src/server/request_handler.cpp | Updated to use Beast request/response types and extract headers using Beast API |
| src/server/connection.cpp | Rewritten to use Beast's async I/O with tcp_stream for connection management |
| include/server/connection.hpp | Updated with Beast types and modern connection handling |
| include/server/request_handler.hpp | Updated type aliases to use Beast types |
| include/server/server.hpp | Refactored acceptor logic to use Beast patterns and added enable_shared_from_this |
| fuzz/request_parser.cc | Updated fuzzer to use Beast's HTTP parser |
| CMakeLists.txt | Added Boost version checks for Beast compatibility |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
That's a fascinating change. Thanks for preparing the insightful experiments. |
9a611b3 to
c1d9c9f
Compare
|
Looks like there's a segfault happening:
|
51cef1a to
9f31063
Compare
|
Well this took a while to debug (only crashed every few thousand |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
03e933b to
61cf71e
Compare
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
bfa817c to
2688a07
Compare
|
This is ready now. |
| short keepalive_timeout) | ||
| { | ||
| util::Log() << "http 1.1 compression handled by zlib version " << zlibVersion(); | ||
| util::Log() << "HTTP/1.1 server using Boost.Beast, compression by zlib " << zlibVersion(); |
There was a problem hiding this comment.
No blocker, but I could imagine this might break a few folks pragmatic uptime monitoring.
There was a problem hiding this comment.
I would hope they would at least check for [info] running and waiting for requests instead. 😆
5ca7321 to
034887b
Compare
|
I'm afraid we have memory leaks: |
|
Are they new though? I can maybe squeeze in some time this week to take a closer look, might just be some |
|
They are new since a few days ago. I have a debug-asan task running in my private repo, failing now. |
|
@TheMarex another thing to mention: a while back, @SiarheiFedartsou tried basically the same and we ended up reverting it, see #6407 IIRC the main issue was that the boost::beast HTTP parser had some upper limit on the GET request size it would accept, and this broke quite a few users making very large GET |
|
@danpat Haha, nothing new under the sun. 😆 Well, fortunately this is actually configurable in 2026 with the less obviously named I'll prepare a separate PR for that, I think we can make this seamless by defaulting to some number derived from the coordinate limits. |
|
@MarcelloPerathoner Took a quick look at it, seems harmless since essentially the root cause is that the |
Issue
We have long discussed sun-setting
osrm-routedin favor ofosrm-routed.js. (see #6411 and #3832). Now having written #3832 9 years ago, it is time to reflect if that was such a good idea.osrm-routedis still around a most people use it inside a docker container behind some kind of HTTP proxy.It is clear the current HTTP code is not great, but there are some good options in C++ land that are really mature and more then enough for a standalone HTTP server. For example
boost::beastwhich makes a lot of sense since we useboost::asioanyway.Thanks to our new AI overlords that transition was relatively smooth with some hand-holding. I've done some benchmarks and I think we should drop the NodeJS path in favor of this. It's pretty clear that we have some issues with initial connection setup, the new beast-based implementation is dramatically faster if we are not saturated.
We need 128 concurrent connections to saturate my machine (4 cores, 8 threads) with the baseline implementation, we can do the same with far fewer connections using the new beast implementation. This is random MLD P2P queries on Bavaria.
Tasklist
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?