httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: prefetch proxy
Date Tue, 08 Nov 2011 19:49:42 GMT
Cool info… I'm (painfully) building Jenkins here locally and will
try to get a bt on the actual scenario…

On Nov 8, 2011, at 11:00 AM, Jeff Trawick wrote:

> On Tue, Nov 8, 2011 at 9:37 AM, Jim Jagielski <jim@jagunet.com> wrote:
>> Here is the method for the Jenkins CLI that causes all the sadness.
>> The major section is this:
> 
> Thanks for the testcase!
> 
> The EAGAIN is getting generated from here:
> 
> static apr_status_t get_remaining_chunk_line(http_ctx_t *ctx,
>                                             apr_bucket_brigade *b,
>                                             int linelimit)
> {
>    apr_status_t rv;
>    apr_off_t brigade_length;
>    apr_bucket *e;
>    const char *lineend;
>    apr_size_t len = 0;
> 
>    /*
>     * As the brigade b should have been requested in mode AP_MODE_GETLINE
>     * all buckets in this brigade are already some type of memory
>     * buckets (due to the needed scanning for LF in mode AP_MODE_GETLINE)
>     * or META buckets.
>     */
>    rv = apr_brigade_length(b, 0, &brigade_length);
>    if (rv != APR_SUCCESS) {
>        return rv;
>    }
>    /* Sanity check. Should never happen. See above. */
>    if (brigade_length == -1) {
>        return APR_EGENERAL;
>    }
>    if (!brigade_length) {
>        return APR_EAGAIN;       <<<<<<<<<< here
>    }
> 
> Breakpoint 2, get_remaining_chunk_line (ctx=0x20061b8, b=0x2006210,
> linelimit=8190) at http_filters.c:132
> 132	        return APR_EAGAIN;
> (gdb) where
> #0  get_remaining_chunk_line (ctx=0x20061b8, b=0x2006210,
> linelimit=8190) at http_filters.c:132
> #1  0x000000000046c4d6 in get_chunk_line (ctx=0x20061b8, b=0x2006210,
> linelimit=8190) at http_filters.c:213
> #2  0x000000000046cef6 in ap_http_filter (f=0x2003520, b=0x2006178,
> mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=16384)
>    at http_filters.c:386
> #3  0x0000000000432ccc in ap_get_brigade (next=0x2003520,
> bb=0x2006178, mode=AP_MODE_READBYTES, block=APR_BLOCK_READ,
> readbytes=16384)
>    at util_filter.c:496
> #4  0x00007facf66955e2 in ap_proxy_http_request (p=0x2001cf8,
> r=0x2001d70, p_conn=0x1f83880, worker=0x1e87190, conf=0x1e86b10,
>    uri=0x2003930, url=0x20039d8 "/cgi-bin/readbody.pl",
> server_portstr=0x7faced7469c0 ":8080") at mod_proxy_http.c:1026
> #5  0x00007facf6698cfc in proxy_http_handler (r=0x2001d70,
> worker=0x1e87190, conf=0x1e86b10,
>    url=0x200386e "http://127.0.0.1:8080/cgi-bin/readbody.pl",
> proxyname=0x0, proxyport=0) at mod_proxy_http.c:2153
> #6  0x00007facf6cb9c59 in proxy_run_scheme_handler (r=0x2001d70,
> worker=0x1e87190, conf=0x1e86b10,
>    url=0x200386e "http://127.0.0.1:8080/cgi-bin/readbody.pl",
> proxyhost=0x0, proxyport=0) at mod_proxy.c:2520
> #7  0x00007facf6cb5353 in proxy_handler (r=0x2001d70) at mod_proxy.c:1055
> #8  0x000000000044efe2 in ap_run_handler (r=0x2001d70) at config.c:168
> 
> At the moment I'm guessing that the chunk-specific path may be missing
> handling for unexpected EOF or some other error path.
> 
> My testcase based on the Jenkins code you pasted isn't doing anything
> to provide a valid body, so there could be a difference in scenario
> which just happens to result in the same error code.  We'll see.
> 


Mime
View raw message