* - Use libtbb-dev in builder stage and libtbb12 package in the runstage instead of building oneTBB v2021.12.0 from source code
- Remove wget package from builder stage, because it is not used
- Uppercase "FROM ... as" -> "FROM ... AS" to silence a "docker build" warning
- Sort packages alphabetically and put them on separate lines for easier comparison
* - Fix the warning "FromAsCasing: 'as' and 'FROM' keywords' casing do not match"
- Sort packages alphabetically and put them on separate lines for easier comparison
* Revert -Wno-stringop-overflow
* Update the link to multi staged builds in the comment
* Update alpine:3.20.0 -> alpine:3.20.5
A request to osrm-routed can be assigned to a thread which
is currently busy processing another request, even when there
are other threads/cores available. This unnecessarily delays
the response, and can make requests appear to hang when
awaiting CPU intensive requests to finish.
The issue looks like a bug in Boost.Asio multithreaded
networking stack.
osrm-routed server implementation is
heavily influenced by the HTTP server 3 example in the
Boost.Asio docs. By upgrading to Boost 1.70 and updating the
server connections to match the example provided in the 1.70
release, the problem is resolved.
The diff of the changes to the Boost.Asio stack are
vast, so it's difficult to identify the exact cause. However
the implementation change is to push the strand of execution
into the socket (and timer) objects, which suggests it could
fix the type of threading issue we are observing.
