[Beast] Client connection times out after 5s. How to avoid?
Hi. Continuing my explorations of Boost.Beast. So now I have: * a small Boost.Beast HTTP server (based on async_http_server example), and * a small Boost.Beast HTTP client (based on sync_http_client example). This works, in that I can start the client (wrapped in a helper class), make several requests, and close the client. But until now, the client was short-lived, so no problem. (the server was started too of course, and long lived as expected). Now I'm embedding that HTTP client into another (WebSocket) server, which uses that same wrapper class above, successfully connects to the HTTP server on startup, and now waits for WebSocket connections, at which time it's supposed to make HTTP requests to the HTTP server for various reasons. Problem is, the HTTP client times out after 5s. While I want it to be long lived. I've read Vinnie's answer in https://stackoverflow.com/a/56880415/103724 about sync operation not having timeouts, but I don't want to control timeouts of individual requests here (for now at least), I want to not have the underlying socket not timeout on its own, the same way a WebSocket does not timeout either. Is that possible? Who controls that 5s timeout? Would switching to an async HTTP client make any difference? Sounds to me that it would allow me to control timeouts of requests, but would it make any difference to the socket timeout described above? Thanks, --DD
On Tue, Dec 15, 2020 at 11:54 AM Dominique Devienne
Hi. Continuing my explorations of Boost.Beast.
So now I have: * a small Boost.Beast HTTP server (based on async_http_server example), and * a small Boost.Beast HTTP client (based on sync_http_client example).
This works, in that I can start the client (wrapped in a helper class), make several requests, and close the client. But until now, the client was short-lived, so no problem. (the server was started too of course, and long lived as expected).
Now I'm embedding that HTTP client into another (WebSocket) server, which uses that same wrapper class above, successfully connects to the HTTP server on startup, and now waits for WebSocket connections, at which time it's supposed to make HTTP requests to the HTTP server for various reasons.
Problem is, the HTTP client times out after 5s. While I want it to be long lived. I've read Vinnie's answer in https://stackoverflow.com/a/56880415/103724 about sync operation not having timeouts, but I don't want to control timeouts of individual requests here (for now at least), I want to not have the underlying socket not timeout on its own, the same way a WebSocket does not timeout either. Is that possible? Who controls that 5s timeout?
Would switching to an async HTTP client make any difference? Sounds to me that it would allow me to control timeouts of requests, but would it make any difference to the socket timeout described above?
Thanks, --DD
Not that I tried to obvious below, to stream_.expires_never() on the client side, and that doesn't make a difference. ``` beast::error_code ec; impl_->resolved_to_ = impl_->resolver_.resolve( impl_->host_, std::to_string(port), ec ); if (!ec) { impl_->stream_.connect(impl_->resolved_to_, ec); } if (ec) { [...] return false; } impl_->stream_.expires_never(); ``` Also tried adding the stream_.expires_never() on the server-side ``` // Take ownership of the stream session( const ServerConfig& config, tcp::socket&& socket ) : config_(config) , stream_(std::move(socket)) { stream_.expires_never(); } ``` Still the 5s timeout :(
On Tue, Dec 15, 2020 at 2:23 PM Richard Hodges via Boost-users < boost-users@lists.boost.org> wrote:
Problem is, the HTTP client times out after 5s.
When you say that the client times out, what exactly is timing out?
A client async_read operation, async_write? Is the server simply dropping your connection because of inactivity?
The latter I think. The client does nothing, beside connecting. It sits idle, waiting for WebSocket connection. (again, the HTTP client is a WebSocket server too, using separate io_context for both). Here's the HTTP server log: Connection from [::1]:59300 Error: on_read: The socket was closed due to a timeout Where the on_read error comes after ~5s (I should put the timestamps back...) BTW, I tried adding get_lowest_layer(stream_) before calling expires_never(), no change :( PS: This is on Windows. Haven't tried this on Linux yet.
On Tue, Dec 15, 2020 at 2:29 PM Dominique Devienne
On Tue, Dec 15, 2020 at 2:23 PM Richard Hodges via Boost-users < boost-users@lists.boost.org> wrote:
Problem is, the HTTP client times out after 5s.
When you say that the client times out, what exactly is timing out?
A client async_read operation, async_write? Is the server simply dropping your connection because of inactivity?
OK, this is ambarassing... The timeout was right there in the server's code. Once removed, everything's fine of course. Sorry for the noise. --DD void do_read() { // Make the request empty before reading, // otherwise the operation behavior is undefined. req_ = {}; // Set the timeout. //stream_.expires_after(std::chrono::seconds(5)); // Read a request http::async_read( stream_, buffer_, req_, beast::bind_front_handler( &session::on_read, shared_from_this() ) ); }
participants (2)
-
Dominique Devienne -
Richard Hodges