> -----Original Message----- > From: Jeff Kaufman [mailto:jef...@google.com] > Sent: dinsdag 27 oktober 2015 21:58 > To: Bert Huijben <b...@qqmail.nl> > Cc: Jeff Kaufman <jef...@google.com.invalid>; dev@serf.apache.org; > Jeffrey Crowell <jcrow...@google.com>; Maksim Orlovich > <morlov...@google.com> > Subject: Re: Spin when fetching resources over SSL > > I just rebuilt against trunk at r1710846 and ran into this again: > > 2015-10-27T16:52:31.589023-04 DEBUG > [l:2620:0:1004:2:6c57:4dc:8e89:3aea:53729 > r:2607:f8b0:4006:80e::2004:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > ssl_decrypt: begin 8000 > 2015-10-27T16:52:31.589029-04 DEBUG > [l:2620:0:1004:2:6c57:4dc:8e89:3aea:53729 > r:2607:f8b0:4006:80e::2004:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > bio_bucket_read called for 5 bytes > 2015-10-27T16:52:31.589043-04 DEBUG > [l:2620:0:1004:2:6c57:4dc:8e89:3aea:53729 > r:2607:f8b0:4006:80e::2004:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > SSL_connect:read error in SSLv3 read server session ticket A: > ssl_error=2, status=11 > 2015-10-27T16:52:31.589048-04 DEBUG > [l:2620:0:1004:2:6c57:4dc:8e89:3aea:53729 > r:2607:f8b0:4006:80e::2004:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > ssl_decrypt: 11 0 > > I was curious if this might be ipv6 related, but after disabling ipv6 > I got the same problem: > > 2015-10-27T16:55:51.974660-04 DEBUG [l:172.29.73.76:57202 > r:216.58.219.228:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > ssl_decrypt: begin 8000 > 2015-10-27T16:55:51.974667-04 DEBUG [l:172.29.73.76:57202 > r:216.58.219.228:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > bio_bucket_read called for 5 bytes > 2015-10-27T16:55:51.974679-04 DEBUG [l:172.29.73.76:57202 > r:216.58.219.228:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > SSL_connect:read error in SSLv3 read server session ticket A: > ssl_error=2, status=11 > 2015-10-27T16:55:51.974684-04 DEBUG [l:172.29.73.76:57202 > r:216.58.219.228:443] > third_party/instaweb/src/third_party/serf/instaweb_ssl_buckets.c: > ssl_decrypt: 11 0 > > It still just loops here printing the same messages over and over until > timeout.
What error is '11' for you? APR_EAGAIN? Or perhaps APR_EOF like in your previous report? (Completely different error range than the errors you reported last time) 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? 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. 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/ ) 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. Bert
