You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if counter.next().unwrap() && Instant::now() >= deadline {
returnOk(copied);
}
}
}
In here the timeout is only checked after the read operation is issued. However, a call to read()may block according to the documentation. If used on a reader that reads from a network socket, IIRC it will block waiting for data from the remote server until the underlying TCP timeout expires (5 minutes by default).
I believe this is a fundamental limitation of the approach; I am not aware of any ways to fix it without spawning an auxiliary thread or using an async runtime.
If a read timeout is desired, it should be configured on the socket explicitly instead.
If a timeout for the entire request is desired, it can be implemented either by spawning an auxiliary thread that interrupts the main thread (as done in attohttpc), or by setting the read timeout to the minimum of read timeout and the remaining time until the deadline for the entire request (as done in minreq).
The text was updated successfully, but these errors were encountered:
The issue was waiting for quite some time. v0.11.0 implements improved solution for handling timeout for the entire request.
The data is read from TCP stream on a separate thread and send over to main thread via mpsc::channel. The data is send in chunks.
The main thread is receiving the data and checking if deadline is not exceeded. It stops the operation when deadline is exceeded. In addition to that receiving is done using recv_timeout with timeout dynamically calculated based on time left before deadline.
copy_with_timeout()
as implemented in v0.7.2 may exceed its deadline:http_req/src/request.rs
Lines 50 to 75 in eba0471
In here the timeout is only checked after the read operation is issued. However, a call to
read()
may block according to the documentation. If used on a reader that reads from a network socket, IIRC it will block waiting for data from the remote server until the underlying TCP timeout expires (5 minutes by default).I believe this is a fundamental limitation of the approach; I am not aware of any ways to fix it without spawning an auxiliary thread or using an async runtime.
If a read timeout is desired, it should be configured on the socket explicitly instead.
If a timeout for the entire request is desired, it can be implemented either by spawning an auxiliary thread that interrupts the main thread (as done in
attohttpc
), or by setting the read timeout to the minimum of read timeout and the remaining time until the deadline for the entire request (as done inminreq
).The text was updated successfully, but these errors were encountered: