search

tatsuhiro-t / spdylay

The experimental SPDY protocol version 2, 3 and 3.1 implementation in C
http://tatsuhiro-t.github.io/spdylay/
MIT License
604 stars 102 forks source link

Implement SPDY stream level timeout #108

Open fcicq opened 10 years ago

fcicq commented 10 years ago

sadly I'm not sure why the server stopped responding if something is triggered in issue #107, so I often have to restart shrpx :(

tatsuhiro-t commented 10 years ago

You mean remote SPDY proxy stop responding? Have you tried backend timeouts?

--backend-read-timeout=<SEC>
                 Specify read timeout for backend connection.
--backend-write-timeout=<SEC>
                 Specify write timeout for backend

I have fixed similar problems before. Are you using latest code?

tatsuhiro-t commented 10 years ago

Also providing complete log helps me understand the situation.

fcicq commented 10 years ago

shrpx -p -b 127.0.0.1,4443 -f 127.0.0.1,8001 -k -L INFO --backend-read-timeout=3 --backend-write-timeout=3

... (curl --proxy 127.0.0.1:8001 www.sina.com.cn for many times, to trigger the remote spdy server stop responding, works well until here) [INFO] [LISTEN:0x7fc322f23ff0] Accepted connection. fd=10 (shrpx_listen_handler.cc:97) [INFO] [UPSTREAM:0x7fc322e00600] HTTP request started (shrpx_https_upstream.cc:78) [INFO] [UPSTREAM:0x7fc322e00600] HTTP request headers completed (shrpx_httpsupstream.cc:135) [INFO] [UPSTREAM:0x7fc322e00600] HTTP request headers GET HTTP://www.sina.com.cn/ HTTP/1.1 User-Agent: curl/7.30.0 Host: www.sina.com.cn Accept: /_ Proxy-Connection: Keep-Alive

   (shrpx_https_upstream.cc:156)

[INFO] [CLIENT_HANDLER:0x7fc322e004e0] Downstream connection pool is empty. Create new one (shrpx_client_handler.cc:278) [INFO] [DCONN:0x7fc322e00210] Attaching to DOWNSTREAM:0x7fc322e00670 (shrpx_spdy_downstream_connection.cc:103) [INFO] [DCONN:0x7fc322e00210] HTTP request headers (removed)

   (shrpx_spdy_downstream_connection.cc:354)

[INFO] [UPSTREAM:0x7fc322e00600] HTTP request completed (shrpx_https_upstream.cc:227) (waiting and waiting... tcp ack is received confirmed by tcpdump)

env: macosx 10.9.2 / ubuntu linux 13.10

mac: brew list --versions autoconf 2.69 automake 1.14.1 libevent 2.0.21 libtool 2.4.2 libxml2 2.9.1 openssl 1.0.1f pkg-config 0.28 spdylay HEAD

ubuntu: libevent 2.0.21-stable-1

hmm... please send a mail to fcicq at fcicq dot net and I'll give you the full command :(

tatsuhiro-t commented 10 years ago

Timeout for SPDY session was not implemented. This was deliberate decision since SPDY is long lived connection and we just rely on the server to disconnect. But our recent experience shows that timeout is useful especially when connection is unstable (e.g., mobile). The commit 0391a3d adds backend SPDY connection timeout. Note that this timeout is for TCP connection, not the SPDY stream. SPDY stream level timeouts have not been implemented in shrpx.

Meanwhile, from your writings, the remote SPDY proxy seems to swallow HTTP requests but does not respond at all. I'd like to know the problem may be in remote SPDY proxy or not. Are you using shrpx as remote SPDY proxy? Or other products?

We may need log for remote SPDY server if you manages it.

You can reach me at t-tujikawa at users dot sourceforge dot net