No new connections after max_connections reached

[EtienneBruines]

Your issue may already be reported!
Please search on the Actix Web issue tracker before creating one.

Expected Behavior

After handling a request, the server should be able to handle another request.

Current Behavior

With max_connections set to 1, the server will handle one single request, and then no more.

(Note that this is with workers(1), backlog(0) and keep_alive(None))

Possible Solution

Steps to Reproduce (for bugs)

1. Use the example code below
2. Make one HTTP request using curl --no-keepalive -v http://localhost:8082/ (will return a 404, which is fine)
3. Make a second HTTP request (this is where it fails)

➜  ~ curl http://localhost:8082/ -v --no-keepalive
*   Trying 127.0.0.1:8082...
* Connected to localhost (127.0.0.1) port 8082 (#0)
> GET / HTTP/1.1
> Host: localhost:8082
> User-Agent: curl/7.74.0
> Accept: */*
> 

5. Make a third HTTP request (will also fail, but slightly different look)

➜  ~ curl http://localhost:8082/ -v --no-keepalive
*   Trying 127.0.0.1:8082...
* connect to 127.0.0.1 port 8082 failed: Connection timed out
* Failed to connect to localhost port 8082: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to localhost port 8082: Connection timed out

Example code

use actix_web::{get, web, App, HttpServer};
use tracing::Level;

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let _collector = tracing_subscriber::fmt()
        .with_max_level(Level::TRACE)
        .init();

    HttpServer::new(|| App::new())
        .workers(1)
        .max_connections(1)
        .backlog(0)
        .bind("127.0.0.1:8082")?
        .shutdown_timeout(5)
        .keep_alive(None)
        .run()
        .await
}

[package]
name = "my-project"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
actix-web = "4"
tokio = { version = "1.17.0" , features = ["time"] }
tracing = "0.1.32"
tracing-subscriber = "0.3.9"

Context

Your Environment

rustc 1.61.0-nightly (68369a041 2022-02-22)

Logs

2022-03-19T18:58:20.376299Z  INFO actix_server::builder: Starting 1 workers
2022-03-19T18:58:20.376378Z  INFO actix_server::server: Actix runtime found; starting in Actix runtime
2022-03-19T18:58:20.376430Z TRACE actix_server::worker: starting server worker 0
2022-03-19T18:58:20.376675Z TRACE mio::poll: registering event source with poller: token=Token(0), interests=READABLE | WRITABLE    
2022-03-19T18:58:20.377098Z TRACE mio::poll: registering event source with poller: token=Token(0), interests=READABLE    
2022-03-19T18:58:20.377112Z TRACE actix_server::worker: Service "actix-web-service-127.0.0.1:8082" is available
2022-03-19T18:58:20.377191Z TRACE actix_server::signals: setting up OS signal listener
2022-03-19T18:58:23.849938Z TRACE mio::poll: registering event source with poller: token=Token(1), interests=READABLE | WRITABLE    
2022-03-19T18:58:23.850138Z TRACE actix_http::h1::dispatcher: start flags: (empty)    
2022-03-19T18:58:23.850175Z TRACE actix_http::h1::dispatcher: start timers:    
2022-03-19T18:58:23.850197Z TRACE actix_http::h1::dispatcher:   head timer is inactive    
2022-03-19T18:58:23.850219Z TRACE actix_http::h1::dispatcher:   shutdown timer is inactive    
2022-03-19T18:58:23.850312Z TRACE actix_http::h1::dispatcher: end timers:    
2022-03-19T18:58:23.850341Z TRACE actix_http::h1::dispatcher:   head timer is active and due to expire in 4526.723 milliseconds    
2022-03-19T18:58:23.850367Z TRACE actix_http::h1::dispatcher:   shutdown timer is inactive    
2022-03-19T18:58:23.850389Z TRACE actix_http::h1::dispatcher: end flags: STARTED    
2022-03-19T18:58:23.850502Z TRACE actix_http::h1::dispatcher: start flags: STARTED    
2022-03-19T18:58:23.850533Z TRACE actix_http::h1::dispatcher: start timers:    
2022-03-19T18:58:23.850555Z TRACE actix_http::h1::dispatcher:   head timer is active and due to expire in 4526.51 milliseconds    
2022-03-19T18:58:23.850579Z TRACE actix_http::h1::dispatcher:   shutdown timer is inactive    
2022-03-19T18:58:23.851110Z TRACE actix_http::h1::dispatcher: start flags: STARTED | SHUTDOWN    
2022-03-19T18:58:23.851151Z TRACE actix_http::h1::dispatcher: start timers:    
2022-03-19T18:58:23.851174Z TRACE actix_http::h1::dispatcher:   head timer is inactive    
2022-03-19T18:58:23.851196Z TRACE actix_http::h1::dispatcher:   shutdown timer is inactive    
2022-03-19T18:58:23.851265Z TRACE actix_http::h1::dispatcher: end flags: STARTED | SHUTDOWN    
2022-03-19T18:58:23.851304Z TRACE mio::poll: deregistering event source from poller    

[fakeshadow]

actix-net/actix-server/src/worker.rs

Line 103 in 855e3f9

self.counter.fetch_sub(1, Ordering::Relaxed) == self.limit

It should have been fetch_sub - 1

[RLuzi]

Good morning, the change suggested in the previous comment should have solved the problem? Because I was able to reproduce the problem in the example described at the beginning of the issue. So, I was wondering if it had been resolved any more. Thanks in advance.

[RLuzi]

@robjtede I think I have found the root cause of the problem: the counter used to count the number of simultaneous connections starts at one. The functions used to increment and decrement the counter return the previous value of the counter. This does not seem to be a problem when the counter is incremented, but it is when it is decremented for two different reasons (I think):

• the first relates to this problem: since the counter starts at 1, when a new connection is accepted, the new value will be 2. When the connection is broken, and therefore the counter is decremented, the previous value is 2 and not 1. Since a worker is woken up when the previous value is equal to the limit, this will never happen when the limit of maximum connections is set to 1.
• The second is more general: if I set the limit to, for example, 6, a worker will be made unavailable when the counter reaches 7 (according to the checks made). Therefore, in order to be woken up, the counter must be decremented twice to pass the check made (because decrementing once would be 7 == 6, i.e. the previous value of the counter and the limit). In this way, once the limit is reached, I will have to close at least (in the worst case) worker number - 1 connections in order to manage new ones.
  I wrote worker number - 1 one because, in the worst case, to have at least one worker awaken a connection needs to be closed for each of them and another one for one of them.