Websocket server finished() isn't called if client disconnects

[sapir]

I was trying to do the websocket tutorial/examples and implement a chat, and found that my server code wasn't cleaning up clients when they disconnected. Even when running the websocket example, the StreamHandler's finished() method doesn't ever get called. That is, if I add a finished() method to examples/websocket/src/main.rs, similar to the client one, and run:

cd examples/websocket
cargo run --bin server

and also

cd examples/websocket
cargo run --bin client

and then hit CTRL-C on the client, then the server doesn't notice. Whereas if I hit CTRL-C on the server, the client does get a "Server disconnected" message within a few seconds, meaning finished() was called.

(Also, I noticed that the server is using WebsocketContext, while the client is using a regular Context. Shouldn't the client also use WebsocketContext?)

netstat shows that the client closes its half of the socket for writing / sends a FIN (FIN_WAIT2 state) while the server is keeping its half open (CLOSE_WAIT state).

This also happens with current actix-web/master / 0.7.8 and actix 0.7.0. I also tried actix master, but then the example doesn't compile anymore.

I'm not sure if my experiences can help.

I was making a small desktop program to monitor my server program by repeatedly polling its internal api (like example.com/api/stats). That desktop program used futures + tokio crates, similar to this:

extern crate futures;
extern crate tokio;

use futures::{future, Future};
use tokio::runtime::Runtime;

fn main() {
    loop {
        poll_stats();
        thread::sleep(...);
    }
}

fn poll_stats() {
    let mut runtime = Runtime::new().unwrap();
    runtime.block_on(...).unwrap();
    runtime.shutdown_now().wait().unwrap();
}

I know that was not good use of those crates. But personally I think that pattern was still valid use:

1. Make new runtime.
2. Block on one single job.
3. Shutdown.
4. Repeat from 1.

However after running for several days, I noticed that the program started to eat RAM, then it couldn't spawn new job anymore. Running lsof -p <pid> revealed that there were hundreds of unclosed ESTABLISHED TCP connections to my server. I tried some more times, and it happened again and again.

Then I switched to futures::future::loop_fn(). Now the program is running on my desktop. It's polling the server right now with no unclosed connections.

Again, I'm really not sure if this can help. I can't prove anything from that experience. :-( But in my thinking, I guess there might be some bug in the futures crate.