hjr3 / weldr

A HTTP 1.1 proxy written in Rust using tokio.
Apache License 2.0
218 stars 20 forks source link

timeout when trying with the test backend #1

Closed yanns closed 8 years ago

yanns commented 8 years ago

Hi,

I am trying to run your proxy locally, and I always see the following error message:

ERROR:alacrity: Error trying proxy - Error { repr: Custom(Custom { kind: TimedOut, error: StringError("Pool connection timeout") }) }

The test server outputs:

Read 0 bytes
Wrote 0 bytes

I am running on Mac. If I can help find this issue, please tell me! ;)

yanns commented 8 years ago

Some more log:

RUST_LOG=alacrity=trace cargo run --bin alacrity
    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/alacrity`
INFO:alacrity::pool: Load balancing server V4(127.0.0.1:12345)
INFO:alacrity: Listening on: 127.0.0.1:8080
DEBUG:alacrity: Incoming connection on 127.0.0.1:57013
DEBUG:alacrity::pool: Pool is cloaning (hehe) out 127.0.0.1:12345
ERROR:alacrity: Error trying proxy - Error { repr: Custom(Custom { kind: TimedOut, error: StringError("Pool connection timeout") }) }
hjr3 commented 8 years ago

I will take a look in about 1 hour.

yanns commented 8 years ago

One guess (I'm quite new to rust and futures):

        let connect_timer = futures::finished(timeout).map(Err);

creates a Future that is already finished, but we'd like a Future that terminates after the timeout, no?

Instead, we could directly use the timeout future, like let connect_timer = timeout.map(Err);? With that change, I do not have this error anymore. But I don't know how to test the timeout, if it's working or if I totally broke it.

hjr3 commented 8 years ago

@yanns that is a solid fix. it took me a while to figure out why this was ever working. apparently, when i was in full debug mode the timeout would not fire, but it would fire if i lowered the debug mode.

you are right about the way futures::finished worked too