On Tue, Oct 27, 2015 at 7:10 PM, Bert Huijben <b...@qqmail.nl> wrote: > > What error is '11' for you? APR_EAGAIN?
11 is EAGAIN, yes. > > Or perhaps APR_EOF like in your previous report? As in the previous report, when it finally times out I get: 2015-10-28T08:21:20.499352-04 DEBUG [l:2620:0:1004:2:6c57:4dc:8e89:3aea:39286 r:2607:f8b0:4006:808::1012:443] third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: ssl_decrypt: 70014 0 E1028 08:21:20.499403 28398 google_message_handler.cc:59] Serf status 120108(APR does not understand this error code) polling for 1 threaded fetches for 0.05 seconds 2015-10-28T08:21:20.550097-04 DEBUG [l:2620:0:1004:2:6c57:4dc:8e89:3aea:39286 r:2607:f8b0:4006:808::1012:443] third_party/instaweb/src/third_party/serf/instaweb_outgoing.c: closed socket, status 0 The 70014 is APR_EOF. The 120108 is "The server unexpectedly closed the connection prematurely", or SERF_ERROR_ABORTED_CONNECTION. > (Completely different error range than the errors you reported last time) I'm pretty sure these are the same errors I got last time. Within the spinning section I get 11 (EAGAIN) repeatedly, when it's all done I get 70014 (APR_EOF) and 120108 (SERF_ERROR_ABORTED_CONNECTION). > > I'm surprised that I don't see familiar filenames; are you just running the > normal serf context loop? Or is it completely embedded in something else with > its own event handling? > I'm invoking serf from a wrapper class in mod_pagespeed, SerfUrlAsyncFetcher, but serf still has it's own context loop. The filenames are slightly different (instaweb_foo instead of foo) because we need to make some changes to get it to compile in our system, like removing unused variables. > > Did you try the serf_get test tool against that same server and check how > that responded? > I think you can enable its logging by simply passing -d. I haven't tried that; I'll check. > > Those hosts in your log appear to be one of the many www.google.com > addresses; I have no problem connecting to those using serf. > (Testing: $ serf_get -d -H https://216.58.219.228/ ) These logs are from connecting to "https//www.google.com", but I get this on all the other https addresses I've tried as well. https://www.example.com https://https.cio.gov/ https://en.wikipedia.org/wiki/HTTPS https://www.eff.org/https-everywhere > Looking a bit further I see that the result on this host is a 301 redirect > response, forwarding to > http://www.google.com:443/ > Which is probably not a good url to test against. (I don't think port 443 > allows plain http :-) Weird things happen if you don't give the host header. Among other things, https://216.58.219.228/ should fail the certificate check. > > Looping on APR_EAGAIN for every few bytes during the ssl handshake is not > that uncommon... you should see bigger chunks later in the connection. As > Serf doesn't block the connection many logged ssl errors with EAGAIN status > are fairly common, but the only thing they tell you is that your CPU is > faster than your network connection to the server. > I see. Some looping here makes sense. What I'm seeing, though, is many seconds of looping followed by serf reporting a fetch failure.
