[Buildbot-devel] lazy logs a bit too lazy and que'ed requests not being processed
Dustin J. Mitchell
dustin at v.igoro.us
Mon Oct 20 19:57:34 UTC 2014
Try *not* using Fiddler (it's just one more, unnecessary variable),
and if it still doesn't work, try using Wireshark to capture traffic
between your browser and Buildbot.
Dustin
On Mon, Oct 20, 2014 at 1:07 PM, Francesco Di Mizio
<francescodimizio at gmail.com> wrote:
> Some more info I got from Fiddler:
>
> SESSION STATE: ReadingResponse.
> DOWNLOAD PROGRESS: 33,614 bytes.
>
>
> == FLAGS ==================
> BitFlags: [ClientPipeReused, ServerPipeReused] 0x18
> X-CLIENTIP: 127.0.0.1
> X-CLIENTPORT: 51030
> X-EGRESSPORT: 51031
> X-HOSTIP: 192.168.15.174
> X-PROCESSINFO: chrome:10936
> X-SERVERSOCKET: REUSE ServerPipe#3
>
> == TIMING INFO ============
> ClientConnected: 18:53:10.904
> ClientBeginRequest: 18:53:14.133
> GotRequestHeaders: 18:53:14.133
> ClientDoneRequest: 18:53:14.133
> Determine Gateway: 0ms
> DNS Lookup: 0ms
> TCP/IP Connect: 0ms
> HTTPS Handshake: 0ms
> ServerConnected: 18:53:10.905
> FiddlerBeginRequest: 18:53:14.133
> ServerGotRequest: 18:53:14.133
> ServerBeginResponse: 18:53:14.138
> GotResponseHeaders: 18:53:14.138
> ServerDoneResponse: 00:00:00.000
> ClientBeginResponse: 00:00:00.000
> ClientDoneResponse: 00:00:00.000
>
>
> The response was buffered before delivery to the client.
>
> == WININET CACHE INFO ============
> This URL is not present in the WinINET cache. [Code: 2]
> * Note: Data above shows WinINET's current cache state, not the state at the
> time of the request.
> * Note: Data above shows WinINET's Medium Integrity (non-Protected Mode)
> cache only.
>
>
> DOWNLOAD PROGRESS keeps increasing during the step's execution. Just nothing
> is being shown.
> Also this sounds suspicious: The response was buffered before delivery to
> the client.
>
>
> On Mon, Oct 20, 2014 at 2:54 PM, Francesco Di Mizio
> <francescodimizio at gmail.com> wrote:
>>
>> GET /builders/test_linux/builds/398/steps/shell/logs/stdio HTTP/1.1
>> Host: 192.168.15.174:8010
>> Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
>> Accept-Encoding: gzip,deflate,sdch
>> Accept-Language: en-US,en;q=0.8,it;q=0.6
>> Cookie: BuildBotSession=4101a104fb9b505021468f7b7ee745e0bdf7adac
>> Referer: http://192.168.15.174:8010/builders/test_linux/builds/398
>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
>> like Gecko) Chrome/37.0.2062.124 Safari/537.36
>>
>> HTTP/1.1 200 OK
>> Cache-Control: max-age=604800
>> Content-Type: text/html; charset=utf-8
>> Date: Mon, 20 Oct 2014 12:51:28 GMT
>> Server: TwistedWeb/13.2.0
>> Transfer-Encoding: chunked
>>
>> Once again, I can't see the response header until the step is over.
>>
>> Cheers,
>> FDM
>>
>>
>> On Mon, Oct 20, 2014 at 2:10 PM, Benoît Allard
>> <benoit.allard at greenbone.net> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 10/20/2014 11:53 AM, Francesco Di Mizio wrote:
>>> > My production setup is indeed accessed via proxy (apache + mod
>>> > proxy). Initially we all assumed that was the problem.
>>> >
>>> > After messing around with some proxy settings and seeing not light
>>> > at the end of the tunnel, I tried a fresh install using a simple
>>> > config with no proxy. It did not help.
>>> >
>>>
>>> In my experience mod_proxy did not had the trouble nginx had by default.
>>>
>>> But there also exist transparent proxies ...
>>>
>>> Look at the HTTP headers of the pages served by buildbot (somewhere
>>> inside your browser, depends on the browser), one of them should
>>> indicate what's happening ...
>>>
>>> The technology used by buildbot there is called "Chunked transfer
>>> encoding", and (as I said) is known to give some troubles with some
>>> proxies that wait for the connection to be closed to 'proxy' it. If
>>> you mention that to your network administrator, it might shed some
>>> lights ...
>>>
>>> Good luck.
>>>
>>> - --
>>> Benoît Allard (B30A05B0)|Greenbone Networks GmbH|http://greenbone.net
>>> Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
>>> Executive Directors: Lukas Grunwald, Dr. Jan-Oliver Wagner
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>
>>> iQEcBAEBAgAGBQJURPvGAAoJEHZCfVOzCgWwyaMH/0VEKFFM8tsdykUzxZbSPLzG
>>> 54RFzL8//WVcMO4zflGdqGPmNAhuGIaHDz1+uVl9S+yvmDtL5xtZ3DOFDhyi1iAw
>>> 8rW73OUQHJIokXtJwHJDf9JN960dSpR6E/L7KibNooc+TWEmUv0HIdmSDBpdSUdK
>>> HmBa3VNlBHJ/43LfKn6YbbKkRfHEaLYB2BGp87GRiT/WqmMiSn/w8AGTKyyuog36
>>> CHu0tWwqm2SR+xeU7wYt6YyYRxDD0jJaPgObHD0p2dsJ6FrGElMz9bs2+puydchG
>>> GqfgdxiJwDmS6XKVCjutXAdW2LX5uYkfVKzbutF/Wp/b0VksV6fN9z6d+y5HlfQ=
>>> =s7lZ
>>> -----END PGP SIGNATURE-----
>>
>>
>
More information about the devel
mailing list