Re: Incomplete responses for some requests

[Dridi Boukelmoune]

On Sat, Sep 17, 2016 at 2:21 AM, Carl Alexander
 wrote:
>> Are you able to reproduce this in a minimal environment? That would help a
>> lot but in any case I think it's worth opening a ticket.
>
> Do you have an example of a minimal environment that I could do this on? Or
> do you mean using the default vcl file?

No, I meant reproducing the bug with as little VCL as possible on a
simple application. Basically not dragging your whole backend to
reproduce the bug.

For non-regression tests (or tests in general) we use `varnishtest`
where we can mock clients and backends to run varnish in a controlled
environment.

Cheers

___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Incomplete responses for some requests

[Carl Alexander]

> Are you able to reproduce this in a minimal environment? That would help
a lot but in any case I think it's worth opening a ticket.

Do you have an example of a minimal environment that I could do this on? Or
do you mean using the default vcl file?

On Fri, Sep 16, 2016 at 2:47 PM, Dridi Boukelmoune <
dr...@varnish-software.com> wrote:

> > So this gives credence that something is going on inside Varnish. Should
> I create a ticket for this? I've hit the limit of my ability
> troubleshooting this at the moment.
>
> Are you able to reproduce this in a minimal environment? That would help a
> lot but in any case I think it's worth opening a ticket.
>
> Cheers
>
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Incomplete responses for some requests

[Carl Alexander]

I've managed to find a workaround to the issue. If I use "return(pipe)"
instead of "return(pass)" in my vcl, the problem disappears. That said,
this isn't ideal at all. I shouldn't have to use pipe for HTML content.

So this gives credence that something is going on inside Varnish. Should I
create a ticket for this? I've hit the limit of my ability troubleshooting
this at the moment.

On Wed, Sep 14, 2016 at 5:45 PM, Carl Alexander <
carlalexan...@globalvoices.org> wrote:

> Hi everyone,
>
> I'm having a weird issue that I have no idea how to solve. I have a setup
> where I have varnish sitting between two vhosts. An SSL termination proxy
> which forwards requests to varnish who forwards them to a backend.
>
> The setup works perfectly for 99% of pages. But, for certain pages,
> varnish seems to choke and only returns part of the html response. This can
> happen consistently or at random for the same page. It also varies between
> browsers sometimes.
>
> When digging into varnishlog, I can find this FetchError for the backend:
>
> -   Fetch_Body 4 eof stream
> -   FetchError Resource temporarily unavailable
> -   FetchError eof socket fail
> -   BackendClose   24 boot.webserver
> -   BereqAcct  1274 0 1274 333 32554 32887
> -   End
>
>
> So I figured that maybe it's a nginx issue. When I turn on debug logs,
> nginx tells me that it's varnish that closed the connection. It was never
> able to send the complete html response back (that's probably why it's
> truncated). Here's the nginx logs:
>
>
> 2016/09/14 23:49:08 [info] 24670#24670: *566 epoll_wait() reported that
> client prematurely closed connection, so upstream connection is closed too
> while reading upstream
>
>
> So on one side, I have varnish saying that nginx became unavailable. And
> on the other, I have nginx telling me that varnish closed the connection. I
> don't know which one is right.
>
> But if I remove varnish and send the proxy request to the backend
> directly, everything works. So the signs seem to point to varnish, but I
> can't seem to find what's causing this. It started on Varnish 4.1.1, but
> upgrading to 4.1.3 didn't change anything.
>
> I'm also not sure how to troubleshoot this further. I tried to look at the
> varnish source code. The FetchError is just a generic C error so I don't
> have much else to go on.
>
> I've also attached the output of "param.show" below:
>
> accept_filter  off [bool] (default)
> acceptor_sleep_decay   0.9 (default)
> acceptor_sleep_incr0.000 [seconds] (default)
> acceptor_sleep_max 0.050 [seconds] (default)
> auto_restart   on [bool] (default)
> backend_idle_timeout   60.000 [seconds] (default)
> ban_dups   on [bool] (default)
> ban_lurker_age 60.000 [seconds] (default)
> ban_lurker_batch   1000 (default)
> ban_lurker_sleep   0.010 [seconds] (default)
> between_bytes_timeout  60.000 [seconds] (default)
> cc_command "exec gcc -std=gnu99 -g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Werror
> -Wno-error=unused-result -pthread -fpic -shared -Wl,-x -o %o %s" (default)
> cli_buffer 8k [bytes] (default)
> cli_limit  48k [bytes] (default)
> cli_timeout60.000 [seconds] (default)
> clock_skew 10 [seconds] (default)
> connect_timeout3.500 [seconds] (default)
> critbit_cooloff180.000 [seconds] (default)
> debug  none (default)
> default_grace  10.000 [seconds] (default)
> default_keep   0.000 [seconds] (default)
> default_ttl3600.000 [seconds]
> featurenone (default)
> fetch_chunksize16k [bytes] (default)
> fetch_maxchunksize 0.25G [bytes] (default)
> first_byte_timeout 60.000 [seconds] (default)
> gzip_buffer32k [bytes] (default)
> gzip_level 6 (default)
> gzip_memlevel  8 (default)
> http_gzip_support  on [bool] (default)
> http_max_hdr   64 [header lines] (default)
> http_range_support on [bool] (default)
> http_req_hdr_len   8k [bytes] (default)
> http_req_size  32k [bytes] (default)
> http_resp_hdr_len  8k [bytes] (default)
> http_resp_size 32k [bytes] (default)
> idle_send_timeout  60.000 [seconds] (default)
> listen_depth   1024 [connections] (default)
> lru_interval   2.000 [seconds] (default)
> max_esi_depth  5 [levels] (default)
> max_restarts   4 [restarts] (default)
> max_retries4 [retries] (default)
> nuke_limit 50 [allocations] (default)
> pcre_match_limit   1 (default)
> pcre_match_limit_recursion 20 (default)
> ping_interval  3 [seconds] (default)
> pipe_timeout   60.000 [seconds] (default)
>