From a.hongens at netmatch.nl  Mon Feb  1 09:50:15 2010
From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=)
Date: Mon, 1 Feb 2010 10:50:15 +0100
Subject: varnishhist x-axis?
Message-ID: <4B66A3D7.2000505@netmatch.nl>

Varnishhist looks cool.. It really does.. But what value is shown on the
x-axis? Ths man page shows: "The horizontal scale is logarithmic", but I
have no idea WHAT it graphs. (object size, ttlb,  etc)



1:15, n = 2000                          nmt-nlb-04.netmatchcolo1.local
                 |
                 |
                 |
                 |
                 |
                 |
                 |
               | |
               |||
               |||
               |||
               |||
               |||
               |||     #
               |||     #
               |||     #
               |||     #
               |||     #
               |||     #
               |||     #
               ||||    #
               ||||    #
              |||||| | ##
              |||||| ||##
              ||||||||####       | #
            | ||||||||##### #   |######
+------+------+------+------+------+------+------+------+------
|1e-6  |1e-5  |1e-4  |1e-3  |1e-2  |1e-1  |1e0   |1e1   |1e2


-- 


With kind regards,


Angelo H?ngens
systems administrator

MCSE on Windows 2003
MCSE on Windows 2000
MS Small Business Specialist
------------------------------------------
NetMatch
tourism internet software solutions

Ringbaan Oost 2b
5013 CA Tilburg
+31 (0)13 5811088
+31 (0)13 5821239

A.Hongens at netmatch.nl
www.netmatch.nl
------------------------------------------




From phk at phk.freebsd.dk  Mon Feb  1 08:53:40 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 01 Feb 2010 08:53:40 +0000
Subject: varnishhist x-axis? 
In-Reply-To: Your message of "Mon, 01 Feb 2010 10:50:15 +0100."
	<4B66A3D7.2000505@netmatch.nl> 
Message-ID: <87181.1265014420@critter.freebsd.dk>

In message <4B66A3D7.2000505 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr
ites:

>Varnishhist looks cool.. It really does.. But what value is shown on the
>x-axis? Ths man page shows: "The horizontal scale is logarithmic", but I
>have no idea WHAT it graphs. (object size, ttlb,  etc)

It shows how long time Varnish spent, from it had the full request
from the kernel, until it delivered the response to the kernel.

>[...]
>               |||     #
>               ||||    #
>               ||||    #
>              |||||| | ##
>              |||||| ||##
>              ||||||||####       | #
>            | ||||||||##### #   |######
>+------+------+------+------+------+------+------+------+------
>|1e-6  |1e-5  |1e-4  |1e-3  |1e-2  |1e-1  |1e0   |1e1   |1e2

You got a pretty damn fast backend there...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From plfgoa at gmail.com  Mon Feb  1 09:57:58 2010
From: plfgoa at gmail.com (Paras Fadte)
Date: Mon, 1 Feb 2010 15:27:58 +0530
Subject: Varnish Prefetch
In-Reply-To: <75cf5801001282037j49becab4qabc8cf3ab3cdcdaf@mail.gmail.com>
References: <75cf5801001270025s722f114ax9335dba334a84007@mail.gmail.com>
	<4956.1264717146@critter.freebsd.dk>
	<75cf5801001282037j49becab4qabc8cf3ab3cdcdaf@mail.gmail.com>
Message-ID: <75cf5801002010157ybf03f32v32232555560dca71@mail.gmail.com>

Hi Poul,

Any work around possible in varnish to make varnish check objects at backend
some time before they actually reach their expires time? Or is it just not
possible to do so in varnish?

Thank you.

-Paras


On Fri, Jan 29, 2010 at 10:07 AM, Paras Fadte <plfgoa at gmail.com> wrote:

> Thanks for the response Poul.
>
>
>
> On Fri, Jan 29, 2010 at 3:49 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:
>
>> In message <75cf5801001270025s722f114ax9335dba334a84007 at mail.gmail.com>,
>> Paras
>> Fadte writes:
>>
>> >Thanks for the response . So with grace mode is it possible to fetch an
>> >object from backend about "x" seconds before its "expires" time is
>> reached ?
>>
>>
>> No, sorry.
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk at FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100201/514ab4be/attachment.html>

From a.hongens at netmatch.nl  Mon Feb  1 10:12:38 2010
From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=)
Date: Mon, 1 Feb 2010 11:12:38 +0100
Subject: varnishhist x-axis?
In-Reply-To: <87181.1265014420@critter.freebsd.dk>
References: <87181.1265014420@critter.freebsd.dk>
Message-ID: <4B66A916.4000104@netmatch.nl>

On 1-2-2010 9:53, Poul-Henning Kamp wrote:
> In message <4B66A3D7.2000505 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr
> ites:
> 
>> Varnishhist looks cool.. It really does.. But what value is shown on the
>> x-axis? Ths man page shows: "The horizontal scale is logarithmic", but I
>> have no idea WHAT it graphs. (object size, ttlb,  etc)
> 
> It shows how long time Varnish spent, from it had the full request
> from the kernel, until it delivered the response to the kernel.


So for my understanding (oversimplified): This is the number of seconds
it takes Varnish to 'get the result', either from the backend or from
it's cache?


> You got a pretty damn fast backend there...

The backends are IIS machines (dual Xeon X5570 with 32GB RAM) running
ASP.NET web applications, which also serve a lot of content from
memory.. They can be quite fast at times ;)


-- 


With kind regards,


Angelo H?ngens
systems administrator

MCSE on Windows 2003
MCSE on Windows 2000
MS Small Business Specialist
------------------------------------------
NetMatch
tourism internet software solutions

Ringbaan Oost 2b
5013 CA Tilburg
+31 (0)13 5811088
+31 (0)13 5821239

A.Hongens at netmatch.nl
www.netmatch.nl
------------------------------------------




From phk at phk.freebsd.dk  Mon Feb  1 09:13:59 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 01 Feb 2010 09:13:59 +0000
Subject: varnishhist x-axis? 
In-Reply-To: Your message of "Mon, 01 Feb 2010 11:12:38 +0100."
	<4B66A916.4000104@netmatch.nl> 
Message-ID: <87322.1265015639@critter.freebsd.dk>

In message <4B66A916.4000104 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr
ites:

>So for my understanding (oversimplified): This is the number of seconds
>it takes Varnish to 'get the result', either from the backend or from
>it's cache?

Yes.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Mon Feb  1 09:18:37 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 01 Feb 2010 09:18:37 +0000
Subject: Varnish Prefetch 
In-Reply-To: Your message of "Mon, 01 Feb 2010 15:27:58 +0530."
	<75cf5801002010157ybf03f32v32232555560dca71@mail.gmail.com> 
Message-ID: <87365.1265015917@critter.freebsd.dk>

In message <75cf5801002010157ybf03f32v32232555560dca71 at mail.gmail.com>, Paras F
adte writes:

>Any work around possible in varnish to make varnish check objects at backend
>some time before they actually reach their expires time? Or is it just not
>possible to do so in varnish?

We have a facility called 'grace' that does pretty much the same thing,
just slightly different.

Good explanation here:

	http://overstimulate.com/articles/varnish-getting-started

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From lstroobant at gmail.com  Mon Feb  1 20:42:58 2010
From: lstroobant at gmail.com (Luc Stroobant)
Date: Mon, 01 Feb 2010 21:42:58 +0100
Subject: obj.cacheable vs expires headers?
Message-ID: <4B673CD2.7070807@gmail.com>

Hello list,

I have a vcl-config with a snippet like the one on:
http://varnish-cache.org/wiki/VCLExampleLongerCaching

sub vcl_fetch {
     if (obj.cacheable) {
       unset obj.http.expires;
       set obj.http.cache-control = "max-age = 900";
       set obj.ttl = 2w;
       set obj.http.magicmarker = "1";
     }
}

sub vcl_deliver {
     if (resp.http.magicmarker) {
       /* unset marker and serve it for upstream as new */
       unset resp.http.magicmarker;
       set resp.http.age = "0";
     }
}

We used that in an attempt to override the expires headers from static 
files for a site and keep them in Varnish cache. We don't want to cache 
an dynamic (PHP) page.

At first sight, everything went fine. But once the load rised a bit, we 
noticed that dynamic pages are sometimes cached.
I've been checking the headers and it looks like the expires header for 
dynamic pages is also removed. I don't think the headers from the 
(first) request below should be considerd obj.cacheable  according to 
the definition on http://varnish-cache.org/wiki/VCL
Or did I miss something? Is this a mistake in my config or a possible 
Varnish issue?

Test without the vcl snippet.
PHP page: unmodified headers and not cached, as expected:

HTTP/1.1 200 OK
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.12
Set-Cookie: SESSbc5f9ce1c97eee1824d1ab6sdfsdfssf70k2hqq7mgo6; 
expires=Wed, 24-Feb-2010 22:58:21 GMT; path=/; domain=removed
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Mon, 01 Feb 2010 19:25:01 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Content-Type: text/html; charset=utf-8
Content-Length: 56194
Date: Mon, 01 Feb 2010 19:25:02 GMT
X-Varnish: 963899298
Age: 0
Via: 1.1 varnish
Connection: close


With the config:
PHP page, Expires header removed and cache-control is set

HTTP/1.1 200 OK
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.12
Set-Cookie: SESSbc5f9ce1c97eee1824d1ab670ce3057b=91dpgvghvkmonso1; 
expires=Wed, 24-Feb-2010 23:21:04 GMT; path=/; domain=removed
Last-Modified: Mon, 01 Feb 2010 19:47:44 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 59418
cache-control: max-age = 900
Date: Mon, 01 Feb 2010 19:47:48 GMT
X-Varnish: 1790685114
Via: 1.1 varnish
Connection: close
age: 0

I used the same VCL-code in vcl_fetch for both examples and for static 
files, everything works as expected. Any ideas?
(Running on Varnish 2.0.6)

Luc

sub vcl_recv {

     # Add a unique header containing the client address
     remove req.http.X-Forwarded-For;
     set    req.http.X-Forwarded-For = client.ip;

     /* Don't cache accept */
     if (req.http.host ~ "^some.host$") {
       return (pass);
     }

     if (req.url ~ "\.(css|js|jpg|jpeg|gif|ico|png)$") {
     	unset req.http.cookie;
     	lookup;
     }

    /* Never cache php files... */
    if (req.url ~ ".*\.php") {
      return (pass);
    }

    /* ... or Apache server status */
    if (req.url ~ ".*/server-status$") {
      return (pass);
    }
}


From pablort+varnish at gmail.com  Mon Feb  1 21:38:42 2010
From: pablort+varnish at gmail.com (pablort)
Date: Mon, 1 Feb 2010 19:38:42 -0200
Subject: Varnish graphs
In-Reply-To: <87ockd43od.fsf@qurzaw.linpro.no>
References: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com> 
	<87ockd43od.fsf@qurzaw.linpro.no>
Message-ID: <7ae911871002011338j6a437228p333ba11469bf87b3@mail.gmail.com>

Nah. using 2.0.6

# varnishtop -V
varnishtop (varnish-2.0.6)
Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS
# varnishtop -1 -i TxStatus
 23917.00 TxStatus
  2611.00 TxStatus
  1183.00 TxStatus
   751.00 TxStatus
    45.00 TxStatus

On Fri, Jan 29, 2010 at 8:16 AM, Tollef Fog Heen
<tfheen at redpill-linpro.com>wrote:

> ]] pablort
>
> | The numbers do reflect the TxStatus'es that I see in interactive
> varnishtop,
> | but when I try to run it with -1, it doesn't show which entry corresponds
> to
> | which status. LOL.
>
> You're running an old version, this was fixed in 2.0.5 so upgrading
> should fix that.
>
> --
> Tollef Fog Heen
> Redpill Linpro -- Changing the game!
> t: +47 21 54 41 73
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100201/e7bf05dd/attachment.html>

From antonivillalonga at dorna.com  Mon Feb  1 23:37:03 2010
From: antonivillalonga at dorna.com (Antoni Villalonga)
Date: Tue, 2 Feb 2010 00:37:03 +0100
Subject: obj.cacheable vs expires headers?
In-Reply-To: <4B673CD2.7070807@gmail.com>
References: <4B673CD2.7070807@gmail.com>
Message-ID: <20100201233703.GA29694@motogp.com>

Hi!

It's seems to be correct. Be careful with cacheable and ttl=0 answers.

Some simple debuging:
sub vcl_fetch {
	# Varnish determined the object was not cacheable
	if (!obj.cacheable) {
		set obj.http.X-Cacheable = "No";
	} elsif (obj.ttl > 0s) {
		set obj.http.X-Cacheable = "Yes";
	} else {
		set obj.http.X-Cacheable = "Yes: ttl=0";
	}
	[...]
}

Good luck!

On dl, feb 01, 2010 at 09:42:58 +0100, Luc Stroobant wrote:
> Hello list,
> 
> I have a vcl-config with a snippet like the one on:
> http://varnish-cache.org/wiki/VCLExampleLongerCaching
> 
> sub vcl_fetch {
>      if (obj.cacheable) {
>        unset obj.http.expires;
>        set obj.http.cache-control = "max-age = 900";
>        set obj.ttl = 2w;
>        set obj.http.magicmarker = "1";
>      }
> }
> 
> sub vcl_deliver {
>      if (resp.http.magicmarker) {
>        /* unset marker and serve it for upstream as new */
>        unset resp.http.magicmarker;
>        set resp.http.age = "0";
>      }
> }
> 
> We used that in an attempt to override the expires headers from static 
> files for a site and keep them in Varnish cache. We don't want to cache 
> an dynamic (PHP) page.
> 
> At first sight, everything went fine. But once the load rised a bit, we 
> noticed that dynamic pages are sometimes cached.
> I've been checking the headers and it looks like the expires header for 
> dynamic pages is also removed. I don't think the headers from the 
> (first) request below should be considerd obj.cacheable  according to 
> the definition on http://varnish-cache.org/wiki/VCL
> Or did I miss something? Is this a mistake in my config or a possible 
> Varnish issue?
> 
> Test without the vcl snippet.
> PHP page: unmodified headers and not cached, as expected:
> 
> HTTP/1.1 200 OK
> Server: Apache/2.2.3 (CentOS)
> X-Powered-By: PHP/5.2.12
> Set-Cookie: SESSbc5f9ce1c97eee1824d1ab6sdfsdfssf70k2hqq7mgo6; 
> expires=Wed, 24-Feb-2010 22:58:21 GMT; path=/; domain=removed
> Expires: Sun, 19 Nov 1978 05:00:00 GMT
> Last-Modified: Mon, 01 Feb 2010 19:25:01 GMT
> Cache-Control: store, no-cache, must-revalidate
> Cache-Control: post-check=0, pre-check=0
> Content-Type: text/html; charset=utf-8
> Content-Length: 56194
> Date: Mon, 01 Feb 2010 19:25:02 GMT
> X-Varnish: 963899298
> Age: 0
> Via: 1.1 varnish
> Connection: close
> 
> 
> With the config:
> PHP page, Expires header removed and cache-control is set
> 
> HTTP/1.1 200 OK
> Server: Apache/2.2.3 (CentOS)
> X-Powered-By: PHP/5.2.12
> Set-Cookie: SESSbc5f9ce1c97eee1824d1ab670ce3057b=91dpgvghvkmonso1; 
> expires=Wed, 24-Feb-2010 23:21:04 GMT; path=/; domain=removed
> Last-Modified: Mon, 01 Feb 2010 19:47:44 GMT
> Content-Type: text/html; charset=utf-8
> Content-Length: 59418
> cache-control: max-age = 900
> Date: Mon, 01 Feb 2010 19:47:48 GMT
> X-Varnish: 1790685114
> Via: 1.1 varnish
> Connection: close
> age: 0
> 
> I used the same VCL-code in vcl_fetch for both examples and for static 
> files, everything works as expected. Any ideas?
> (Running on Varnish 2.0.6)
> 
> Luc
> 
> sub vcl_recv {
> 
>      # Add a unique header containing the client address
>      remove req.http.X-Forwarded-For;
>      set    req.http.X-Forwarded-For = client.ip;
> 
>      /* Don't cache accept */
>      if (req.http.host ~ "^some.host$") {
>        return (pass);
>      }
> 
>      if (req.url ~ "\.(css|js|jpg|jpeg|gif|ico|png)$") {
>      	unset req.http.cookie;
>      	lookup;
>      }
> 
>     /* Never cache php files... */
>     if (req.url ~ ".*\.php") {
>       return (pass);
>     }
> 
>     /* ... or Apache server status */
>     if (req.url ~ ".*/server-status$") {
>       return (pass);
>     }
> }
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc

-- 
Antoni Villalonga i Noceras / root / New Technologies / Dorna Sports S.L.
Tel. +34 934 702 885  / Fax. +34 934 737 779
Narc?s Monturiol 2, 08960, Sant Just Desvern - Spain
http://www.motogp.com
http://www.dorna.com

***************************** DISCLAIMER *****************************
This message is intended exclusively for the named person. It may
contain confidential, propietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it an
notify the sender. Your must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

Please note that internet e-mail neither guarantees the
confidentiality nor the proper receipt of the message sent. If the
addressee of this message does not consent to the use of internet
e-mail, please communicate it to us immediately.

**************************** AVISO LEGAL *****************************

Este mensaje es solamente para la persona a la que va dirigido. Puede
contener informaci?n confidencial o legalmente protegida. No hay
renuncia a la confidencialidad o privilegio por cualquier transmisi?n
mala/err?nea. Si usted ha recibido este mensaje por error, le rogamos
que borre de su sistema inmediatamente el mensaje asi como todas sus
copias, destruya todas las copias del mismo de su disco duro y
notifique al remitente. No debe, directa o indirectamente, usar,
revelar, distribuir, imprimir o copiar ninguna de las partes de este
mensaje si no es usted el destinatario.

N?tese que el correo electr?nico via Internet no permite asegurar ni
la confidencialidad de los mensajes que se transmiten ni la correcta
recepci?n de los mismos. En el caso de que el destinatario de este
mensaje no consintiera la utilizaci?n del correo electr?nico via
Internet, rogamos lo ponga en nuestro conocimiento de manera
inmediata.

**********************************************************************


From martin.boer at netclever.nl  Tue Feb  2 09:22:38 2010
From: martin.boer at netclever.nl (Martin Boer)
Date: Tue, 02 Feb 2010 10:22:38 +0100
Subject: Survey; how do you use Varnish?
In-Reply-To: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
References: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
Message-ID: <4B67EEDE.90001@netclever.nl>

1) One active server. We have another one as hot standby.

2) 50Mbit, 200 requests/second max. Most of the time it's 10Mbit, 40 
requests/second which isn't much.

3) Internet touroperator.

4) Nope

5) Automatic refreshing of data without having the endusers have to wait 
for the response.

The reason we use varnish most is because our website has complex, 
timeconsuming queries to backend systems. The answers to these queries 
do vary several times per day but are still cachable. Of course varnish 
also helps te bring down the load on those backend systems but the main 
use is that varnish gives the endusers a lightning fast prerendered 
interactive experience which is a paradox. We like working paradoxes.

Something like 'refresh pages after object.prefetch seconds if at least 
someone requested that object the last object.ttl seconds' where 
object.ttl is larger then object.refresh. So an object might be 
prefetched even a couple of times without anyone being interested but 
will be removed from the cache eventually after object.ttl has expired.

Regards,
Martin Boer



Per Andreas Buer wrote:
> Hi list.
>
> I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks.
>
> 1) How many servers do you have running Varnish?
>
> 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics.
>
> 3) What sort of site is it?
>  *) Online media
>  *) Cooperate website (ibm.com or similar)
>  *) Retail
>  *) Educational
>  *) Social website
>
> 4) Do you use ESI?
>
> 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features. 
>
>
>
>   



From r at roze.lv  Tue Feb  2 13:02:49 2010
From: r at roze.lv (Reinis Rozitis)
Date: Tue, 2 Feb 2010 15:02:49 +0200
Subject: Survey; how do you use Varnish?
References: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
Message-ID: <DAD40F6D976249ADA85FEA18DB5C3521@KD5>

1) 15
2) Arround 10k/s  results in 500-600Mbit.
3) Social Network website
4) No
5) Large dataset performance improvements, High traffic performance improvements


rr


From samcrawford at gmail.com  Tue Feb  2 13:27:58 2010
From: samcrawford at gmail.com (Sam Crawford)
Date: Tue, 2 Feb 2010 13:27:58 +0000
Subject: Survey; how do you use Varnish?
In-Reply-To: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
References: <1972754207.83637.1264776184796.JavaMail.root@claudius.linpro.no>
	<630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
Message-ID: <e4bd33301002020527g69afb196sa788427aeada5ce9@mail.gmail.com>

1) ~20 (Mixture of production and development environments, spread
across London, Tokyo and New York)

2) Low figures - 300-500 hits/s at peak. A lot of our backends have
very high latency though (~200ms just to connect to the server), and
are predominantly static content, so caching speeds up application
loading considerably.

3) Global corporate intranet (Finance sector)

4) No, but we have looked at it. The lack of user/entitlements
awareness put us off it, and we moved the logic to another layer.

5) #1 - GZIP compression
    #2 - SSL support (I know, I know...) - both for accepting incoming
connections, and for outgoing connections to backends

Thanks,

Sam


On 29 January 2010 14:48, Per Andreas Buer <per.buer at redpill-linpro.com> wrote:
> Hi list.
>
> I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks.
>
> 1) How many servers do you have running Varnish?
>
> 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics.
>
> 3) What sort of site is it?
> ?*) Online media
> ?*) Cooperate website (ibm.com or similar)
> ?*) Retail
> ?*) Educational
> ?*) Social website
>
> 4) Do you use ESI?
>
> 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features.
>
>
>
> --
> Per Andreas Buer
> Redpill Linpro Group - Changing the Game
>
> Mobile +47 958 39 117 / Phone: +47 21 54 41 21
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From phk at phk.freebsd.dk  Tue Feb  2 12:34:53 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 02 Feb 2010 12:34:53 +0000
Subject: Memory usage 
In-Reply-To: Your message of "Tue, 26 Jan 2010 22:23:57 EST."
	<24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> 
Message-ID: <4701.1265114093@critter.freebsd.dk>

In message <24a219a51001261923n40146083yb221aac2cadbcff8 at mail.gmail.com>, Marti
n Goldman writes:

>1. How can you tell whether your Varnish objects fit in RAM?

If you start seeing disk-activity, they do not fit.

>2. If I have objects residing in virtual memory, to what extent will my
>performance be adversely affected? If I want my site to be fast, do I
>basically need to go out and buy as much RAM as it will take so that virtual
>memory isn't needed?

Well, the impact is the necessary disk-I/O to bring the object into
RAM.

Getting more RAM is one solution, but if your working set is much
larger than 4G, getting a SSD disk instead might be a better investment.

>3. I noticed tonight that my machine was using a few hundred megs of swap
>space,

Yes, varnish will force inactive programs (inetd, getty, sendmail etc)
out to swap so it can get at the RAM.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From v.bilek at 1art.cz  Tue Feb  2 13:48:17 2010
From: v.bilek at 1art.cz (=?ISO-8859-1?Q?V=E1clav_B=EDlek?=)
Date: Tue, 02 Feb 2010 14:48:17 +0100
Subject: Survey; how do you use Varnish?
In-Reply-To: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
References: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
Message-ID: <4B682D21.2000807@1art.cz>

1)8
2)600-800Mbit/s 60Kreq/s ( there is still big margin on that 8 servers)
3)sport realtime results
4)no
5)gracefull restart( not in meaning of persistent cache, but in the
meaning of not flushing all clients and letting them wait for tens of
seconds till enough threads appear.)

Per Andreas Buer napsal(a):
> Hi list.
> 
> I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks.
> 
> 1) How many servers do you have running Varnish?
> 
> 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics.
> 
> 3) What sort of site is it?
>  *) Online media
>  *) Cooperate website (ibm.com or similar)
>  *) Retail
>  *) Educational
>  *) Social website
> 
> 4) Do you use ESI?
> 
> 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features. 
> 
> 
> 



From bernard at frit.net  Tue Feb  2 15:44:48 2010
From: bernard at frit.net (Bernardf FRIT)
Date: Tue, 02 Feb 2010 16:44:48 +0100
Subject: GRSEC and Varnish
Message-ID: <4B684870.9070503@frit.net>

Hi,

I'am running :
- varnishd (varnish-2.0.4)
- linux kernel 2.6.27.10-grsec-xxxx-grs-ipv4-64

and it appears that the grsec Kernel repeatedly and unexpectedly sends 
signal 11 to the varnishd child.

.../...
Feb  2 12:01:02 XXXXXX varnishd[17111]: segfault at 1000 ip 
000000000043abf0 sp 0000000047d89ae0 error 4 in varnishd[400000+50000]
Feb  2 12:01:02 XXXXXX grsec: From 82.67.39.69: signal 11 sent to 
/usr/sbin/varnishd[varnishd:17111] uid/euid:65534/65534 
gid/egid:65534/65534, parent
 /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0
Feb  2 13:45:44 XXXXXX varnishd[22187]: segfault at f5000 ip 
000000000043abf0 sp 0000000048538ae0 error 4 in varnishd[400000+50000]
Feb  2 13:45:44 XXXXXX grsec: From 80.13.19.228: signal 11 sent to 
/usr/sbin/varnishd[varnishd:22187] uid/euid:65534/65534 
gid/egid:65534/65534, paren
t /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0
Feb  2 13:54:57 XXXXXX varnishd[22236]: segfault at 1000 ip 
000000000043abf0 sp 0000000045445ae0 error 4 in varnishd[400000+50000]
Feb  2 13:54:57 XXXXXX grsec: From 80.13.19.228: signal 11 sent to 
/usr/sbin/varnishd[varnishd:22236] uid/euid:65534/65534 
gid/egid:65534/65534, paren
t /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0
Feb  2 14:13:41 XXXXXX varnishd[22595]: segfault at ae000 ip 
000000000043abf0 sp 0000000040ff4ae0 error 4 in varnishd[400000+50000]
Feb  2 14:13:41 XXXXXX grsec: From 83.145.80.130: signal 11 sent to 
/usr/sbin/varnishd[varnishd:22595] uid/euid:65534/65534 
gid/egid:65534/65534, pare
nt /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0
Feb  2 14:31:08 XXXXXX varnishd[23547]: segfault at 1000 ip 
000000000043abf0 sp 0000000045b40ae0 error 4 in varnishd[400000+50000]
Feb  2 14:31:08 XXXXXX grsec: From 81.49.118.48: signal 11 sent to 
/usr/sbin/varnishd[varnishd:23547] uid/euid:65534/65534 
gid/egid:65534/65534, paren
t /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0
Feb  2 16:19:05 XXXXXX varnishd[24256]: segfault at f7000 ip 
000000000043abf0 sp 00000000473bcae0 error 4 in varnishd[400000+50000]
Feb  2 16:19:05 XXXXXX grsec: From 192.196.142.20: signal 11 sent to 
/usr/sbin/varnishd[varnishd:24256] uid/euid:65534/65534 
gid/egid:65534/65534, par
ent /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0

Then the parent varnishd process starts immediately a new child process 
which lasts some time.

Is there any way to fix this. Remocve the GRSEC kernel ? Upgrade the 
kernel ? Varnish ? or whatever ?

Thanks in advance.
--
Bernard FRIT





From pubcrawler.com at gmail.com  Tue Feb  2 21:37:17 2010
From: pubcrawler.com at gmail.com (pub crawler)
Date: Tue, 2 Feb 2010 16:37:17 -0500
Subject: Varnish caching 503 error pages
Message-ID: <4c3149fb1002021337q7c8bc8cdx59d74f908a5ce357@mail.gmail.com>

Thought I'd ask the list before I went on a voyage with this one.

Sometime our backend app servers gets overloaded and go into
protection mode whereby they sends out 503 errors until they recover.

Varnish is in front of the app servers and when this happens the 503
ends up as a cached item in Varnish.

Here's output to show such:

HTTP/1.1 503 Service Unavailable
Keep-Alive: timeout=30
Content-Type: text/html
Content-Language: en-US
Content-Length: 122
Date: Tue, 02 Feb 2010 21:34:15 GMT
X-Varnish: 655791101 655790499
Age: 97
Via: 1.1 varnish
Connection: keep-alive
X-Served-By: atom3302
X-Cache: HIT
X-Cache-Hits: 13

What is the best way to explicitly refuse caching of 503 errors by Varnish?

Thanks!


From kb+varnish at slide.com  Tue Feb  2 21:52:54 2010
From: kb+varnish at slide.com (Ken Brownfield)
Date: Tue, 2 Feb 2010 13:52:54 -0800
Subject: Varnish caching 503 error pages
In-Reply-To: <4c3149fb1002021337q7c8bc8cdx59d74f908a5ce357@mail.gmail.com>
References: <4c3149fb1002021337q7c8bc8cdx59d74f908a5ce357@mail.gmail.com>
Message-ID: <0D3F3478-3128-4C01-871D-18125D0A7374@slide.com>

If your default_ttl is not 0, then this may be the expected behavior.  I'm not sure if Varnish should really ever cache >=500 responses?

But in VCL you could do something like:

sub vcl_fetch {
	if ( obj.status >= 500 ) {
		set obj.ttl = 0s;
		set obj.cacheable = false;
	}
}

Adjusting timeouts for ttl for 404s is also handy.  Hope it helps,
-- 
Ken

On Feb 2, 2010, at 1:37 PM, pub crawler wrote:

> Thought I'd ask the list before I went on a voyage with this one.
> 
> Sometime our backend app servers gets overloaded and go into
> protection mode whereby they sends out 503 errors until they recover.
> 
> Varnish is in front of the app servers and when this happens the 503
> ends up as a cached item in Varnish.
> 
> Here's output to show such:
> 
> HTTP/1.1 503 Service Unavailable
> Keep-Alive: timeout=30
> Content-Type: text/html
> Content-Language: en-US
> Content-Length: 122
> Date: Tue, 02 Feb 2010 21:34:15 GMT
> X-Varnish: 655791101 655790499
> Age: 97
> Via: 1.1 varnish
> Connection: keep-alive
> X-Served-By: atom3302
> X-Cache: HIT
> X-Cache-Hits: 13
> 
> What is the best way to explicitly refuse caching of 503 errors by Varnish?
> 
> Thanks!
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc



From bayron.guevara at gmail.com  Tue Feb  2 22:25:14 2010
From: bayron.guevara at gmail.com (Bayron Guevara)
Date: Tue, 2 Feb 2010 16:25:14 -0600
Subject: Fwd: Varnish caching 503 error pages
In-Reply-To: <0D3F3478-3128-4C01-871D-18125D0A7374@slide.com>
References: <4c3149fb1002021337q7c8bc8cdx59d74f908a5ce357@mail.gmail.com>
	<0D3F3478-3128-4C01-871D-18125D0A7374@slide.com>
Message-ID: <f3bcf9cb1002021425u57ed57d5q669e8f53a60c7d08@mail.gmail.com>

You can use the obj.cacheable property, which is a suggestion from Varnish
about the response should be cacheable. By default Error response codes
aren't cached, so test the following:

sub vcl_fetch {
if (!obj.cacheable){
return (pass);
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100202/efe1eaa1/attachment.html>

From ross at trademe.co.nz  Wed Feb  3 03:47:47 2010
From: ross at trademe.co.nz (Ross Brown)
Date: Wed, 3 Feb 2010 16:47:47 +1300
Subject: Survey; how do you use Varnish?
In-Reply-To: <4B67EEDE.90001@netclever.nl>
References: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
	<4B67EEDE.90001@netclever.nl>
Message-ID: <1FF67D7369ED1A45832180C7C1109BCA13F74B856E@tmmail0.trademe.local>

1) How many servers do you have running Varnish?

8 servers (2 sites x 4 servers), load balanced behind F5 GTM. We aim to be able to lose a site AND suffer a hardware failure and keep on truckin'. We could probably run on one or two servers at a push, but our backend would most likely explode before Varnish broke a sweat.
Each server is a quad core Xeon w/ 16G RAM. We have a fairly large working set.

(+1 Varnish server for Dev / test, which is a VM)

2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics.

~900 req/sec at peak per Prod server / 60Mbps

3) What sort of site is it?
  *) Retail <= online auctions

4) Do you use ESI?
No.

5) What features are you missing from Varnish. 
Varnishlog filtering language (or other enhancements in this area)
Dynamic stats counters
Large dataset performance improvements


-----Original Message-----
From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of Martin Boer
Sent: Tuesday, 2 February 2010 10:23 p.m.
To: Per Andreas Buer
Cc: varnish-misc at projects.linpro.no
Subject: Re: Survey; how do you use Varnish?

1) One active server. We have another one as hot standby.

2) 50Mbit, 200 requests/second max. Most of the time it's 10Mbit, 40 
requests/second which isn't much.

3) Internet touroperator.

4) Nope

5) Automatic refreshing of data without having the endusers have to wait 
for the response.

The reason we use varnish most is because our website has complex, 
timeconsuming queries to backend systems. The answers to these queries 
do vary several times per day but are still cachable. Of course varnish 
also helps te bring down the load on those backend systems but the main 
use is that varnish gives the endusers a lightning fast prerendered 
interactive experience which is a paradox. We like working paradoxes.

Something like 'refresh pages after object.prefetch seconds if at least 
someone requested that object the last object.ttl seconds' where 
object.ttl is larger then object.refresh. So an object might be 
prefetched even a couple of times without anyone being interested but 
will be removed from the cache eventually after object.ttl has expired.

Regards,
Martin Boer



Per Andreas Buer wrote:
> Hi list.
>
> I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks.
>
> 1) How many servers do you have running Varnish?
>
> 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics.
>
> 3) What sort of site is it?
>  *) Online media
>  *) Cooperate website (ibm.com or similar)
>  *) Retail
>  *) Educational
>  *) Social website
>
> 4) Do you use ESI?
>
> 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features. 
>
>
>
>   

_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


From tfheen at varnish-software.com  Wed Feb  3 07:48:52 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Wed, 03 Feb 2010 08:48:52 +0100
Subject: Survey; how do you use Varnish?
In-Reply-To: <4B682D21.2000807@1art.cz> (=?utf-8?Q?=22V=C3=A1clav_B=C3=ADl?=
	=?utf-8?Q?ek=22's?= message of "Tue, 02 Feb 2010 14:48:17 +0100")
References: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
	<4B682D21.2000807@1art.cz>
Message-ID: <878wbalpy3.fsf@qurzaw.linpro.no>

]] V?clav B?lek 

| 5)gracefull restart( not in meaning of persistent cache, but in the
| meaning of not flushing all clients and letting them wait for tens of
| seconds till enough threads appear.)

You can tune the thread_pool_add_delay parameter to at least bring the
time down somewhat.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From tfheen at varnish-software.com  Wed Feb  3 07:53:45 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Wed, 03 Feb 2010 08:53:45 +0100
Subject: GRSEC and Varnish
In-Reply-To: <4B684870.9070503@frit.net> (Bernardf FRIT's message of "Tue, 02
	Feb 2010 16:44:48 +0100")
References: <4B684870.9070503@frit.net>
Message-ID: <874olylppy.fsf@qurzaw.linpro.no>

]] Bernardf FRIT 

| Then the parent varnishd process starts immediately a new child process 
| which lasts some time.
| 
| Is there any way to fix this. Remocve the GRSEC kernel ? Upgrade the 
| kernel ? Varnish ? or whatever ?

Work out why it thinks that varnishd is doing something wrong?  It
doesn't seem to say so in the log.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From v.bilek at 1art.cz  Wed Feb  3 07:58:09 2010
From: v.bilek at 1art.cz (=?UTF-8?B?VsOhY2xhdiBCw61sZWs=?=)
Date: Wed, 03 Feb 2010 08:58:09 +0100
Subject: Survey; how do you use Varnish?
In-Reply-To: <878wbalpy3.fsf@qurzaw.linpro.no>
References: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>	<4B682D21.2000807@1art.cz>
	<878wbalpy3.fsf@qurzaw.linpro.no>
Message-ID: <4B692C91.60302@1art.cz>



Tollef Fog Heen napsal(a):
> ]] V?clav B?lek 
> 
> | 5)gracefull restart( not in meaning of persistent cache, but in the
> | meaning of not flushing all clients and letting them wait for tens of
> | seconds till enough threads appear.)
> 
> You can tune the thread_pool_add_delay parameter to at least bring the
> time down somewhat.
> 

alredy set to "1" bud for 4000 threads it takes around 20seconds till
fully working state



From tfheen at varnish-software.com  Wed Feb  3 08:41:16 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Wed, 03 Feb 2010 09:41:16 +0100
Subject: Varnish graphs
In-Reply-To: <7ae911871002011338j6a437228p333ba11469bf87b3@mail.gmail.com>
	(pablort's message of "Mon, 1 Feb 2010 19:38:42 -0200")
References: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com>
	<87ockd43od.fsf@qurzaw.linpro.no>
	<7ae911871002011338j6a437228p333ba11469bf87b3@mail.gmail.com>
Message-ID: <87zl3qk8yb.fsf@qurzaw.linpro.no>

]] pablort 

| Nah. using 2.0.6

Hmm, indeed.

I just fixed it in trunk, will backport it to 2.0 branch.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From ahooper at bmjgroup.com  Wed Feb  3 11:41:14 2010
From: ahooper at bmjgroup.com (Alex Hooper)
Date: Wed, 3 Feb 2010 11:41:14 +0000
Subject: varnishlog not behaving as expected (by  me)
In-Reply-To: <4B4DAD57.2050609@bmjgroup.com>
References: <4B4DAD57.2050609@bmjgroup.com>
Message-ID: <4B6960DA.6080300@bmjgroup.com>

Hi,

It's OK: I'm used to not receiving responses from mailing lists. I have
an unfortunate way of communicating in such forums, I think.

Anyway, having come back to this after a slight hiatus I have noted that
the inclusion of the '-c' flag makes it work as expected.

If I instead include the '-b' flag, it also seems to work as expected
(ie, it doesn't spew output, returns data on backend requests where
tag/regex matched). If I include both -b and -c, it continues to work --
but if I include neither, I get the type of spurious* output I noted
originally, no matter what the combination of tag and regex.

My reading of the man page is that

  varnishlog -o <tag> <regex>

is semantically equivalent to

  varnishlog -b -c -o <tag> <regex>


Either I or the code or the man page would appear to be wrong.

Cheers,

Alex.

* The use of this term may be subjective.


Alex Hooper uttered:
> Hi,
> 
> I'm having a bit of trouble using varnishlog. I am using:
> 
>   /usr/local/bin/varnishlog -o RxURL "^wp-admin$"
> 
> Expecting to see grouped log lines for requests where the RxURL matches
> /^wp-admin$. But the (copious) output I see is like:
> 
>     0 StatAddr     - 59.181.130.123 0 6 1 3 0 0 0 1003 8711
>     0 StatAddr     - 120.28.216.236 0 1 6 11 0 0 0 3864 92763
>     0 StatAddr     - 80.13.50.156 0 754 22 40 0 0 0 7080 0
>     0 StatAddr     - 86.156.98.226 0 0 2 4 0 0 0 1397 9259
>     0 ExpPick      - 1023444941 ttl
>     0 VCL_call     - timeout
>     0 VCL_return   - discard
>     0 ExpKill      - 1023444941 -1263381538
>     0 ExpPick      - 1023444953 ttl
>     0 VCL_call     - timeout
>     0 VCL_return   - discard
>     0 ExpKill      - 1023444953 -1263381538
>     0 ExpPick      - 1023108126 ttl
>     0 VCL_call     - timeout
>     0 VCL_return   - discard
>     0 ExpKill      - 1023108126 -10
>     0 ExpPick      - 1023109753 prefetch
>     0 VCL_call     - prefetch
>     0 VCL_return   - fetch
>     0 Debug        - "Attempt Prefetch 1023109753"
>     0 StatAddr     - 86.156.98.226 0 0 3 5 0 0 0 1750 22988
>     0 StatAddr     - 193.146.115.134 0 12 4 4 0 0 0 708 0
>     0 StatAddr     - 86.156.98.226 0 0 4 6 0 0 0 2103 36115
>     0 StatAddr     - 80.13.50.156 0 754 22 41 0 0 0 7257 0
>     0 StatAddr     - 80.13.50.156 0 754 23 42 0 0 0 7434 0
> 
> 
> '/usr/local/bin/varnishlog' -i RxURL  shows me the requests coming in.
> '/usr/local/bin/varnishlog -i RxURL|grep wp-admin' shows that there are
> generally no requests for wp-admin.
> 
> Am I missing something obvious?
> 
> (varnish-2.0.4 on RHEL 5.4)
> 
> Cheers,
> 
> Alex.


-- 
Alex Hooper                           |  <w> www.bmjpg.com
Operations Team Leader                |  <e> ahooper at bmjgroup.com
BMJ Technology, BMJ Publishing Group  |  <t> +44 20 7383 6049
BMA House, LONDON, WC1H 9JR           |


_______________________________________________________________________
The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com.  This email and any attachments are confidential.  If you have received this email in error, please delete it and kindly notify us.  If the email contains personal views then the BMJ Group accepts no responsibility for these statements.  The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses.  Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content.  BMJ Publishing Group Limited trading as BMJ Group.  A private limited company, registered in England and Wales under registration number 03102371.  Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK.
_______________________________________________________________________


From phk at phk.freebsd.dk  Wed Feb  3 11:57:25 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 03 Feb 2010 11:57:25 +0000
Subject: varnishlog not behaving as expected (by me) 
In-Reply-To: Your message of "Wed, 03 Feb 2010 11:41:14 GMT."
	<4B6960DA.6080300@bmjgroup.com> 
Message-ID: <81569.1265198245@critter.freebsd.dk>

In message <4B6960DA.6080300 at bmjgroup.com>, Alex Hooper writes:

>>   /usr/local/bin/varnishlog -o RxURL "^wp-admin$"

This says you want to *O*mit all RxURL lines.  The regexp argument
should have generated an argument error.

What you want is probably:

	varnishlog -i RxURL -I "^wp-admin$"

Ie: Include (only) RxURL lines, which match this regexp.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From richard.chiswell at mangahigh.com  Wed Feb  3 16:58:02 2010
From: richard.chiswell at mangahigh.com (Richard Chiswell)
Date: Wed, 03 Feb 2010 16:58:02 +0000
Subject: Upper and lower case strings in Varnish
Message-ID: <4B69AB1A.6010406@mangahigh.com>

Hi all,

I've got a simple question which I've been puzzling on for the last 30 
minutes or so - how do you change a string in Varnish to lowercase?

Basically, all the links on our site should be lowercase, but some 
people have been randomly capitalising them when linking to them - I'd 
just like Varnish to issue a 301 redirect to the lowercased version of 
the URL: everything is in place apart from converting the string to 
lowercase.

Any advice welcome!

Thanks,
Richard


From phk at phk.freebsd.dk  Wed Feb  3 15:59:57 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 03 Feb 2010 15:59:57 +0000
Subject: Upper and lower case strings in Varnish 
In-Reply-To: Your message of "Wed, 03 Feb 2010 16:58:02 GMT."
	<4B69AB1A.6010406@mangahigh.com> 
Message-ID: <95767.1265212797@critter.freebsd.dk>

In message <4B69AB1A.6010406 at mangahigh.com>, Richard Chiswell writes:
>Hi all,
>
>I've got a simple question which I've been puzzling on for the last 30 
>minutes or so - how do you change a string in Varnish to lowercase?
>
>Basically, all the links on our site should be lowercase, but some 
>people have been randomly capitalising them when linking to them - I'd 
>just like Varnish to issue a 301 redirect to the lowercased version of 
>the URL: everything is in place apart from converting the string to 
>lowercase.

You'll have to use a bit of inline C code to do that.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From richard.chiswell at mangahigh.com  Wed Feb  3 17:15:30 2010
From: richard.chiswell at mangahigh.com (Richard Chiswell)
Date: Wed, 03 Feb 2010 17:15:30 +0000
Subject: Upper and lower case strings in Varnish
In-Reply-To: <95767.1265212797@critter.freebsd.dk>
References: <95767.1265212797@critter.freebsd.dk>
Message-ID: <4B69AF32.8020402@mangahigh.com>

Hi Poul,

Poul-Henning Kamp wrote:
> In message <4B69AB1A.6010406 at mangahigh.com>, Richard Chiswell writes:
>   
>> I've got a simple question which I've been puzzling on for the last 30 
>> minutes or so - how do you change a string in Varnish to lowercase?
>>     
> You'll have to use a bit of inline C code to do that.
>   
Thanks Poul - any chance of any example of how to do this with a regular 
expression: we currently have:
set obj.http.Location = "http://" req.http.host "/" 
regsub(req.url,"^/(en_gb/|en_us/)?([A-Za-z]+)/?(.*)$","\1\2");
but we only want the \1 lowercased -I've got to
set obj.http.Location = "http://" req.http.host "/" 
regsub(req.url,"^/(en_gb/|en_us/)?([A-Za-z]+)/?(.*)$","C{char 
str[255];str=\1;for (i=0;str[i];i++) { str[i]=tolower(str[i]);return 
str;}C\2");
but that doesn't seem to work. I don't suppose you can point me in the 
right direction (it's been over 10 years since I've done C [since then 
C++, C#.Net, PHP, Perl and Java: so remembering what's valid syntax is 
bad enough, and I've got no idea about the passing to/from varnish side 
of things).

Thank you,
Richard


From l at lrowe.co.uk  Wed Feb  3 17:28:02 2010
From: l at lrowe.co.uk (Laurence Rowe)
Date: Wed, 3 Feb 2010 17:28:02 +0000
Subject: Upper and lower case strings in Varnish
In-Reply-To: <4B69AF32.8020402@mangahigh.com>
References: <95767.1265212797@critter.freebsd.dk>
	<4B69AF32.8020402@mangahigh.com>
Message-ID: <e95443d91002030928x195317c5tf5a5d8e0d5ba88e2@mail.gmail.com>

I don't think it's possible to write a regex that will do that in one
go. There's a dumb solution though:

    set obj.http.Location regsuball(obj.http.Location, "A", "a");
    set obj.http.Location regsuball(obj.http.Location, "B", "b");
    ...

Laurence

On 3 February 2010 17:15, Richard Chiswell
<richard.chiswell at mangahigh.com> wrote:
> Hi Poul,
>
> Poul-Henning Kamp wrote:
>> In message <4B69AB1A.6010406 at mangahigh.com>, Richard Chiswell writes:
>>
>>> I've got a simple question which I've been puzzling on for the last 30
>>> minutes or so - how do you change a string in Varnish to lowercase?
>>>
>> You'll have to use a bit of inline C code to do that.
>>
> Thanks Poul - any chance of any example of how to do this with a regular
> expression: we currently have:
> set obj.http.Location = "http://" req.http.host "/"
> regsub(req.url,"^/(en_gb/|en_us/)?([A-Za-z]+)/?(.*)$","\1\2");
> but we only want the \1 lowercased -I've got to
> set obj.http.Location = "http://" req.http.host "/"
> regsub(req.url,"^/(en_gb/|en_us/)?([A-Za-z]+)/?(.*)$","C{char
> str[255];str=\1;for (i=0;str[i];i++) { str[i]=tolower(str[i]);return
> str;}C\2");
> but that doesn't seem to work. I don't suppose you can point me in the
> right direction (it's been over 10 years since I've done C [since then
> C++, C#.Net, PHP, Perl and Java: so remembering what's valid syntax is
> bad enough, and I've got no idea about the passing to/from varnish side
> of things).
>
> Thank you,
> Richard
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From cosimo at streppone.it  Wed Feb  3 19:52:32 2010
From: cosimo at streppone.it (Cosimo Streppone)
Date: Wed, 03 Feb 2010 20:52:32 +0100
Subject: Upper and lower case strings in Varnish
In-Reply-To: <e95443d91002030928x195317c5tf5a5d8e0d5ba88e2@mail.gmail.com>
References: <95767.1265212797@critter.freebsd.dk>
	<4B69AF32.8020402@mangahigh.com>
	<e95443d91002030928x195317c5tf5a5d8e0d5ba88e2@mail.gmail.com>
Message-ID: <op.u7khhujms5ttvb@ubuntu.ubuntu-domain.local>

On 3 February 2010 17:15, Richard Chiswell
<richard.chiswell at mangahigh.com> wrote:

>> Hi Poul,
>>
>> Poul-Henning Kamp wrote:
>>> In message <4B69AB1A.6010406 at mangahigh.com>, Richard Chiswell writes:
>>>
>>>> I've got a simple question which I've been puzzling on for the last 30
>>>> minutes or so - how do you change a string in Varnish to lowercase?
>>>>
>>> You'll have to use a bit of inline C code to do that.

I'm no varnish or C expert, YMMV etc...
but I managed to get something like this working.

It's a VCL with embedded C that reads the "Accept-Language" header
and rewrites it (or writes into a different header, actually) the
result of some processing function.

Take a look at the examples here:

http://github.com/cosimo/varnish-accept-language/tree/master/examples

sample.vcl is the main VCL file, from which you embed the other one,
accept-language.vcl, which in turn contains the C function you want
to use.

I think `vcl_rewrite_accept_language()' is what you need.
Then you're only missing the upper->lower case bit.

-- 
Cosimo


From moseleymark at gmail.com  Thu Feb  4 00:10:58 2010
From: moseleymark at gmail.com (Mark Moseley)
Date: Wed, 3 Feb 2010 16:10:58 -0800
Subject: GRSEC and Varnish
In-Reply-To: <874olylppy.fsf@qurzaw.linpro.no>
References: <4B684870.9070503@frit.net> <874olylppy.fsf@qurzaw.linpro.no>
Message-ID: <294d5daa1002031610p701686c9sa46f7f24aeca49fb@mail.gmail.com>

On Tue, Feb 2, 2010 at 11:53 PM, Tollef Fog Heen
<tfheen at varnish-software.com> wrote:
> ]] Bernardf FRIT
>
> | Then the parent varnishd process starts immediately a new child process
> | which lasts some time.
> |
> | Is there any way to fix this. Remocve the GRSEC kernel ? Upgrade the
> | kernel ? Varnish ? or whatever ?
>
> Work out why it thinks that varnishd is doing something wrong? ?It
> doesn't seem to say so in the log.
>
> --
> Tollef Fog Heen
> Redpill Linpro -- Changing the game!
> t: +47 21 54 41 73
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>

grsec will often report that signals were sent, not that grsec
necessarily sent that signal itself. I don't think I've ever actually
seen it report itself sending a signal to a process. So varnishd could
be segfaulting for some reason and grsec is just reporting this. If
you're getting a core file, try loading it into gdb and using 'bt' on
it, to see where it's dying.

One other thing to try: As soon as it happens, try using 'dmesg' (or
"dmesg -s 131072" in case you have lots of things logging to the
kernel logs) and grep for PAX. It's not likely, but PAX could be
killing it due to some violation. And for whatever reason, the PAX
message doesn't show up in the logs, just in dmesg.


From kristian at redpill-linpro.com  Thu Feb  4 14:21:38 2010
From: kristian at redpill-linpro.com (Kristian Lyngstol)
Date: Thu, 4 Feb 2010 15:21:38 +0100
Subject: GRSEC and Varnish
In-Reply-To: <4B684870.9070503@frit.net>
References: <4B684870.9070503@frit.net>
Message-ID: <20100204142138.GA9577@kjeks.varnish-software.com>

On Tue, Feb 02, 2010 at 04:44:48PM +0100, Bernardf FRIT wrote:
> Hi,
> 
> I'am running :
> - varnishd (varnish-2.0.4)

Why not 2.0.6?

> and it appears that the grsec Kernel repeatedly and unexpectedly sends 
> signal 11 to the varnishd child.

grsec seems to just report that a segfault occurred. SIGSEG would be a
strange signal to send in any event. You want to fetch yourself a core-dump
of this. However, before we get into that, I'd like to know what parameters
you start Varnish with, and the general setup. VCL too, if possible.

-- 
Kristian Lyngst?l
Redpill Linpro AS
Mob: +47 99014497
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100204/5c26acce/attachment.bin>

From moseleymark at gmail.com  Thu Feb  4 18:10:17 2010
From: moseleymark at gmail.com (Mark Moseley)
Date: Thu, 4 Feb 2010 10:10:17 -0800
Subject: GRSEC and Varnish
In-Reply-To: <4B6AEEE3.3000908@frit.net>
References: <4B684870.9070503@frit.net> <874olylppy.fsf@qurzaw.linpro.no>
	<294d5daa1002031610p701686c9sa46f7f24aeca49fb@mail.gmail.com>
	<4B6AEEE3.3000908@frit.net>
Message-ID: <294d5daa1002041010l502a92b7n9d8bf6ec514b574c@mail.gmail.com>

On Thu, Feb 4, 2010 at 7:59 AM, Bernardf FRIT <bernard at frit.net> wrote:
> Mark Moseley a ?crit :
>>
>> grsec will often report that signals were sent, not that grsec
>> necessarily sent that signal itself. I don't think I've ever actually
>> seen it report itself sending a signal to a process. So varnishd could
>> be segfaulting for some reason and grsec is just reporting this. If
>> you're getting a core file, try loading it into gdb and using 'bt' on
>> it, to see where it's dying.
>
> I cannot get any core file.
>>
>> One other thing to try: As soon as it happens, try using 'dmesg' (or
>> "dmesg -s 131072" in case you have lots of things logging to the
>> kernel logs) and grep for PAX. It's not likely, but PAX could be
>> killing it due to some violation. And for whatever reason, the PAX
>> message doesn't show up in the logs, just in dmesg.
>
> Nothing more in dmesg than in kern.log. ;-[
>
> varnishd[27069]: segfault at 1000 ip 000000000043abf0 sp 0000000045696ae0
> error 4 in varnishd[400000+50000]
> grsec: From 80.13.9.224: signal 11 sent to
> /usr/sbin/varnishd[varnishd:27069] uid/euid:65534/65534
> gid/egid:65534/65534, parent /usr/sbin/varnishd[varnishd:11327] uid/euid:0/0
> gid/egid:0/0
> varnishd[27992]: segfault at 1000 ip 000000000043abf0 sp 0000000048140ae0
> error 4 in varnishd[400000+50000]
> grsec: From 90.4.162.78: signal 11 sent to
> /usr/sbin/varnishd[varnishd:27992] uid/euid:65534/65534
> gid/egid:65534/65534, parent /usr/sbin/varnishd[varnishd:11327] uid/euid:0/0
> gid/egid:0/0
> varnishd[28119]: segfault at ed000 ip 000000000043abf0 sp 0000000047ceaae0
> error 4 in varnishd[400000+50000]
> grsec: From 90.44.219.18: signal 11 sent to
> /usr/sbin/varnishd[varnishd:28119] uid/euid:65534/65534
> gid/egid:65534/65534, parent /usr/sbin/varnishd[varnishd:11327] uid/euid:0/0
> gid/egid:0/0

Try putting "ulimit -c unlimited" in your varnishd rc file. I haven't
needed to get a varnishd core file before, so maybe the devs might be
able to advise if there's other steps necessary as well. There should
also be some logs saying that it died (or at least that it restarted);
dunno what your distro you're using, but in debian, those typically
end up in /var/log/syslog.

You could tail varnishncsa to see if there's a common request where it
seems to segfault at and if there is, you could attach to varnishd
with "gdb /path/to/varnishd <pid of varnishd>" and try to trigger it.
Then get the backtrace with 'bt'. But be aware that it'll bog it down
dreadfully, so i wouldn't advise it in production.


From root at novactive.com  Fri Feb  5 10:42:56 2010
From: root at novactive.com (alertebox)
Date: Fri, 5 Feb 2010 11:42:56 +0100
Subject: Varnish load balancer & (keep session)
Message-ID: <747761DAE0C78D44B79D05BD760F242101C15686@antares.novactive.local>

Version: 2.0.6-1 

Insall: .deb 

Os: Debian 5.0.3

Hi,

I've got two backends running apache2: front1.domain.com &
front2.domain.com, set with the load balancing configuration from
http://varnish-cache.org/wiki/LoadBalancing
<http://varnish-cache.org/wiki/LoadBalancing> .

The issue is, when I shutdown apache2 of the first backend varnish don't
switch to the second and display "Error 503 Service Unavailable", is
that a normal answer from varnish?

Other question, does varnish load balancer keep php sessions for
e-commerce, if yes how will I do?

Varnishlog :

0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008
0.039814 HTTP/1.1 200 OK

0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948
0.066591 HTTP/1.1 200 OK

The S flag is missing in my log, is that an issue...

"4--X-S-RH" to notify that TCP socket shutdown succeeded from
http://varnish-cache.org/wiki/BackendPolling
<http://varnish-cache.org/wiki/BackendPolling> 

Part of default.vcl

backend front1 {

  .host = "front1.domain.com";

  .port = "80";

  .probe = { .url = "/";

             .interval = 10s;

             .timeout = 5s;

             .window = 10;

             .threshold = 8;

 }

}

 

backend front2 {

  .host = "front2.domain.com";

  .port = "80";

  .probe = { .url = "/";

             .interval = 10s;

             .timeout = 5s;

             .window = 10;

             .threshold = 8;

 }

}

 

director b1 random

{

   { .backend = front1; .weight = 1; }

   { .backend = front2; .weight = 1; }

}

 

#director b1 round-robin {

#    { .backend = front1; }

#    { .backend = front2; }

#}

Is that part of configuration is wrong ?

 

Thanks for your help...

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100205/659192a0/attachment.html>

From bernard at frit.net  Fri Feb  5 11:01:00 2010
From: bernard at frit.net (Bernardf FRIT)
Date: Fri, 05 Feb 2010 12:01:00 +0100
Subject: GRSEC and Varnish
In-Reply-To: <874olylppy.fsf@qurzaw.linpro.no>
References: <4B684870.9070503@frit.net> <874olylppy.fsf@qurzaw.linpro.no>
Message-ID: <4B6BFA6C.50806@frit.net>

Tollef Fog Heen a ?crit :
> ]] Bernardf FRIT 
>
> | Then the parent varnishd process starts immediately a new child process 
> | which lasts some time.
> | 
> | Is there any way to fix this. Remocve the GRSEC kernel ? Upgrade the 
> | kernel ? Varnish ? or whatever ?
>
> Work out why it thinks that varnishd is doing something wrong?  It
> doesn't seem to say so in the log.
>   
Seems a bit complicated to add monitoring features on a running GRSEC
kernel. Need to install all kernel files then configure and recompile
the kernel. I will do it if we need it. The only extra feature I found
relevant is CONFIG_GRKERNSEC_RESLOG wich stands for "Denied resource
logging".

I have monitored the following segfault with varnislog :

Jan 29 19:59:07 XXXXXXX varnishd[13812]: segfault at 1000 ip
000000000043abf0 sp 0000000046332ae0 error 4 in varnishd[400000+50000]
Jan 29 19:59:07 XXXXXXX grsec: From 91.163.168.48: signal 11 sent to
/usr/sbin/varnishd[varnishd:13812] uid/euid:65534/65534
gid/egid:65534/65534, pare
nt /usr/sbin/varnishd[varnishd:28927] uid/euid:0/0 gid/egid:0/0

I hope that could help to figure out what happened.

    0 CLI          - Rd ping
    0 CLI          - Wr 0 200 PONG 1264791539 1.0
    0 CLI          - Rd ping
    0 CLI          - Wr 0 200 PONG 1264791542 1.0

    9 SessionOpen  c 91.163.168.48 49273 87.98.137.117:80
    9 ReqStart     c 91.163.168.48 49273 879416771
    9 RxRequest    c GET
    9 RxURL        c /a_liste_ville_cp.php?q=59
    9 RxProtocol   c HTTP/1.1
    9 RxHeader     c x-requested-with: XMLHttpRequest
    9 RxHeader     c Accept-Language: fr
    9 RxHeader     c Referer: http://www.your-immo.fr/recherche.php
    9 RxHeader     c Accept: */*
    9 RxHeader     c UA-CPU: x86
    9 RxHeader     c Accept-Encoding: gzip, deflate
    9 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 6.0; GTB6.3; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; SV1) ; S
LCC1; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.5.30729; .NET CLR
3.0.30618; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)
    9 RxHeader     c Host: www.your-immo.fr
    9 RxHeader     c Connection: Keep-Alive
    9 RxHeader     c Cookie: PHPSESSID=9d73c9bbf8944a710f3d954a2e16c838;
DYNSRV=s0;
__utma=235703049.2110649494.1264791338.1264791338.1264791338.1; __u
tmb=235703049.6.10.1264791338; __utmc=235703049;
__utmz=235703049.1264791338.1.1.utmcsr=google|utmccn=generique|utmcmd=cpc|ut
    9 VCL_call     c recv
    9 VCL_return   c lookup
    9 VCL_call     c hash
    9 VCL_return   c hash
    9 VCL_call     c miss
    9 VCL_return   c fetch
   10 BackendOpen  b ha_proxy 127.0.0.1 35735 127.0.0.1 80
    9 Backend      c 10 ha_proxy ha_proxy
   10 TxRequest    b GET
   10 TxURL        b /a_liste_ville_cp.php?q=59
   10 TxProtocol   b HTTP/1.1
   10 TxHeader     b x-requested-with: XMLHttpRequest
   10 TxHeader     b Accept-Language: fr
   10 TxHeader     b Referer: http://www.your-immo.fr/recherche.php
   10 TxHeader     b Accept: */*
   10 TxHeader     b UA-CPU: x86
   10 TxHeader     b User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 6.0; GTB6.3; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; SV1) ; S
LCC1; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.5.30729; .NET CLR
3.0.30618; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)
   10 TxHeader     b Host: www.your-immo.fr
   10 TxHeader     b Cookie: PHPSESSID=9d73c9bbf8944a710f3d954a2e16c838;
DYNSRV=s0;
__utma=235703049.2110649494.1264791338.1264791338.1264791338.1; __u
tmb=235703049.6.10.1264791338; __utmc=235703049;
__utmz=235703049.1264791338.1.1.utmcsr=google|utmccn=generique|utmcmd=cpc|ut
   10 TxHeader     b X-Forwarded-For: 91.163.168.48
   10 TxHeader     b Accept-Encoding: gzip
   10 TxHeader     b X-Varnish: 879416771
   10 TxHeader     b X-Forwarded-For: 91.163.168.48
   10 RxProtocol   b HTTP/1.1
   10 RxStatus     b 200
   10 RxResponse   b OK
   10 RxHeader     b Date: Fri, 29 Jan 2010 19:05:12 GMT
   10 RxHeader     b Server: Apache
   10 RxHeader     b X-Powered-By: PHP/5.2.5-pl1-gentoo
   10 RxHeader     b Expires: Thu, 19 Nov 1981 08:52:00 GMT
   10 RxHeader     b Cache-Control: no-store, no-cache, must-revalidate,
post-check=0, pre-check=0
   10 RxHeader     b Pragma: no-cache
   10 RxHeader     b Connection: close
   10 RxHeader     b Transfer-Encoding: chunked
   10 RxHeader     b Content-Type: text/html
    9 ObjProtocol  c HTTP/1.1
    9 ObjStatus    c 200
    9 ObjResponse  c OK
    9 ObjHeader    c Date: Fri, 29 Jan 2010 19:05:12 GMT
    9 ObjHeader    c Server: Apache
    9 ObjHeader    c X-Powered-By: PHP/5.2.5-pl1-gentoo
    9 ObjHeader    c Expires: Thu, 19 Nov 1981 08:52:00 GMT
    9 ObjHeader    c Cache-Control: no-store, no-cache, must-revalidate,
post-check=0, pre-check=0
    9 ObjHeader    c Pragma: no-cache
    9 ObjHeader    c Content-Type: text/html
   10 BackendClose b ha_proxy
    9 TTL          c 879416771 RFC 0 1264791545 1264791912 375007920 0 0
    9 VCL_call     c fetch
    9 TTL          c 879416771 VCL 0 1264791545
    9 VCL_return   c pass
    9 Length       c 12193
    9 VCL_call     c deliver
    9 VCL_return   c deliver
    9 TxProtocol   c HTTP/1.1
    9 TxStatus     c 200
    9 TxResponse   c OK
    9 TxHeader     c Expires: Thu, 19 Nov 1981 08:52:00 GMT
    9 TxHeader     c Cache-Control: no-store, no-cache, must-revalidate,
post-check=0, pre-check=0
    9 TxHeader     c Pragma: no-cache
    9 TxHeader     c Content-Type: text/html
    9 TxHeader     c Content-Length: 12193
    9 TxHeader     c X-Cacheable: NO:Not-Cacheable
    9 TxHeader     c Date: Fri, 29 Jan 2010 18:59:05 GMT
    9 TxHeader     c X-Varnish: 879416771
    9 TxHeader     c Age: 0
    9 TxHeader     c Via: 1.1 varnish
    9 TxHeader     c Connection: keep-alive
    9 TxHeader     c X-Served-By: Server 203
    9 TxHeader     c X-Cache: MISS
    9 TxHeader     c Server: Apache-NSCA
    9 ReqEnd       c 879416771 1264791545.113656044 1264791545.259571791
0.011645794 0.145873547 0.000042200
    0 StatAddr     - 91.163.168.48 0 173 23 129 3 9 15 49930 1202797
    0 CLI          - Rd ping
    0 CLI          - Wr 0 200 PONG 1264791545 1.0
    0 WorkThread   - 0x420a0ce0 start
    0 CLI          - Rd vcl.load boot ./vcl.1P9zoqAU.so
    0 CLI          - Wr 0 200 Loaded "./vcl.1P9zoqAU.so" as "boot"
    0 CLI          - Rd vcl.use boot
    0 CLI          - Wr 0 200
    0 CLI          - Rd start
    0 Debug        - "Acceptor is epoll"
    0 CLI          - Wr 0 200
    0 WorkThread   - 0x440a4ce0 start
    0 WorkThread   - 0x448a5ce0 start
    0 WorkThread   - 0x450a6ce0 start
    0 WorkThread   - 0x458a7ce0 start
    0 WorkThread   - 0x460a8ce0 start
    0 WorkThread   - 0x468a9ce0 start
    0 WorkThread   - 0x470aace0 start
    0 WorkThread   - 0x478abce0 start
    0 WorkThread   - 0x480acce0 start
    9 SessionOpen  c 91.163.168.48 49275 87.98.137.117:80
    9 SessionClose c pipe
    9 ReqStart     c 91.163.168.48 49275 667915017
    9 RxRequest    c POST
    9 RxURL        c /recherche.php
    9 RxProtocol   c HTTP/1.1
    9 RxHeader     c Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, application/x-ms-application,
application/vnd.ms-xpsdocument, applica
tion/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
    9 RxHeader     c Referer: http://www.your-immo.fr/recherche.php
    9 RxHeader     c Accept-Language: fr
    9 RxHeader     c Content-Type: application/x-www-form-urlencoded
    9 RxHeader     c UA-CPU: x86
    9 RxHeader     c Accept-Encoding: gzip, deflate
    9 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 6.0; GTB6.3; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; SV1) ; S
LCC1; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.5.30729; .NET CLR
3.0.30618; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)
    9 RxHeader     c Host: www.your-immo.fr
    9 RxHeader     c Content-Length: 240
    9 RxHeader     c Connection: Keep-Alive
    9 RxHeader     c Cache-Control: no-cache
    9 RxHeader     c Cookie: PHPSESSID=9d73c9bbf8944a710f3d954a2e16c838;
DYNSRV=s0;
__utma=235703049.2110649494.1264791338.1264791338.1264791338.1; __u
tmb=235703049.6.10.1264791338; __utmc=235703049;
__utmz=235703049.1264791338.1.1.utmcsr=google|utmccn=generique|utmcmd=cpc|ut
    9 VCL_call     c recv
    9 VCL_return   c pipe
    9 VCL_call     c pipe
    9 VCL_return   c pipe
   10 BackendOpen  b ha_proxy 127.0.0.1 35741 127.0.0.1 80
    9 Backend      c 10 ha_proxy ha_proxy
   10 TxRequest    b POST
   10 TxURL        b /recherche.php
   10 TxProtocol   b HTTP/1.1
   10 TxHeader     b Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, application/x-ms-application,
application/vnd.ms-xpsdocument, applica
tion/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
   10 TxHeader     b Referer: http://www.your-immo.fr/recherche.php







From bernard at frit.net  Fri Feb  5 11:01:23 2010
From: bernard at frit.net (Bernardf FRIT)
Date: Fri, 05 Feb 2010 12:01:23 +0100
Subject: GRSEC and Varnish
In-Reply-To: <20100204142138.GA9577@kjeks.varnish-software.com>
References: <4B684870.9070503@frit.net>
	<20100204142138.GA9577@kjeks.varnish-software.com>
Message-ID: <4B6BFA83.1090205@frit.net>

Kristian Lyngstol a ?crit :
> On Tue, Feb 02, 2010 at 04:44:48PM +0100, Bernardf FRIT wrote:
>> Hi,
>>
>> I'am running :
>> - varnishd (varnish-2.0.4)
>
> Why not 2.0.6?
When a server is running well, I'm a bit reluctant to upgrade. Now, I'm
ok to upgrade as an attempt to fix this.

>> and it appears that the grsec Kernel repeatedly and unexpectedly sends 
>> signal 11 to the varnishd child.
>
> grsec seems to just report that a segfault occurred. SIGSEG would be a
> strange signal to send in any event. You want to fetch yourself a core-dump
> of this. However, before we get into that, I'd like to know what parameters
> you start Varnish with, and the general setup. VCL too, if possible.
>
Ok, I just misunderstood the grsec report. I can't find any core dump
file in the system.

I start varnishd using /etc/init.d/varnishd with the following parameters :

# cat /etc/conf.d/varnishd
# /etc/conf.d/varnishd

# options passed to varnish on startup
# please see the varnishd man page for more options
VARNISHD_OPTS="-a 87.98.137.117:80 -f /etc/varnish/yourimmo.vcl -n
/home/varnish/yourimmo -s file,/home/varnish/cache/yourimmo,1G -T
127.0.0.1:7777"

# arguments passed to varnishncsa
# please see the varnishncsa man page for more options
VARNISHNCSA_ARGS="-c -a -n /home/varnish/yourimmo -w
/var/log/varnish/access.log"

-----------------------------------------------------------------------------------------------

# cat /etc/varnish/yourimmo.vcl
### define backends:

# ha proxy
backend ha_proxy {
    .host = "127.0.0.1";
    .port = "80";
}

acl purge {
    "localhost";
    "111.111.111.111";
}

### Called when a client request is received

sub vcl_recv {

### if there is a purge make sure its coming from $localhost

        if (req.request == "PURGE") {
            if (!client.ip ~ purge) {
                error 405 "Not allowed.";
                }
            lookup;
        }

# Add a unique header containing the client address
remove req.http.X-Forwarded-For;
set    req.http.X-Forwarded-For = client.ip;

# set    req.http.X-Forwarded-For = req.http.rlnclientipaddr;

# grace settings, note this is also set in vcl_fetch,
set req.grace = 600s;

if (req.http.host ~ "^(www.)?your-immo.fr$") {
        set req.backend = ha_proxy;
}

### ne pas mettre en cache:

        if (req.request == "GET" && req.url ~ "\.(php|html)$") {
                pass;
        }
        if (req.request == "GET" && req.url ~ "\.(your-immo\.fr)$") {
                pass;
        }

### toujours mettre en cache:

     if (req.request == "GET" && req.url ~ "\.(js)") {
                lookup;
        }

        ## images
        if (req.request == "GET" && req.url ~
"\.(gif|jpg|jpeg|bmp|png|tiff|tif|ico|img|tga|wmf)$") {
        lookup;
        }

        ## pages statiques
        if (req.request == "GET" && req.url ~ "\.(css|pdf|exe)$") {
        lookup;
        }

  ## multimedia
        if (req.request == "GET" && req.url ~
"\.(svg|swf|ico|mp3|mp4|m4a|ogg|mov|avi|wmv)$") {
        lookup;
        }

        ## xml

        if (req.request == "GET" && req.url ~ "\.(xml)$") {
        lookup;
        }

### regles a  ne pas mettre en cache:

        if (req.request == "GET" && req.url ~ "\/stats") {
                 pipe;
        }
        if (req.request != "GET" && req.request != "HEAD") {
                pipe;
        }
        if (req.http.Authenticate || req.http.Authorization) {
                pass;
        }

###  ne pas mettre en cache les sessions d'authenticfication
        if (req.http.Cookie && req.http.Cookie ~ "authtoken=") {
                pipe;
        }


### parse accept encoding rulesets to make it look nice
        if (req.http.Accept-Encoding) {
                if (req.http.Accept-Encoding ~ "gzip") {
                        set req.http.Accept-Encoding = "gzip";
                } elsif (req.http.Accept-Encoding ~ "deflate") {
                        set req.http.Accept-Encoding = "deflate";
                } else {
                        # unkown algorithm
                        remove req.http.Accept-Encoding;
                }
        }

### Modif suite a segfault
        pass;

### if it passes all these tests, do a lookup anyway;
###        lookup;

### end of vcl_recv
}

### Called when an object is in the cache, its a hit.
sub vcl_hit {
  if (req.request == "PURGE") {
      set obj.ttl = 0s;
      error 200 "Purged.";
  }
  if (!obj.cacheable) {
      pass;
  }

deliver;
}

### Called when the requested object was not found in the cache

sub vcl_miss {
  if (req.request == "PURGE") {
      error 404 "Not in cache.";
  }
}

### Called when the requested object has been retrieved from the
backend, or the request to the backend has failed

sub vcl_fetch {

## If the request to the backend returns a code other than 200, restart
the loop
## If the number of restarts reaches the value of the parameter
max_restarts,
## the request will be error'ed.  max_restarts defaults to 4.  This
prevents
## an eternal loop in the event that, e.g., the object does not exist
at all.
## this rule also allows for 301's and 302's redirects...

        if (obj.status != 200 && obj.status != 403 && obj.status != 404
&& obj.status != 301 && obj.status != 302) {
           restart;
        }

        # if i cant connect to the backend, ill set the grace period to
be 600 seconds to hold onto content
        set obj.ttl = 0s;
        set obj.grace = 600s;

        if (obj.status == 404) {
        set obj.ttl = 0s;
        }

        if (obj.status >= 500) {
        set obj.ttl = 0s;
        }

        if (req.request == "GET" && req.url ~
"\.(gif|jpg|jpeg|bmp|png|tiff|tif|ico|img|tga|wmf)$") {
        set obj.ttl = 24h;
        }

        ## various other content pages
        if (req.request == "GET" && req.url ~ "\.(css|pdf|exe)$") {
        set obj.ttl = 24h;
        }

        if (req.request == "GET" && req.url ~ "\.(js)$") {
        set obj.ttl = 24h;
        }

        ## xml
        if (req.request == "GET" && req.url ~ "\.(xml)$") {
        set obj.ttl = 24h;
        }

        ## multimedia
        if (req.request == "GET" && req.url ~
"\.(svg|swf|ico|mp3|mp4|m4a|ogg|mov|avi|wmv)$") {
        set obj.ttl = 24h;
        }

        if (!obj.cacheable) {
        set obj.http.X-Cacheable = "NO:Not-Cacheable";
        pass;
        }

        if (obj.http.Set-Cookie) {
        pass;
        }

        if (req.request == "HEAD") {
        set obj.http.head = "yes";
        }

        set obj.http.X-Cacheable = "YES";
        deliver;
}

#
#
## Called before a cached object is delivered to the client
#
sub vcl_deliver {

  set resp.http.X-Served-By = "Server 203";
  if (obj.hits > 0) {
    set resp.http.X-Cache = "HIT";
    set resp.http.X-Cache-Hits = obj.hits;
  } else {
    set resp.http.X-Cache = "MISS";
  }
    remove resp.http.X-Powered-By;
    set resp.http.Server="Apache-NSCA";
  deliver;
}







From fulanpeng at gmail.com  Fri Feb  5 12:01:56 2010
From: fulanpeng at gmail.com (fulan Peng)
Date: Fri, 5 Feb 2010 20:01:56 +0800
Subject: How to modify backend content before it reach to client's browser?
Message-ID: <bf0f1bc91002050401q461a8368q136e3659cf412222@mail.gmail.com>

Hi,

I am looking for the functionality similar to Apache's mod_proxy_html.
It can modify backend's content before it reach to customer. I used it
to rewrite url in the links.

Usually, when people are talking about url rewriting, they mean to
rewrite the url before send out to backend. That is varnish's url
rewriting. That is not I want.

Thanks a lot!

Fulan Peng


From richard.chiswell at mangahigh.com  Fri Feb  5 13:04:43 2010
From: richard.chiswell at mangahigh.com (Richard Chiswell)
Date: Fri, 05 Feb 2010 13:04:43 +0000
Subject: How to modify backend content before it reach to client's browser?
In-Reply-To: <bf0f1bc91002050401q461a8368q136e3659cf412222@mail.gmail.com>
References: <bf0f1bc91002050401q461a8368q136e3659cf412222@mail.gmail.com>
Message-ID: <4B6C176B.4040004@mangahigh.com>

Hello Fulan,

I'm not sure what you are asking from Varnish. You could use its ESI ( 
http://varnish-cache.org/wiki/ESIfeatures ) to include additional 
content or "synthetic" ( http://varnish-cache.org/wiki/VCLSyntaxStrings 
) to set the content. I don't think you are able to change the contents 
of URLs "on the fly" in Varnish without using inline C.

If you are actually looking at redirecting URLs, you may find code such as:

sub vcl_recv {
....
if (req.url ~ "^/rgb([A-z0-9]+)$") {
        error 750 "ukredirect";
}
...
}
sub vcl_error {
...
    if (obj.status == 750) {
    if (obj.response == "ukredirect") {
         set obj.http.Location = "http://" req.http.host 
regsub(req.url,"^/rgb([A-z0-9]+)$","/en_gb/?utm_source=ukredirect&utm_medium=web&utm_campaign=\1");
         set obj.status = 301;
         set obj.response = "Found";
         deliver;
    }
}
...
}
useful to redirect the users browser without touching the backend.

Yours,
Richard

fulan Peng wrote:
> Hi,
>
> I am looking for the functionality similar to Apache's mod_proxy_html.
> It can modify backend's content before it reach to customer. I used it
> to rewrite url in the links.
>
> Usually, when people are talking about url rewriting, they mean to
> rewrite the url before send out to backend. That is varnish's url
> rewriting. That is not I want.
>
> Thanks a lot!
>
> Fulan Peng
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>   



From m.walraven at terantula.com  Fri Feb  5 15:47:16 2010
From: m.walraven at terantula.com (Marco Walraven)
Date: Fri, 5 Feb 2010 16:47:16 +0100
Subject: Varnish User Group meeting 2 [VUG2] 29+30/03/2010
Message-ID: <20100205154715.GF21823@cotton.terantula.com>

                                                                                         
Hi all,                                                                                  

On March the 29th and 30th the second Varnish User Group meeting will be
held in the Bay / Marktplaats.nl offices in Amsterdam.

See http://varnish-cache.org/wiki/VUG2 for all information and how to sign up.
We have a max of 15 open seats, please sign up if you are actually attending. 
However be quick to sign-up, the seats might be taken quickly.

Regards,

Marco

-- 
 Terantula - Industrial Strength Open Source
 phone:+31 64 3232 400 / www: http://www.terantula.com / pgpkey: E7EE7A46
 pgp fingerprint: F2EE 122D 964C DE68 7380 6F95 3710 7719 E7EE 7A46 


From fulanpeng at gmail.com  Sat Feb  6 00:12:23 2010
From: fulanpeng at gmail.com (fulan Peng)
Date: Sat, 6 Feb 2010 08:12:23 +0800
Subject: How to modify backend content before it reach to client's 
	browser?
In-Reply-To: <4B6C176B.4040004@mangahigh.com>
References: <bf0f1bc91002050401q461a8368q136e3659cf412222@mail.gmail.com>
	<4B6C176B.4040004@mangahigh.com>
Message-ID: <bf0f1bc91002051612m173d41cah22d826a85c16b1b9@mail.gmail.com>

Thank you for your response.

I am not looking to include additional content or synthetic something
to the content. I am trying to rewrite the url in the content. This
can be done by Apache mod_proxy_html. I made it working. But Apache
breaks some web pages. I want to try something else.
Yes. I want to change the content "on the fly". I found only Apache
mod_proxy_html and Microsoft IIS .NET something can do it.  All others
are not able to do this.
I would try inline C at Varnish. I do not want do anything with Microsoft.
Thanks !

Fulan Peng


On Fri, Feb 5, 2010 at 9:04 PM, Richard Chiswell
<richard.chiswell at mangahigh.com> wrote:
> Hello Fulan,
>
> I'm not sure what you are asking from Varnish. You could use its ESI (
> http://varnish-cache.org/wiki/ESIfeatures ) to include additional content or
> "synthetic" ( http://varnish-cache.org/wiki/VCLSyntaxStrings ) to set the
> content. I don't think you are able to change the contents of URLs "on the
> fly" in Varnish without using inline C.
>
> If you are actually looking at redirecting URLs, you may find code such as:
>
> sub vcl_recv {
> ....
> if (req.url ~ "^/rgb([A-z0-9]+)$") {
> ? ? ? error 750 "ukredirect";
> }
> ...
> }
> sub vcl_error {
> ...
> ? if (obj.status == 750) {
> ? if (obj.response == "ukredirect") {
> ? ? ? ?set obj.http.Location = "http://" req.http.host
> regsub(req.url,"^/rgb([A-z0-9]+)$","/en_gb/?utm_source=ukredirect&utm_medium=web&utm_campaign=\1");
> ? ? ? ?set obj.status = 301;
> ? ? ? ?set obj.response = "Found";
> ? ? ? ?deliver;
> ? }
> }
> ...
> }
> useful to redirect the users browser without touching the backend.
>
> Yours,
> Richard
>
> fulan Peng wrote:
>>
>> Hi,
>>
>> I am looking for the functionality similar to Apache's mod_proxy_html.
>> It can modify backend's content before it reach to customer. I used it
>> to rewrite url in the links.
>>
>> Usually, when people are talking about url rewriting, they mean to
>> rewrite the url before send out to backend. That is varnish's url
>> rewriting. That is not I want.
>>
>> Thanks a lot!
>>
>> Fulan Peng
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>>
>
>


From rtshilston at gmail.com  Sat Feb  6 11:59:33 2010
From: rtshilston at gmail.com (Rob S)
Date: Sat, 06 Feb 2010 11:59:33 +0000
Subject: Varnish load balancer & (keep session)
In-Reply-To: <747761DAE0C78D44B79D05BD760F242101C15686@antares.novactive.local>
References: <747761DAE0C78D44B79D05BD760F242101C15686@antares.novactive.local>
Message-ID: <4B6D59A5.80900@gmail.com>

Hi,

To answer some of your questions:

1) 503 error when shutting down a backend:  When you shutdown the 
backend, do you see varnishlog say that the backend is healthy or sick?  
If one is sick, then the other should get the traffic if your VCL 
contains set req.backend = b1;

2) Vanish load balanced does not keep e-commerce sessions for PHP.  The 
simplest solution to this is to install memcache, and put the following 
lines in your php.ini file:

[Session]
session.save_handler = memcached
session.save_path = "memcache-server1:11211,memcache-server2:11211"

instead of session.save_handler = files

However, I can't say for certain that this will definitely work - it 
depends on how your ecommerce application operates. 

3) S-flag: I'm not sure about this, but my gut feeling is that it's not 
causing the problems you're seeing.



Rob


alertebox wrote:
>
> Version: 2.0.6-1
>
> Insall: .deb
>
> Os: Debian 5.0.3
>
> Hi,
>
> I've got two backends running apache2: front1.domain.com & 
> front2.domain.com, set with the load balancing configuration 
> from http://varnish-cache.org/wiki/LoadBalancing.
>
> _The issue is, when I shutdown apache2 of the first backend varnish 
> don't switch to the second and display "Error 503 Service 
> Unavailable", is that a normal answer from varnish?_
>
> Other question, _does varnish load balancer keep php sessions for 
> e-commerce, if yes how will I do?_
>
> Varnishlog :
>
> 0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008 
> 0.039814 HTTP/1.1 200 OK
>
> 0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948 
> 0.066591 HTTP/1.1 200 OK
>
> _The S flag is missing in my log, is that an issue?_
>
> "4--X-S-RH" to notify that TCP socket shutdown succeeded 
> from http://varnish-cache.org/wiki/BackendPolling
>
> Part of default.vcl
>
> backend front1 {
>
>   .host = "front1.domain.com";
>
>   .port = "80";
>
>   .probe = { .url = "/";
>
>              .interval = 10s;
>
>              .timeout = 5s;
>
>              .window = 10;
>
>              .threshold = 8;
>
>  }
>
> }
>
>  
>
> backend front2 {
>
>   .host = "front2.domain.com";
>
>   .port = "80";
>
>   .probe = { .url = "/";
>
>              .interval = 10s;
>
>              .timeout = 5s;
>
>              .window = 10;
>
>              .threshold = 8;
>
>  }
>
> }
>
>  
>
> director b1 random
>
> {
>
>    { .backend = front1; .weight = 1; }
>
>    { .backend = front2; .weight = 1; }
>
> }
>
>  
>
> #director b1 round-robin {
>
> #    { .backend = front1; }
>
> #    { .backend = front2; }
>
> #}
>
> _Is that part of configuration is wrong_ ?
>
>  
>
> Thanks for your help...
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>   



From torrance123 at gmail.com  Sun Feb  7 09:56:00 2010
From: torrance123 at gmail.com (Torrance)
Date: Sun, 07 Feb 2010 22:56:00 +1300
Subject: 503 Errors on POST
In-Reply-To: <4B637011.3010008@gmail.com>
References: <4B627C00.2040001@gmail.com> <87fx5p436q.fsf@qurzaw.linpro.no>
	<4B637011.3010008@gmail.com>
Message-ID: <4B6E8E30.9030100@gmail.com>

I've no response to this on list, and the problem is ongoing. Should I
file this as a bug?

Torrance



On 30/01/10 12:32 PM, Torrance wrote:
> Hi Tollef,
>
> I've pasted the logs of two failed requests below. As you can see,
> they're both in response to POST requests, though I was overstating the
> frequency at which these errors are occurring: they're occurring about
> 10% of the time.
>
> To be honest, I don't entirely understand the logs or their format, but
> I hope I've captured the important details. (Session IDs have been
> deleted, btw).
>
> Many thanks,
> Torrance
>
>
>    15 ReqStart     c 125.236.128.219 51361 561006524
>    15 RxRequest    c POST
>    15 RxURL        c /node/78063/edit
>    15 RxProtocol   c HTTP/1.1
>    15 RxHeader     c Host: indymedia.org.nz
>    15 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>    15 RxHeader     c Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>    15 RxHeader     c Accept-Language: en-gb,en;q=0.5
>    15 RxHeader     c Accept-Encoding: gzip,deflate
>    15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    15 RxHeader     c Keep-Alive: 115
>    15 RxHeader     c Connection: keep-alive
>    15 RxHeader     c Referer: http://indymedia.org.nz/node/78063/edit
>    15 RxHeader     c Cookie: comment_info_name=Tester;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>    15 RxHeader     c Content-Type: multipart/form-data;
> boundary=---------------------------1850078892860212931738819713
>    15 RxHeader     c Content-Length: 16978
>    15 VCL_call     c recv
>    15 VCL_return   c pass
>    15 VCL_call     c pass
>    15 VCL_return   c pass
>    15 Backend      c 10 default default
>    10 TxRequest    b POST
>    10 TxURL        b /node/78063/edit
>    10 TxProtocol   b HTTP/1.1
>    10 TxHeader     b Host: indymedia.org.nz
>    10 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>    10 TxHeader     b Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>    10 TxHeader     b Accept-Language: en-gb,en;q=0.5
>    10 TxHeader     b Accept-Encoding: gzip,deflate
>    10 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    10 TxHeader     b Referer: http://indymedia.org.nz/node/78063/edit
>    10 TxHeader     b Cookie: comment_info_name=Tester;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>    10 TxHeader     b Content-Type: multipart/form-data;
> boundary=---------------------------1850078892860212931738819713
>    10 TxHeader     b Content-Length: 16978
>    10 TxHeader     b X-Forwarded-For: 125.236.128.219
>    10 TxHeader     b X-Varnish: 561006524
>    10 TxHeader     b X-Forwarded-For: 125.236.128.219
>    10 BackendClose b default
>    15 VCL_call     c error
>    15 VCL_return   c deliver
>    15 Length       c 465
>    15 VCL_call     c deliver
>    15 VCL_return   c deliver
>    15 TxProtocol   c HTTP/1.1
>    15 TxStatus     c 503
>    15 TxResponse   c Service Unavailable
>    15 TxHeader     c Server: Varnish
>    15 TxHeader     c Retry-After: 0
>    15 TxHeader     c Content-Type: text/html; charset=utf-8
>    15 TxHeader     c Content-Length: 465
>    15 TxHeader     c Date: Fri, 29 Jan 2010 23:00:42 GMT
>    15 TxHeader     c X-Varnish: 561006524
>    15 TxHeader     c Age: 1
>    15 TxHeader     c Via: 1.1 varnish
>    15 TxHeader     c Connection: close
>    15 ReqEnd       c 561006524 1264806040.957435846 1264806042.241542339
> 4.125935793 1.284075260 0.000031233
>    15 SessionClose c error
>    15 StatSess     c 125.236.128.219 51361 14 1 3 0 3 2 1410 49426
>     0 StatAddr     - 125.236.128.219 0 1102 34 74 0 32 42 38287 1054700
>
>
>    21 ReqStart     c 125.236.128.219 53669 561007510
>    21 RxRequest    c POST
>    21 RxURL        c /node/78063/edit
>    21 RxProtocol   c HTTP/1.1
>    21 RxHeader     c Host: indymedia.org.nz
>    21 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>    21 RxHeader     c Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>    21 RxHeader     c Accept-Language: en-gb,en;q=0.5
>    21 RxHeader     c Accept-Encoding: gzip,deflate
>    21 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    21 RxHeader     c Keep-Alive: 115
>    21 RxHeader     c Connection: keep-alive
>    21 RxHeader     c Referer: http://indymedia.org.nz/node/78063/edit
>    21 RxHeader     c Cookie: comment_info_name=Tester;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>    21 RxHeader     c Content-Type: multipart/form-data;
> boundary=---------------------------84863282515329900481602423677
>    21 RxHeader     c Content-Length: 17019
>    21 VCL_call     c recv
>    21 VCL_return   c pass
>    21 VCL_call     c pass
>    21 VCL_return   c pass
>    21 Backend      c 15 default default
>    15 TxRequest    b POST
>    15 TxURL        b /node/78063/edit
>    15 TxProtocol   b HTTP/1.1
>    15 TxHeader     b Host: indymedia.org.nz
>    15 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>    15 TxHeader     b Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>    15 TxHeader     b Accept-Language: en-gb,en;q=0.5
>    15 TxHeader     b Accept-Encoding: gzip,deflate
>    15 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>    15 TxHeader     b Referer: http://indymedia.org.nz/node/78063/edit
>    15 TxHeader     b Cookie: comment_info_name=Tester;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>    15 TxHeader     b Content-Type: multipart/form-data;
> boundary=---------------------------84863282515329900481602423677
>    15 TxHeader     b Content-Length: 17019
>    15 TxHeader     b X-Forwarded-For: 125.236.128.219
>    15 TxHeader     b X-Varnish: 561007510
>    15 TxHeader     b X-Forwarded-For: 125.236.128.219
>    15 BackendClose b default
>    21 VCL_call     c error
>    21 VCL_return   c deliver
>    21 Length       c 465
>    21 VCL_call     c deliver
>    21 VCL_return   c deliver
>    21 TxProtocol   c HTTP/1.1
>    21 TxStatus     c 503
>    21 TxResponse   c Service Unavailable
>    21 TxHeader     c Server: Varnish
>    21 TxHeader     c Retry-After: 0
>    21 TxHeader     c Content-Type: text/html; charset=utf-8
>    21 TxHeader     c Content-Length: 465
>    21 TxHeader     c Date: Fri, 29 Jan 2010 23:22:15 GMT
>    21 TxHeader     c X-Varnish: 561007510
>    21 TxHeader     c Age: 2
>    21 TxHeader     c Via: 1.1 varnish
>    21 TxHeader     c Connection: close
>    21 ReqEnd       c 561007510 1264807333.799563885 1264807335.335580826
> 3.151196718 1.535988092 0.000028849
>    21 SessionClose c error
>    21 StatSess     c 125.236.128.219 53669 35 1 9 0 5 4 4595 137808
>     0 StatAddr     - 125.236.128.219 0 2395 45 114 0 53 61 58675 1768498
>
> On 29/01/10 11:26 PM, Tollef Fog Heen wrote:
>   
>> ]] Torrance 
>>
>> | I am running a drupal site behind Varnish and when posts or comments are
>> | submitted there's about a 50/50 chance the user will get one of
>> | Varnish's 503 error pages. These errors aren't after waiting a little
>> | while or even a few seconds - they are returned with no delay
>> | whatsoever. I can only presume that this is somehow linked to the fact
>> | that these are POST requests, as the errors do not come up at any other
>> | time.
>>
>> If you can capture a varnishlog from a good and a failing request, that
>> might shed some light on what's going on.
>>
>>   
>>     
>   


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 905 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100207/d9201c88/attachment.bin>

From rtshilston at gmail.com  Sun Feb  7 10:04:00 2010
From: rtshilston at gmail.com (Rob S)
Date: Sun, 07 Feb 2010 10:04:00 +0000
Subject: 503 Errors on POST
In-Reply-To: <4B6E8E30.9030100@gmail.com>
References: <4B627C00.2040001@gmail.com>
	<87fx5p436q.fsf@qurzaw.linpro.no>	<4B637011.3010008@gmail.com>
	<4B6E8E30.9030100@gmail.com>
Message-ID: <4B6E9010.7080409@gmail.com>

Torrance,

Can you upload a full tcpdump packet trace both between client and 
varnish, and varnish and backend, together with the varnish logs and 
varnish config, and I'll take a look.


Rob

Torrance wrote:
> I've no response to this on list, and the problem is ongoing. Should I
> file this as a bug?
>
> Torrance
>
>
>
> On 30/01/10 12:32 PM, Torrance wrote:
>   
>> Hi Tollef,
>>
>> I've pasted the logs of two failed requests below. As you can see,
>> they're both in response to POST requests, though I was overstating the
>> frequency at which these errors are occurring: they're occurring about
>> 10% of the time.
>>
>> To be honest, I don't entirely understand the logs or their format, but
>> I hope I've captured the important details. (Session IDs have been
>> deleted, btw).
>>
>> Many thanks,
>> Torrance
>>
>>
>>    15 ReqStart     c 125.236.128.219 51361 561006524
>>    15 RxRequest    c POST
>>    15 RxURL        c /node/78063/edit
>>    15 RxProtocol   c HTTP/1.1
>>    15 RxHeader     c Host: indymedia.org.nz
>>    15 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
>> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>>    15 RxHeader     c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>    15 RxHeader     c Accept-Language: en-gb,en;q=0.5
>>    15 RxHeader     c Accept-Encoding: gzip,deflate
>>    15 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>    15 RxHeader     c Keep-Alive: 115
>>    15 RxHeader     c Connection: keep-alive
>>    15 RxHeader     c Referer: http://indymedia.org.nz/node/78063/edit
>>    15 RxHeader     c Cookie: comment_info_name=Tester;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>>    15 RxHeader     c Content-Type: multipart/form-data;
>> boundary=---------------------------1850078892860212931738819713
>>    15 RxHeader     c Content-Length: 16978
>>    15 VCL_call     c recv
>>    15 VCL_return   c pass
>>    15 VCL_call     c pass
>>    15 VCL_return   c pass
>>    15 Backend      c 10 default default
>>    10 TxRequest    b POST
>>    10 TxURL        b /node/78063/edit
>>    10 TxProtocol   b HTTP/1.1
>>    10 TxHeader     b Host: indymedia.org.nz
>>    10 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
>> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>>    10 TxHeader     b Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>    10 TxHeader     b Accept-Language: en-gb,en;q=0.5
>>    10 TxHeader     b Accept-Encoding: gzip,deflate
>>    10 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>    10 TxHeader     b Referer: http://indymedia.org.nz/node/78063/edit
>>    10 TxHeader     b Cookie: comment_info_name=Tester;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>>    10 TxHeader     b Content-Type: multipart/form-data;
>> boundary=---------------------------1850078892860212931738819713
>>    10 TxHeader     b Content-Length: 16978
>>    10 TxHeader     b X-Forwarded-For: 125.236.128.219
>>    10 TxHeader     b X-Varnish: 561006524
>>    10 TxHeader     b X-Forwarded-For: 125.236.128.219
>>    10 BackendClose b default
>>    15 VCL_call     c error
>>    15 VCL_return   c deliver
>>    15 Length       c 465
>>    15 VCL_call     c deliver
>>    15 VCL_return   c deliver
>>    15 TxProtocol   c HTTP/1.1
>>    15 TxStatus     c 503
>>    15 TxResponse   c Service Unavailable
>>    15 TxHeader     c Server: Varnish
>>    15 TxHeader     c Retry-After: 0
>>    15 TxHeader     c Content-Type: text/html; charset=utf-8
>>    15 TxHeader     c Content-Length: 465
>>    15 TxHeader     c Date: Fri, 29 Jan 2010 23:00:42 GMT
>>    15 TxHeader     c X-Varnish: 561006524
>>    15 TxHeader     c Age: 1
>>    15 TxHeader     c Via: 1.1 varnish
>>    15 TxHeader     c Connection: close
>>    15 ReqEnd       c 561006524 1264806040.957435846 1264806042.241542339
>> 4.125935793 1.284075260 0.000031233
>>    15 SessionClose c error
>>    15 StatSess     c 125.236.128.219 51361 14 1 3 0 3 2 1410 49426
>>     0 StatAddr     - 125.236.128.219 0 1102 34 74 0 32 42 38287 1054700
>>
>>
>>    21 ReqStart     c 125.236.128.219 53669 561007510
>>    21 RxRequest    c POST
>>    21 RxURL        c /node/78063/edit
>>    21 RxProtocol   c HTTP/1.1
>>    21 RxHeader     c Host: indymedia.org.nz
>>    21 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
>> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>>    21 RxHeader     c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>    21 RxHeader     c Accept-Language: en-gb,en;q=0.5
>>    21 RxHeader     c Accept-Encoding: gzip,deflate
>>    21 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>    21 RxHeader     c Keep-Alive: 115
>>    21 RxHeader     c Connection: keep-alive
>>    21 RxHeader     c Referer: http://indymedia.org.nz/node/78063/edit
>>    21 RxHeader     c Cookie: comment_info_name=Tester;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>>    21 RxHeader     c Content-Type: multipart/form-data;
>> boundary=---------------------------84863282515329900481602423677
>>    21 RxHeader     c Content-Length: 17019
>>    21 VCL_call     c recv
>>    21 VCL_return   c pass
>>    21 VCL_call     c pass
>>    21 VCL_return   c pass
>>    21 Backend      c 15 default default
>>    15 TxRequest    b POST
>>    15 TxURL        b /node/78063/edit
>>    15 TxProtocol   b HTTP/1.1
>>    15 TxHeader     b Host: indymedia.org.nz
>>    15 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
>> X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
>>    15 TxHeader     b Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>    15 TxHeader     b Accept-Language: en-gb,en;q=0.5
>>    15 TxHeader     b Accept-Encoding: gzip,deflate
>>    15 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>    15 TxHeader     b Referer: http://indymedia.org.nz/node/78063/edit
>>    15 TxHeader     b Cookie: comment_info_name=Tester;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
>> SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1
>>    15 TxHeader     b Content-Type: multipart/form-data;
>> boundary=---------------------------84863282515329900481602423677
>>    15 TxHeader     b Content-Length: 17019
>>    15 TxHeader     b X-Forwarded-For: 125.236.128.219
>>    15 TxHeader     b X-Varnish: 561007510
>>    15 TxHeader     b X-Forwarded-For: 125.236.128.219
>>    15 BackendClose b default
>>    21 VCL_call     c error
>>    21 VCL_return   c deliver
>>    21 Length       c 465
>>    21 VCL_call     c deliver
>>    21 VCL_return   c deliver
>>    21 TxProtocol   c HTTP/1.1
>>    21 TxStatus     c 503
>>    21 TxResponse   c Service Unavailable
>>    21 TxHeader     c Server: Varnish
>>    21 TxHeader     c Retry-After: 0
>>    21 TxHeader     c Content-Type: text/html; charset=utf-8
>>    21 TxHeader     c Content-Length: 465
>>    21 TxHeader     c Date: Fri, 29 Jan 2010 23:22:15 GMT
>>    21 TxHeader     c X-Varnish: 561007510
>>    21 TxHeader     c Age: 2
>>    21 TxHeader     c Via: 1.1 varnish
>>    21 TxHeader     c Connection: close
>>    21 ReqEnd       c 561007510 1264807333.799563885 1264807335.335580826
>> 3.151196718 1.535988092 0.000028849
>>    21 SessionClose c error
>>    21 StatSess     c 125.236.128.219 53669 35 1 9 0 5 4 4595 137808
>>     0 StatAddr     - 125.236.128.219 0 2395 45 114 0 53 61 58675 1768498
>>
>> On 29/01/10 11:26 PM, Tollef Fog Heen wrote:
>>   
>>     
>>> ]] Torrance 
>>>
>>> | I am running a drupal site behind Varnish and when posts or comments are
>>> | submitted there's about a 50/50 chance the user will get one of
>>> | Varnish's 503 error pages. These errors aren't after waiting a little
>>> | while or even a few seconds - they are returned with no delay
>>> | whatsoever. I can only presume that this is somehow linked to the fact
>>> | that these are POST requests, as the errors do not come up at any other
>>> | time.
>>>
>>> If you can capture a varnishlog from a good and a failing request, that
>>> might shed some light on what's going on.
>>>
>>>   
>>>     



From a.deau at novactive.com  Fri Feb  5 09:13:33 2010
From: a.deau at novactive.com (Axel DEAU)
Date: Fri, 5 Feb 2010 10:13:33 +0100
Subject: Varnish load balancer & (keep session)
Message-ID: <747761DAE0C78D44B79D05BD760F242101C15642@antares.novactive.local>

Version: 2.0.6-1 

Insall: .deb 

Os: Debian 5.0.3

Hi,

I've got two backends running apache2: front1.domain.com &
front2.domain.com, set with the load balancing configuration from
http://varnish-cache.org/wiki/LoadBalancing
<http://varnish-cache.org/wiki/LoadBalancing> .

The issue is, when I shutdown apache2 of the first backend varnish don't
switch to the second and display "Error 503 Service Unavailable", is
that a normal answer from varnish?

Other question, does varnish load balancer keep php sessions, if yes how
will I do?

Varnishlog :

0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008
0.039814 HTTP/1.1 200 OK

0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948
0.066591 HTTP/1.1 200 OK

The S flag is missing in my log, is that an issue...

"4--X-S-RH" to notify that TCP socket shutdown succeeded from
http://varnish-cache.org/wiki/BackendPolling
<http://varnish-cache.org/wiki/BackendPolling> 

Part of default.vcl

backend front1 {

  .host = "front1.domain.com";

  .port = "80";

  .probe = { .url = "/";

             .interval = 10s;

             .timeout = 5s;

             .window = 10;

             .threshold = 8;

 }

}

 

backend front2 {

  .host = "front2.domain.com";

  .port = "80";

  .probe = { .url = "/";

             .interval = 10s;

             .timeout = 5s;

             .window = 10;

             .threshold = 8;

 }

}

 

director b1 random

{

   { .backend = front1; .weight = 5; }

   { .backend = front2; .weight = 1; }

}

 

#director b1 round-robin {

#    { .backend = front1; }

#    { .backend = front2; }

#}

Thanks for your help...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100205/747963f1/attachment.html>

From rtshilston at gmail.com  Sun Feb  7 12:33:13 2010
From: rtshilston at gmail.com (Rob S)
Date: Sun, 07 Feb 2010 12:33:13 +0000
Subject: Varnish load balancer & (keep session)
In-Reply-To: <747761DAE0C78D44B79D05BD760F242101C15642@antares.novactive.local>
References: <747761DAE0C78D44B79D05BD760F242101C15642@antares.novactive.local>
Message-ID: <4B6EB309.40907@gmail.com>

Hi,

To answer some of your questions:

1) 503 error when shutting down a backend:  When you shutdown the 
backend, do you see varnishlog say that the backend is healthy or sick?  
If one is sick, then the other should get the traffic if your VCL 
contains set req.backend = b1;

2) Vanish load balanced does not keep e-commerce sessions for PHP.  The 
simplest solution to this is to install memcache, and put the following 
lines in your php.ini file:

[Session]
session.save_handler = memcached
session.save_path = "memcache-server1:11211,memcache-server2:11211"

instead of session.save_handler = files

However, I can't say for certain that this will definitely work - it 
depends on how your ecommerce application operates.

3) S-flag: I'm not sure about this, but my gut feeling is that it's not 
causing the problems you're seeing.



Rob


Axel DEAU wrote:
>
> Version: 2.0.6-1
>
> Insall: .deb
>
> Os: Debian 5.0.3
>
> Hi,
>
> I've got two backends running apache2: front1.domain.com & 
> front2.domain.com, set with the load balancing configuration 
> from http://varnish-cache.org/wiki/LoadBalancing.
>
> _The issue is, when I shutdown apache2 of the first backend varnish 
> don't switch to the second and display "Error 503 Service 
> Unavailable", is that a normal answer from varnish?_
>
> Other question, _does varnish load balancer keep php sessions, if yes 
> how will I do?_
>
> Varnishlog :
>
> 0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008 
> 0.039814 HTTP/1.1 200 OK
>
> 0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948 
> 0.066591 HTTP/1.1 200 OK
>
> The S flag is missing in my log, is that an issue?
>
> "4--X-S-RH" to notify that TCP socket shutdown succeeded 
> from http://varnish-cache.org/wiki/BackendPolling
>
> Part of default.vcl
>
> backend front1 {
>
>   .host = "front1.domain.com";
>
>   .port = "80";
>
>   .probe = { .url = "/";
>
>              .interval = 10s;
>
>              .timeout = 5s;
>
>              .window = 10;
>
>              .threshold = 8;
>
>  }
>
> }
>
>  
>
> backend front2 {
>
>   .host = "front2.domain.com";
>
>   .port = "80";
>
>   .probe = { .url = "/";
>
>              .interval = 10s;
>
>              .timeout = 5s;
>
>              .window = 10;
>
>              .threshold = 8;
>
>  }
>
> }
>
>  
>
> director b1 random
>
> {
>
>    { .backend = front1; .weight = 5; }
>
>    { .backend = front2; .weight = 1; }
>
> }
>
>  
>
> #director b1 round-robin {
>
> #    { .backend = front1; }
>
> #    { .backend = front2; }
>
> #}
>
> Thanks for your help...
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>   



From samcrawford at gmail.com  Sun Feb  7 13:28:34 2010
From: samcrawford at gmail.com (Sam Crawford)
Date: Sun, 7 Feb 2010 13:28:34 +0000
Subject: Varnish load balancer & (keep session)
In-Reply-To: <4B6EB309.40907@gmail.com>
References: <747761DAE0C78D44B79D05BD760F242101C15642@antares.novactive.local>
	<4B6EB309.40907@gmail.com>
Message-ID: <e4bd33301002070528l158f8684u500f54b5c837056f@mail.gmail.com>

Axel - Can I assume you have a single Varnish instance balancing over
the two Apache instances? If so, then another option would be to use
some kind of home-grown source IP stickyness to force connections from
one half of the Internet to one backend, and connections from the
other half to the other backend. I'm not sure if you'd need to dip
into C, but it should be possible to do something like "if (srcip % 2
== 0) { backend = b1; } else { backend = b2; }"

You can still support failover by calling checking the status of
backend.healthy, and change the backend to the alternative if the
preferred one is down.

Thanks,

Sam


On 7 February 2010 12:33, Rob S <rtshilston at gmail.com> wrote:
> Hi,
>
> To answer some of your questions:
>
> 1) 503 error when shutting down a backend: ?When you shutdown the
> backend, do you see varnishlog say that the backend is healthy or sick?
> If one is sick, then the other should get the traffic if your VCL
> contains set req.backend = b1;
>
> 2) Vanish load balanced does not keep e-commerce sessions for PHP. ?The
> simplest solution to this is to install memcache, and put the following
> lines in your php.ini file:
>
> [Session]
> session.save_handler = memcached
> session.save_path = "memcache-server1:11211,memcache-server2:11211"
>
> instead of session.save_handler = files
>
> However, I can't say for certain that this will definitely work - it
> depends on how your ecommerce application operates.
>
> 3) S-flag: I'm not sure about this, but my gut feeling is that it's not
> causing the problems you're seeing.
>
>
>
> Rob
>
>
> Axel DEAU wrote:
>>
>> Version: 2.0.6-1
>>
>> Insall: .deb
>>
>> Os: Debian 5.0.3
>>
>> Hi,
>>
>> I've got two backends running apache2: front1.domain.com &
>> front2.domain.com, set with the load balancing configuration
>> from http://varnish-cache.org/wiki/LoadBalancing.
>>
>> _The issue is, when I shutdown apache2 of the first backend varnish
>> don't switch to the second and display "Error 503 Service
>> Unavailable", is that a normal answer from varnish?_
>>
>> Other question, _does varnish load balancer keep php sessions, if yes
>> how will I do?_
>>
>> Varnishlog :
>>
>> 0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008
>> 0.039814 HTTP/1.1 200 OK
>>
>> 0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948
>> 0.066591 HTTP/1.1 200 OK
>>
>> The S flag is missing in my log, is that an issue?
>>
>> "4--X-S-RH" to notify that TCP socket shutdown succeeded
>> from http://varnish-cache.org/wiki/BackendPolling
>>
>> Part of default.vcl
>>
>> backend front1 {
>>
>> ? .host = "front1.domain.com";
>>
>> ? .port = "80";
>>
>> ? .probe = { .url = "/";
>>
>> ? ? ? ? ? ? ?.interval = 10s;
>>
>> ? ? ? ? ? ? ?.timeout = 5s;
>>
>> ? ? ? ? ? ? ?.window = 10;
>>
>> ? ? ? ? ? ? ?.threshold = 8;
>>
>> ?}
>>
>> }
>>
>>
>>
>> backend front2 {
>>
>> ? .host = "front2.domain.com";
>>
>> ? .port = "80";
>>
>> ? .probe = { .url = "/";
>>
>> ? ? ? ? ? ? ?.interval = 10s;
>>
>> ? ? ? ? ? ? ?.timeout = 5s;
>>
>> ? ? ? ? ? ? ?.window = 10;
>>
>> ? ? ? ? ? ? ?.threshold = 8;
>>
>> ?}
>>
>> }
>>
>>
>>
>> director b1 random
>>
>> {
>>
>> ? ?{ .backend = front1; .weight = 5; }
>>
>> ? ?{ .backend = front2; .weight = 1; }
>>
>> }
>>
>>
>>
>> #director b1 round-robin {
>>
>> # ? ?{ .backend = front1; }
>>
>> # ? ?{ .backend = front2; }
>>
>> #}
>>
>> Thanks for your help...
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From per.buer at redpill-linpro.com  Mon Feb  8 11:22:21 2010
From: per.buer at redpill-linpro.com (Per Andreas Buer)
Date: Mon, 8 Feb 2010 12:22:21 +0100 (CET)
Subject: Survey; how do you use Varnish?
In-Reply-To: <2049016219.110775.1265627806030.JavaMail.root@claudius.linpro.no>
Message-ID: <1323973730.110818.1265628141142.JavaMail.root@claudius.linpro.no>

Hi.

A short summary of what I've found. This was a rather superficial survey - I hope we can come back with a more thorough one after VUG2.

A typical varnish installation is either 2-4 dedicated servers or 10-20 servers running more or less the complete stack on every server. Only 2 out of 14 use ESI but three are planning to deploy ESI soon. I personally think ESI adoption is relatively high considering ESI is more or less a Varnish-only feature (few Akamai customers seem to use ESI because Akamai charges quite a lot extra for enabling it).

The most wanted feature is persistence and gzip, 9 points each. The hash director is also much asked about - 6 points. The DNS director is also (to me) surprisingly popular - I believe Kristian has an implementation of it for the 2.0 series so it shouldn't be to long a wait for this one. Better cookie handling is also a common request.

Varnish is used everywhere. No area of business stood out - maybe except "online media" which is quite an empty term since it covers a lot.

-- 
Per Andreas Buer
Redpill Linpro Group - Changing the Game

Mobile +47 958 39 117 / Phone: +47 21 54 41 21 


From tfheen at varnish-software.com  Mon Feb  8 11:40:47 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Mon, 08 Feb 2010 12:40:47 +0100
Subject: varnishlog not behaving as expected (by me)
In-Reply-To: <81569.1265198245@critter.freebsd.dk> (Poul-Henning Kamp's
	message of "Wed, 03 Feb 2010 11:57:25 +0000")
References: <81569.1265198245@critter.freebsd.dk>
Message-ID: <871vgwc5vk.fsf@qurzaw.linpro.no>

]] "Poul-Henning Kamp" 

| In message <4B6960DA.6080300 at bmjgroup.com>, Alex Hooper writes:
| 
| >>   /usr/local/bin/varnishlog -o RxURL "^wp-admin$"
| 
| This says you want to *O*mit all RxURL lines.  The regexp argument
| should have generated an argument error.

No, it doesn't:

     -o          Group log entries by request ID.  This has no effect when
                 writing to a file using the -w option.

The printing of non-client and non-backend lines is really a bug.
Please just file a ticket and we can get it fixed.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From tfheen at redpill-linpro.com  Mon Feb  8 07:29:29 2010
From: tfheen at redpill-linpro.com (Tollef Fog Heen)
Date: Mon, 08 Feb 2010 08:29:29 +0100
Subject: 503 Errors on POST
In-Reply-To: <4B637011.3010008@gmail.com> (Torrance's message of "Sat, 30 Jan
	2010 12:32:33 +1300")
References: <4B627C00.2040001@gmail.com> <87fx5p436q.fsf@qurzaw.linpro.no>
	<4B637011.3010008@gmail.com>
Message-ID: <87pr4gchie.fsf@qurzaw.linpro.no>

]] Torrance 

| I've pasted the logs of two failed requests below. As you can see,
| they're both in response to POST requests, though I was overstating the
| frequency at which these errors are occurring: they're occurring about
| 10% of the time.

>From looking at this, it might be that your backend is too slow.  We
have a default backend connection timeout of just 0.4 seconds.  Try
increasing that somewhat?  It's a bit surprising that should just hit
POST requests, though.  Alternatively, try with 2.0.6 since it'll have a
?FetchError? log entry when if fails.

| To be honest, I don't entirely understand the logs or their format, but
| I hope I've captured the important details. (Session IDs have been
| deleted, btw).

You have and the session entries are not important.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From naamab at answers.com  Sun Feb  7 15:20:19 2010
From: naamab at answers.com (Naama Bamberger)
Date: Sun, 7 Feb 2010 09:20:19 -0600
Subject: Error compiling VCL when using '% in regexp
Message-ID: <DD929CD9109B0A4D8C34B732A6D35CC43C34E274@MBX03.exg5.exghost.com>

I'm trying to handle bad requests sent to the servers, by eliminating problematic suffixes.
We had a lot of requests lately, ending by a percent sign and a single digit, that returned 503.

I tried adding this code to remove the 2 last characters of the URL, but the compilation fails.

                # If the URL ends with % and one digit (a broken hex value) - remove the last 2 characters.
                if (req.url ~ "(.*)%[0-9a-fA-F]$") {
                                set req.url = regsub(req.url, "(.*)%[0-9a-fA-F]$", "\1");
                }

I get this error:

Invalid hex char in %xx escape
(input Line 107 Pos 28)
        if (req.url ~ "(.*)%[0-9a-fA-F]$") {
---------------------------###--------------

I tried adding '\' before the '%' sign, with no success.

Thanks for your help,
Naama
Answers.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100207/8d677bd5/attachment.html>

From phk at phk.freebsd.dk  Mon Feb  8 10:44:28 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Feb 2010 10:44:28 +0000
Subject: varnishlog not behaving as expected (by me) 
In-Reply-To: Your message of "Mon, 08 Feb 2010 12:40:47 +0100."
	<871vgwc5vk.fsf@qurzaw.linpro.no> 
Message-ID: <55614.1265625868@critter.freebsd.dk>

In message <871vgwc5vk.fsf at qurzaw.linpro.no>, Tollef Fog Heen writes:
>]] "Poul-Henning Kamp" 
>
>| In message <4B6960DA.6080300 at bmjgroup.com>, Alex Hooper writes:
>| 
>| >>   /usr/local/bin/varnishlog -o RxURL "^wp-admin$"
>| 
>| This says you want to *O*mit all RxURL lines.  The regexp argument
>| should have generated an argument error.
>
>No, it doesn't:
>
>     -o          Group log entries by request ID.  This has no effect when
>                 writing to a file using the -w option.

I must have been sleepy, I thought of -x

sorry for the confusion.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Mon Feb  8 10:53:20 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Feb 2010 10:53:20 +0000
Subject: Error compiling VCL when using '% in regexp 
In-Reply-To: Your message of "Sun, 07 Feb 2010 09:20:19 CST."
	<DD929CD9109B0A4D8C34B732A6D35CC43C34E274@MBX03.exg5.exghost.com> 
Message-ID: <60459.1265626400@critter.freebsd.dk>

In message <DD929CD9109B0A4D8C34B732A6D35CC43C34E274 at MBX03.exg5.exghost.com>, N
aama Bamberger writes:

>I get this error:
>
>Invalid hex char in %xx escape
>(input Line 107 Pos 28)
>        if (req.url ~ "(.*)%[0-9a-fA-F]$") {
>---------------------------###--------------
>

Try: %25

One of the decisions I had most trouble with, was deciding which
kind of escape-mechanism we wanted for strings in VCL.

In the end I settled for URL-%xx encoding, because I pressume
webmasters know it, and because it avoids a nightmare of back-slashes
in regexps.

I'm not 100% convinced that was the perfect decision...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From rtshilston at gmail.com  Mon Feb  8 14:39:09 2010
From: rtshilston at gmail.com (Rob S)
Date: Mon, 08 Feb 2010 14:39:09 +0000
Subject: Varnish load balancer & (keep session)
In-Reply-To: <747761DAE0C78D44B79D05BD760F242101C1579A@antares.novactive.local>
References: <747761DAE0C78D44B79D05BD760F242101C15642@antares.novactive.local>
	<4B6EB309.40907@gmail.com>
	<747761DAE0C78D44B79D05BD760F242101C15751@antares.novactive.local>
	<4B6FD843.5030302@gmail.com>
	<747761DAE0C78D44B79D05BD760F242101C1575B@antares.novactive.local>
	<4B6FEC47.30108@gmail.com>
	<747761DAE0C78D44B79D05BD760F242101C1579A@antares.novactive.local>
Message-ID: <4B70220D.1060507@gmail.com>

Just to copy in the list... the problem Axel was seeing is one that 
troubled us for a bit - getting unexpected 503 responses.

Solution: Make sure the top of "sub vcl_recv" has a default backend:

set req.backend = xxx;

You can override this later with conditional statements, or whatever, 
but having a default helps prevent 503s.


Rob


Axel DEAU wrote:
> Hi,
>
> It seems that with this method it works very well I thanks you a lot for your help and wich you have a nice day
>
> Best regard
>
> Axel DEAU | NOVACTIVE SYTEME
>
> Administrateur Systeme et Reseaux
> mail : a.deau at novactive-systemes.com
> Tel : + 33 1 48 24 33 60
> Fax : + 33 1 48 24 33 54
> www.novactive.com
>
>
> -----Message d'origine-----
> De : Rob S [mailto:rtshilston at gmail.com] 
> Envoy? : lundi 8 f?vrier 2010 11:50
> ? : Axel DEAU
> Cc : Sacha MILADINOVIC
> Objet : Re: Varnish load balancer & (keep session)
>
> At the very top of "sub vcl_recv", please add:
>
> set req.backend = b1;
>
> This will set the default backend.
>
> Can you also send me the output of
>
> # varnishlog |grep Backend_health
>     0 Backend_health - server7 Still healthy 4--X-S-RH 10 8 10 0.007498 
> 0.009539 HTTP/1.1 200 OK
>     0 Backend_health - server2 Still healthy 4--X-S-RH 10 8 10 0.006767 
> 0.013814 HTTP/1.1 200 OK
>     0 Backend_health - server3 Still healthy 4--X-S-RH 10 8 10 0.012027 
> 0.010841 HTTP/1.1 200 OK
>
> from before and after you stop apache on the first and second backends.
>
>
> Rob
>
>
> Axel DEAU wrote:
>   
>> Hi,
>>
>> Absolutely
>>
>> Axel DEAU | NOVACTIVE SYTEME
>>
>> Administrateur Systeme et Reseaux
>> mail : a.deau at novactive-systemes.com
>> Tel : + 33 1 48 24 33 60
>> Fax : + 33 1 48 24 33 54
>> www.novactive.com
>>
>>
>> -----Message d'origine-----
>> De : Rob S [mailto:rtshilston at gmail.com] 
>> Envoy? : lundi 8 f?vrier 2010 10:24
>> ? : Axel DEAU
>> Cc : Sacha MILADINOVIC
>> Objet : Re: Varnish load balancer & (keep session)
>>
>> Axel,
>>
>> Can you post your entire VCL, and I'll see why this is happening.
>>
>> Rob
>>
>> Axel DEAU wrote:
>>   
>>     
>>> Hi Rob,
>>>
>>> Thanks for the reply, for 1) when I shut down the second backend all the traffic goes to the first backend but,
>>> When I shut down the first backend even if the second backend mark "Still healthy" the error 503 appears.
>>>
>>> For the other point I'm agreed with you...
>>>
>>> -----Message d'origine-----
>>> De : Rob S [mailto:rtshilston at gmail.com] 
>>> Envoy? : dimanche 7 f?vrier 2010 13:33
>>> ? : Axel DEAU
>>> Cc : varnish-misc at projects.linpro.no
>>> Objet : Re: Varnish load balancer & (keep session)
>>>
>>> Hi,
>>>
>>> To answer some of your questions:
>>>
>>> 1) 503 error when shutting down a backend:  When you shutdown the 
>>> backend, do you see varnishlog say that the backend is healthy or sick?  
>>> If one is sick, then the other should get the traffic if your VCL 
>>> contains set req.backend = b1;
>>>
>>> 2) Vanish load balanced does not keep e-commerce sessions for PHP.  The 
>>> simplest solution to this is to install memcache, and put the following 
>>> lines in your php.ini file:
>>>
>>> [Session]
>>> session.save_handler = memcached
>>> session.save_path = "memcache-server1:11211,memcache-server2:11211"
>>>
>>> instead of session.save_handler = files
>>>
>>> However, I can't say for certain that this will definitely work - it 
>>> depends on how your ecommerce application operates.
>>>
>>> 3) S-flag: I'm not sure about this, but my gut feeling is that it's not 
>>> causing the problems you're seeing.
>>>
>>>
>>>
>>> Rob
>>>
>>>
>>> Axel DEAU wrote:
>>>   
>>>     
>>>       
>>>> Version: 2.0.6-1
>>>>
>>>> Insall: .deb
>>>>
>>>> Os: Debian 5.0.3
>>>>
>>>> Hi,
>>>>
>>>> I've got two backends running apache2: front1.domain.com & 
>>>> front2.domain.com, set with the load balancing configuration 
>>>> from http://varnish-cache.org/wiki/LoadBalancing.
>>>>
>>>> _The issue is, when I shutdown apache2 of the first backend varnish 
>>>> don't switch to the second and display "Error 503 Service 
>>>> Unavailable", is that a normal answer from varnish?_
>>>>
>>>> Other question, _does varnish load balancer keep php sessions, if yes 
>>>> how will I do?_
>>>>
>>>> Varnishlog :
>>>>
>>>> 0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008 
>>>> 0.039814 HTTP/1.1 200 OK
>>>>
>>>> 0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948 
>>>> 0.066591 HTTP/1.1 200 OK
>>>>
>>>> The S flag is missing in my log, is that an issue?
>>>>
>>>> "4--X-S-RH" to notify that TCP socket shutdown succeeded 
>>>> from http://varnish-cache.org/wiki/BackendPolling
>>>>
>>>> Part of default.vcl
>>>>
>>>> backend front1 {
>>>>
>>>>   .host = "front1.domain.com";
>>>>
>>>>   .port = "80";
>>>>
>>>>   .probe = { .url = "/";
>>>>
>>>>              .interval = 10s;
>>>>
>>>>              .timeout = 5s;
>>>>
>>>>              .window = 10;
>>>>
>>>>              .threshold = 8;
>>>>
>>>>  }
>>>>
>>>> }
>>>>
>>>>  
>>>>
>>>> backend front2 {
>>>>
>>>>   .host = "front2.domain.com";
>>>>
>>>>   .port = "80";
>>>>
>>>>   .probe = { .url = "/";
>>>>
>>>>              .interval = 10s;
>>>>
>>>>              .timeout = 5s;
>>>>
>>>>              .window = 10;
>>>>
>>>>              .threshold = 8;
>>>>
>>>>  }
>>>>
>>>> }
>>>>
>>>>  
>>>>
>>>> director b1 random
>>>>
>>>> {
>>>>
>>>>    { .backend = front1; .weight = 5; }
>>>>
>>>>    { .backend = front2; .weight = 1; }
>>>>
>>>> }
>>>>
>>>>  
>>>>
>>>> #director b1 round-robin {
>>>>
>>>> #    { .backend = front1; }
>>>>
>>>> #    { .backend = front2; }
>>>>
>>>> #}
>>>>
>>>> Thanks for your help...
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> varnish-misc mailing list
>>>> varnish-misc at projects.linpro.no
>>>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>>>>   
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>   
>>     
>
>   



From r at roze.lv  Mon Feb  8 15:12:09 2010
From: r at roze.lv (Reinis Rozitis)
Date: Mon, 8 Feb 2010 17:12:09 +0200
Subject: Varnish load balancer & (keep session)
References: <747761DAE0C78D44B79D05BD760F242101C15642@antares.novactive.local><4B6EB309.40907@gmail.com><747761DAE0C78D44B79D05BD760F242101C15751@antares.novactive.local><4B6FD843.5030302@gmail.com><747761DAE0C78D44B79D05BD760F242101C1575B@antares.novactive.local><4B6FEC47.30108@gmail.com><747761DAE0C78D44B79D05BD760F242101C1579A@antares.novactive.local>
	<4B70220D.1060507@gmail.com>
Message-ID: <1E428E50623545E68F868E82E9A5506B@KD5>

While this might be somewhat "hammering" backends (in case something goes totally wrong) we have ironed out a lot (if not all) 503 
errors just by rerequesting the objects (in our case usually a static image) which get the 503 response by adding this:

sub vcl_error {
        if (obj.status == 503 && req.restarts < 4) {
                restart;
        }
}



rr


----- Original Message ----- 
From: "Rob S"

> Just to copy in the list... the problem Axel was seeing is one that
> troubled us for a bit - getting unexpected 503 responses.
>
> Solution: Make sure the top of "sub vcl_recv" has a default backend:
>
> set req.backend = xxx;
>
> You can override this later with conditional statements, or whatever,
> but having a default helps prevent 503s.
>
>
> Rob
>
>
> Axel DEAU wrote:
>> Hi,
>>
>> It seems that with this method it works very well I thanks you a lot for your help and wich you have a nice day
>>
>> Best regard
>>
>> Axel DEAU | NOVACTIVE SYTEME
>>
>> Administrateur Systeme et Reseaux
>> mail : a.deau at novactive-systemes.com
>> Tel : + 33 1 48 24 33 60
>> Fax : + 33 1 48 24 33 54
>> www.novactive.com
>>
>>
>> -----Message d'origine-----
>> De : Rob S [mailto:rtshilston at gmail.com]
>> Envoy? : lundi 8 f?vrier 2010 11:50
>> ? : Axel DEAU
>> Cc : Sacha MILADINOVIC
>> Objet : Re: Varnish load balancer & (keep session)
>>
>> At the very top of "sub vcl_recv", please add:
>>
>> set req.backend = b1;
>>
>> This will set the default backend.
>>
>> Can you also send me the output of
>>
>> # varnishlog |grep Backend_health
>>     0 Backend_health - server7 Still healthy 4--X-S-RH 10 8 10 0.007498
>> 0.009539 HTTP/1.1 200 OK
>>     0 Backend_health - server2 Still healthy 4--X-S-RH 10 8 10 0.006767
>> 0.013814 HTTP/1.1 200 OK
>>     0 Backend_health - server3 Still healthy 4--X-S-RH 10 8 10 0.012027
>> 0.010841 HTTP/1.1 200 OK
>>
>> from before and after you stop apache on the first and second backends.
>>
>>
>> Rob
>>
>>
>> Axel DEAU wrote:
>>
>>> Hi,
>>>
>>> Absolutely
>>>
>>> Axel DEAU | NOVACTIVE SYTEME
>>>
>>> Administrateur Systeme et Reseaux
>>> mail : a.deau at novactive-systemes.com
>>> Tel : + 33 1 48 24 33 60
>>> Fax : + 33 1 48 24 33 54
>>> www.novactive.com
>>>
>>>
>>> -----Message d'origine-----
>>> De : Rob S [mailto:rtshilston at gmail.com]
>>> Envoy? : lundi 8 f?vrier 2010 10:24
>>> ? : Axel DEAU
>>> Cc : Sacha MILADINOVIC
>>> Objet : Re: Varnish load balancer & (keep session)
>>>
>>> Axel,
>>>
>>> Can you post your entire VCL, and I'll see why this is happening.
>>>
>>> Rob
>>>
>>> Axel DEAU wrote:
>>>
>>>
>>>> Hi Rob,
>>>>
>>>> Thanks for the reply, for 1) when I shut down the second backend all the traffic goes to the first backend but,
>>>> When I shut down the first backend even if the second backend mark "Still healthy" the error 503 appears.
>>>>
>>>> For the other point I'm agreed with you...
>>>>
>>>> -----Message d'origine-----
>>>> De : Rob S [mailto:rtshilston at gmail.com]
>>>> Envoy? : dimanche 7 f?vrier 2010 13:33
>>>> ? : Axel DEAU
>>>> Cc : varnish-misc at projects.linpro.no
>>>> Objet : Re: Varnish load balancer & (keep session)
>>>>
>>>> Hi,
>>>>
>>>> To answer some of your questions:
>>>>
>>>> 1) 503 error when shutting down a backend:  When you shutdown the
>>>> backend, do you see varnishlog say that the backend is healthy or sick?
>>>> If one is sick, then the other should get the traffic if your VCL
>>>> contains set req.backend = b1;
>>>>
>>>> 2) Vanish load balanced does not keep e-commerce sessions for PHP.  The
>>>> simplest solution to this is to install memcache, and put the following
>>>> lines in your php.ini file:
>>>>
>>>> [Session]
>>>> session.save_handler = memcached
>>>> session.save_path = "memcache-server1:11211,memcache-server2:11211"
>>>>
>>>> instead of session.save_handler = files
>>>>
>>>> However, I can't say for certain that this will definitely work - it
>>>> depends on how your ecommerce application operates.
>>>>
>>>> 3) S-flag: I'm not sure about this, but my gut feeling is that it's not
>>>> causing the problems you're seeing.
>>>>
>>>>
>>>>
>>>> Rob
>>>>
>>>>
>>>> Axel DEAU wrote:
>>>>
>>>>
>>>>
>>>>> Version: 2.0.6-1
>>>>>
>>>>> Insall: .deb
>>>>>
>>>>> Os: Debian 5.0.3
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've got two backends running apache2: front1.domain.com &
>>>>> front2.domain.com, set with the load balancing configuration
>>>>> from http://varnish-cache.org/wiki/LoadBalancing.
>>>>>
>>>>> _The issue is, when I shutdown apache2 of the first backend varnish
>>>>> don't switch to the second and display "Error 503 Service
>>>>> Unavailable", is that a normal answer from varnish?_
>>>>>
>>>>> Other question, _does varnish load balancer keep php sessions, if yes
>>>>> how will I do?_
>>>>>
>>>>> Varnishlog :
>>>>>
>>>>> 0 Backend_health - front1 Still healthy 4--X-RH 10 8 10 0.040008
>>>>> 0.039814 HTTP/1.1 200 OK
>>>>>
>>>>> 0 Backend_health - front2 Still healthy 4--X-RH 10 8 10 0.066948
>>>>> 0.066591 HTTP/1.1 200 OK
>>>>>
>>>>> The S flag is missing in my log, is that an issue?
>>>>>
>>>>> "4--X-S-RH" to notify that TCP socket shutdown succeeded
>>>>> from http://varnish-cache.org/wiki/BackendPolling
>>>>>
>>>>> Part of default.vcl
>>>>>
>>>>> backend front1 {
>>>>>
>>>>>   .host = "front1.domain.com";
>>>>>
>>>>>   .port = "80";
>>>>>
>>>>>   .probe = { .url = "/";
>>>>>
>>>>>              .interval = 10s;
>>>>>
>>>>>              .timeout = 5s;
>>>>>
>>>>>              .window = 10;
>>>>>
>>>>>              .threshold = 8;
>>>>>
>>>>>  }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> backend front2 {
>>>>>
>>>>>   .host = "front2.domain.com";
>>>>>
>>>>>   .port = "80";
>>>>>
>>>>>   .probe = { .url = "/";
>>>>>
>>>>>              .interval = 10s;
>>>>>
>>>>>              .timeout = 5s;
>>>>>
>>>>>              .window = 10;
>>>>>
>>>>>              .threshold = 8;
>>>>>
>>>>>  }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> director b1 random
>>>>>
>>>>> {
>>>>>
>>>>>    { .backend = front1; .weight = 5; }
>>>>>
>>>>>    { .backend = front2; .weight = 1; }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> #director b1 round-robin {
>>>>>
>>>>> #    { .backend = front1; }
>>>>>
>>>>> #    { .backend = front2; }
>>>>>
>>>>> #}
>>>>>
>>>>> Thanks for your help...
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> varnish-misc mailing list
>>>>> varnish-misc at projects.linpro.no
>>>>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
> 



From moseleymark at gmail.com  Mon Feb  8 20:18:59 2010
From: moseleymark at gmail.com (Mark Moseley)
Date: Mon, 8 Feb 2010 12:18:59 -0800
Subject: Survey; how do you use Varnish?
In-Reply-To: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
References: <1972754207.83637.1264776184796.JavaMail.root@claudius.linpro.no>
	<630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no>
Message-ID: <294d5daa1002081218ke7bb140of43f5207718f7f75@mail.gmail.com>

Sorry for the late reply.

1) About 200 servers

2) Averages 2500 hits/sec over the day, approx 35% hit ratio (which is
awesome for web hosting)

3) Web hosting

4) No

5)
#1 Allow for 304 revalidation of cache content.
#2 There was an earlier reply that mentioned automatic revalidation
for warm content, i.e. after the TTL expires, leave content in cache
if it hasn't changed till some amount of time has passed. Obviously
implies #1
#3 Similarly to #2, if unallocated memory is under a certain
threshold, allow stale content to live indefinitely, which also
implies #1


From lstroobant at gmail.com  Mon Feb  8 20:24:52 2010
From: lstroobant at gmail.com (Luc Stroobant)
Date: Mon, 08 Feb 2010 21:24:52 +0100
Subject: obj.cacheable vs expires headers?
In-Reply-To: <20100201233703.GA29694@motogp.com>
References: <4B673CD2.7070807@gmail.com> <20100201233703.GA29694@motogp.com>
Message-ID: <4B707314.5090205@gmail.com>

Hello,

Antoni Villalonga wrote:

> It's seems to be correct. Be careful with cacheable and ttl=0 answers.
> 
> Some simple debuging:
> sub vcl_fetch {
> 	# Varnish determined the object was not cacheable
> 	if (!obj.cacheable) {
> 		set obj.http.X-Cacheable = "No";
> 	} elsif (obj.ttl > 0s) {
> 		set obj.http.X-Cacheable = "Yes";
> 	} else {
> 		set obj.http.X-Cacheable = "Yes: ttl=0";
> 	}
> 	[...]
> }

Thanks for your reply. I enabled the extra debugging on a test-instance, 
like you proposed.
obj.ttl seems to be zero indeed, but I still don't get how his would 
make the request cacheable. At least it's not the behaviour one would 
expect?
Secondly: I also thought that Varnish never caches requests with a 
Set-cookie header?
Or is it just the header that causes problems with intermediate proxies 
between our server and the users (and/or browser cache of the clients)?

Request sent through Varnish:
HTTP/1.1 200 OK
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.12
Set-Cookie: SESSbc5f9ce1c97eee1824d1ab670ce3057b14; expires=Wed, 03-Mar-
2010 23:24:42 GMT; path=/; domain=removed
Last-Modified: Mon, 08 Feb 2010 19:49:49 GMT
ETag: "8060981009417cf0496649018d6535fa"
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Content-Length: 12955
X-Cacheable: Yes: ttl=0
cache-control: max-age = 900
Date: Mon, 08 Feb 2010 19:51:22 GMT
X-Varnish: 1349734797
Via: 1.1 varnish
Connection: close
age: 0


Direct request:
HTTP/1.1 200 OK
Date: Mon, 08 Feb 2010 19:53:56 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.12
Set-Cookie: SESSbc5f9ce1c97eee1824d1ab670ebj735pffubr1e86; expires=Wed, 
03-Mar-2010 23:27:16 GMT; path=/; domain=removed
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Mon, 08 Feb 2010 19:53:56 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Connection: close
Content-Type: text/html; charset=utf-8

If this is wanted behaviour, I would propose to add a warning on 
http://varnish-cache.org/wiki/VCLExampleLongerCaching
The config can cause serious privacy problems and other weird things on 
sites with logged in users.

Luc


From phk at phk.freebsd.dk  Mon Feb  8 19:29:19 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Feb 2010 19:29:19 +0000
Subject: obj.cacheable vs expires headers? 
In-Reply-To: Your message of "Mon, 08 Feb 2010 21:24:52 +0100."
	<4B707314.5090205@gmail.com> 
Message-ID: <11702.1265657359@critter.freebsd.dk>

In message <4B707314.5090205 at gmail.com>, Luc Stroobant writes:

>obj.ttl seems to be zero indeed, but I still don't get how his would 
>make the request cacheable. At least it's not the behaviour one would 
>expect?

We distinguish between "can be cached" and "how long should it be cached"
because they are very different questions.

"can be cached" is a matter of correctness, whereas "how long" is 
just a performance issue.

>Secondly: I also thought that Varnish never caches requests with a 
>Set-cookie header?

Varnish has a special kind of cache entries called "hit-for-pass".
This is a cache entry that says that the object can not be cached,
that solves a pile-up issue on busy objects.

The fact that you see zero TTL, can be indicative of the clock on
the varnish-host and the clock on the backend not agreeing what
time it is.  Check your ntpd.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From lstroobant at gmail.com  Mon Feb  8 20:39:28 2010
From: lstroobant at gmail.com (Luc Stroobant)
Date: Mon, 08 Feb 2010 21:39:28 +0100
Subject: obj.cacheable vs expires headers?
In-Reply-To: <11702.1265657359@critter.freebsd.dk>
References: <11702.1265657359@critter.freebsd.dk>
Message-ID: <4B707680.6020205@gmail.com>

Poul-Henning Kamp wrote:
> In message <4B707314.5090205 at gmail.com>, Luc Stroobant writes:
> 
>> obj.ttl seems to be zero indeed, but I still don't get how his would 
>> make the request cacheable. At least it's not the behaviour one would 
>> expect?
> 
> We distinguish between "can be cached" and "how long should it be cached"
> because they are very different questions.
> 
> "can be cached" is a matter of correctness, whereas "how long" is 
> just a performance issue.

So you mean: the object /can/ be cached, but it would only be cached for 
zero seconds?

>> Secondly: I also thought that Varnish never caches requests with a 
>> Set-cookie header?
> 
> Varnish has a special kind of cache entries called "hit-for-pass".
> This is a cache entry that says that the object can not be cached,
> that solves a pile-up issue on busy objects.
> 
> The fact that you see zero TTL, can be indicative of the clock on
> the varnish-host and the clock on the backend not agreeing what
> time it is.  Check your ntpd.

I don't think it's a clock issue. Varnish and the webserver are running 
on the same host. We wanted to use Varnish to cache some static files on 
an overloaded prefork Apache + mod-php (and it did a great job, till we 
started to see weird session issues).

Luc


From phk at phk.freebsd.dk  Mon Feb  8 19:55:41 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Feb 2010 19:55:41 +0000
Subject: obj.cacheable vs expires headers? 
In-Reply-To: Your message of "Mon, 08 Feb 2010 21:39:28 +0100."
	<4B707680.6020205@gmail.com> 
Message-ID: <27641.1265658941@critter.freebsd.dk>

In message <4B707680.6020205 at gmail.com>, Luc Stroobant writes:
>Poul-Henning Kamp wrote:

>> "can be cached" is a matter of correctness, whereas "how long" is 
>> just a performance issue.
>
>So you mean: the object /can/ be cached, but it would only be cached for 
>zero seconds?

Yes, that is a valid, but silly configuration.

>I don't think it's a clock issue. Varnish and the webserver are running 
>on the same host. We wanted to use Varnish to cache some static files on 
>an overloaded prefork Apache + mod-php (and it did a great job, till we 
>started to see weird session issues).

Ok, no, it's not a clock issue then.

Check your varnishlog output, it shows all headers sent/received
and look for what cache-control the backend gives varnish...

Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From lstroobant at gmail.com  Mon Feb  8 21:38:49 2010
From: lstroobant at gmail.com (Luc Stroobant)
Date: Mon, 08 Feb 2010 22:38:49 +0100
Subject: obj.cacheable vs expires headers?
In-Reply-To: <27641.1265658941@critter.freebsd.dk>
References: <27641.1265658941@critter.freebsd.dk>
Message-ID: <4B708469.9070708@gmail.com>

Poul-Henning Kamp wrote:

> Check your varnishlog output, it shows all headers sent/received
> and look for what cache-control the backend gives varnish...

The cache-control headers of the backend seem to be ok?
(btw, the Varnish test-instance is running on my laptop, but the 
behaviour is exactly the same as it was on the production server)

Luc

First request:

     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664137 1.0
     8 SessionOpen  c 127.0.0.1 48239 127.0.0.1:80
     8 ReqStart     c 127.0.0.1 48239 858012427
     8 RxRequest    c GET
     8 RxURL        c /
     8 RxProtocol   c HTTP/1.0
     8 RxHeader     c Host: www.removed
     8 RxHeader     c Accept: text/html, text/plain, text/css, 
text/sgml, */*;q=0.01
     8 RxHeader     c Accept-Encoding: gzip, compress, bzip2
     8 RxHeader     c Accept-Language: en
     8 RxHeader     c User-Agent: Lynx/2.8.7pre.6 libwww-FM/2.14 
SSL-MM/1.4.1
     8 VCL_call     c recv
     8 VCL_return   c lookup
     8 VCL_call     c hash
     8 VCL_return   c hash
     8 VCL_call     c miss
     8 VCL_return   c fetch
     9 BackendOpen  b default 192.168.1.13 41812 <remote ip> 80
     8 Backend      c 9 default default
     9 TxRequest    b GET
     9 TxURL        b /
     9 TxProtocol   b HTTP/1.1
     9 TxHeader     b Host: www.removed
     9 TxHeader     b Accept: text/html, text/plain, text/css, 
text/sgml, */*;q=0.01
     9 TxHeader     b Accept-Encoding: gzip, compress, bzip2
     9 TxHeader     b Accept-Language: en
     9 TxHeader     b User-Agent: Lynx/2.8.7pre.6 libwww-FM/2.14 
SSL-MM/1.4.1
     9 TxHeader     b X-Forwarded-For: 127.0.0.1
     9 TxHeader     b X-Varnish: 858012427
     9 TxHeader     b X-Forwarded-For: 127.0.0.1
     9 RxProtocol   b HTTP/1.1
     9 RxStatus     b 200
     9 RxResponse   b OK
     9 RxHeader     b Date: Mon, 08 Feb 2010 21:22:19 GMT
     9 RxHeader     b Server: Apache/2.2.3 (CentOS)
     9 RxHeader     b X-Powered-By: PHP/5.2.12
     9 RxHeader     b Set-Cookie: 
SESSbc5f9ce1c97eee1824d1ab670ce3057b=aar9ormanugvueruqlpr327ka5; 
expires=Thu, 04-Mar-2010 00:55:39 GMT; path=/; domain=.removed
     9 RxHeader     b Last-Modified: Mon, 08 Feb 2010 21:19:29 GMT
     9 RxHeader     b ETag: "8f386ae81f34f492ba4abde82d8ef425"
     9 RxHeader     b Expires: Sun, 19 Nov 1978 05:00:00 GMT
     9 RxHeader     b Cache-Control: must-revalidate
     9 RxHeader     b Content-Encoding: gzip
     9 RxHeader     b Transfer-Encoding: chunked
     9 RxHeader     b Content-Type: text/html; charset=utf-8
     8 ObjProtocol  c HTTP/1.1
     8 ObjStatus    c 200
     8 ObjResponse  c OK
     8 ObjHeader    c Date: Mon, 08 Feb 2010 21:22:19 GMT
     8 ObjHeader    c Server: Apache/2.2.3 (CentOS)
     8 ObjHeader    c X-Powered-By: PHP/5.2.12
     8 ObjHeader    c Set-Cookie: 
SESSbc5f9ce1c97eee1824d1ab670ce3057b=aar9ormanugvueruqlpr327ka5; 
expires=Thu, 04-Mar-2010 00:55:39 GMT; path=/; domain=.removed
     8 ObjHeader    c Last-Modified: Mon, 08 Feb 2010 21:19:29 GMT
     8 ObjHeader    c ETag: "8f386ae81f34f492ba4abde82d8ef425"
     8 ObjHeader    c Expires: Sun, 19 Nov 1978 05:00:00 GMT
     8 ObjHeader    c Cache-Control: must-revalidate
     8 ObjHeader    c Content-Encoding: gzip
     8 ObjHeader    c Content-Type: text/html; charset=utf-8
     9 BackendReuse b default
     8 TTL          c 858012427 RFC 0 1265664139 1265664139 280299600 0 0
     8 VCL_call     c fetch
     8 TTL          c 858012427 VCL 1209600 1265664139
     8 VCL_return   c deliver
     8 Length       c 10987
     8 VCL_call     c deliver
     8 VCL_return   c deliver
     8 TxProtocol   c HTTP/1.1
     8 TxStatus     c 200
     8 TxResponse   c OK
     8 TxHeader     c Server: Apache/2.2.3 (CentOS)
     8 TxHeader     c X-Powered-By: PHP/5.2.12
     8 TxHeader     c Set-Cookie: 
SESSbc5f9ce1c97eee1824d1ab670ce3057b=aar9ormanugvueruqlpr327ka5; 
expires=Thu, 04-Mar-2010 00:55:39 GMT; path=/; domain=.removed
     8 TxHeader     c Last-Modified: Mon, 08 Feb 2010 21:19:29 GMT
     8 TxHeader     c ETag: "8f386ae81f34f492ba4abde82d8ef425"
     8 TxHeader     c Content-Encoding: gzip
     8 TxHeader     c Content-Type: text/html; charset=utf-8
     8 TxHeader     c Content-Length: 10987
     8 TxHeader     c X-Cacheable: Yes: ttl=0
     8 TxHeader     c cache-control: max-age = 900
     8 TxHeader     c Date: Mon, 08 Feb 2010 21:22:19 GMT
     8 TxHeader     c X-Varnish: 858012427
     8 TxHeader     c Via: 1.1 varnish
     8 TxHeader     c Connection: close
     8 TxHeader     c age: 0
     8 ReqEnd       c 858012427 1265664139.376405954 
1265664139.577864408 0.000237465 0.201274157 0.000184298
     8 SessionClose c not HTTP/1.1
     8 StatSess     c 127.0.0.1 48239 0 1 1 0 0 1 556 10987
     0 StatAddr     - 127.0.0.1 0 0 1 1 0 0 1 556 10987
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664140 1.0

A second request:

     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664528 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664531 1.0
     8 SessionOpen  c 127.0.0.1 36366 127.0.0.1:80
     8 ReqStart     c 127.0.0.1 36366 858012428
     8 RxRequest    c GET
     8 RxURL        c /
     8 RxProtocol   c HTTP/1.0
     8 RxHeader     c Host: removed
     8 RxHeader     c Accept: text/html, text/plain, text/css, 
text/sgml, */*;q=0.01
     8 RxHeader     c Accept-Encoding: gzip, compress, bzip2
     8 RxHeader     c Accept-Language: en
     8 RxHeader     c User-Agent: Lynx/2.8.7pre.6 libwww-FM/2.14 
SSL-MM/1.4.1
     8 VCL_call     c recv
     8 VCL_return   c lookup
     8 VCL_call     c hash
     8 VCL_return   c hash
     8 Hit          c 858012427
     8 VCL_call     c hit
     8 VCL_return   c deliver
     8 Length       c 10987
     8 VCL_call     c deliver
     8 VCL_return   c deliver
     8 TxProtocol   c HTTP/1.1
     8 TxStatus     c 200
     8 TxResponse   c OK
     8 TxHeader     c Server: Apache/2.2.3 (CentOS)
     8 TxHeader     c X-Powered-By: PHP/5.2.12
     8 TxHeader     c Set-Cookie: 
SESSbc5f9ce1c97eee1824d1ab670ce3057b=aar9ormanugvueruqlpr327ka5; 
expires=Thu, 04-Mar-2010 00:55:39 GMT; path=/; domain=.removed
     8 TxHeader     c Last-Modified: Mon, 08 Feb 2010 21:19:29 GMT
     8 TxHeader     c ETag: "8f386ae81f34f492ba4abde82d8ef425"
     8 TxHeader     c Content-Encoding: gzip
     8 TxHeader     c Content-Type: text/html; charset=utf-8
     8 TxHeader     c Content-Length: 10987
     8 TxHeader     c X-Cacheable: Yes: ttl=0
     8 TxHeader     c cache-control: max-age = 900
     8 TxHeader     c Date: Mon, 08 Feb 2010 21:28:51 GMT
     8 TxHeader     c X-Varnish: 858012428 858012427
     8 TxHeader     c Via: 1.1 varnish
     8 TxHeader     c Connection: close
     8 TxHeader     c age: 0
     8 ReqEnd       c 858012428 1265664531.629857302 
1265664531.629952192 0.000370026 0.000051498 0.000043392
     8 SessionClose c not HTTP/1.1
     8 StatSess     c 127.0.0.1 36366 0 1 1 0 0 0 566 10987
     0 StatAddr     - 127.0.0.1 0 392 2 2 0 0 1 1122 21974
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664534 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664537 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1265664540 1.0


From phk at phk.freebsd.dk  Mon Feb  8 20:43:34 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 08 Feb 2010 20:43:34 +0000
Subject: obj.cacheable vs expires headers? 
In-Reply-To: Your message of "Mon, 08 Feb 2010 22:38:49 +0100."
	<4B708469.9070708@gmail.com> 
Message-ID: <30711.1265661814@critter.freebsd.dk>

In message <4B708469.9070708 at gmail.com>, Luc Stroobant writes:
>Poul-Henning Kamp wrote:
>
>> Check your varnishlog output, it shows all headers sent/received
>> and look for what cache-control the backend gives varnish...
>
>The cache-control headers of the backend seem to be ok?
>(btw, the Varnish test-instance is running on my laptop, but the 
>behaviour is exactly the same as it was on the production server)

>     9 RxHeader     b Expires: Sun, 19 Nov 1978 05:00:00 GMT

This is your problem: the backend says that the object is already
expired, so obviously we cannot cache it for any amount of time.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From lstroobant at gmail.com  Tue Feb  9 10:05:50 2010
From: lstroobant at gmail.com (lstroobant at gmail.com)
Date: Tue, 9 Feb 2010 11:05:50 +0100 (GMT+01:00)
Subject: obj.cacheable vs expires headers?
In-Reply-To: <14787165.281265709826744.JavaMail.luc@syntop>
Message-ID: <15261481.301265709947078.JavaMail.luc@syntop>


----- "Poul-Henning Kamp" <phk at phk.freebsd.dk> wrote:

> >     9 RxHeader     b Expires: Sun, 19 Nov 1978 05:00:00 GMT
> 
> This is your problem: the backend says that the object is already
> expired, so obviously we cannot cache it for any amount of time.

I'm not sure we're still talking about the same problem. :-)
Just to be sure: we don't want to cache that dynamic page, but I'm wondering why (with those) headers, it's still seen as obj.cacheable by Varnish. If you check the log of the second request in my previous mail, you even see a message "   8 VCL_call     c hit" which seems to suggest the object is served from cache?
(cache-control: max-age = 900 is also set)

Luc


From marc.fournier at camptocamp.com  Tue Feb  9 13:22:06 2010
From: marc.fournier at camptocamp.com (Marc Fournier)
Date: Tue, 9 Feb 2010 14:22:06 +0100
Subject: varnish & amazon S3 private buckets
Message-ID: <20100209142206.12626ee4@lonquimay.wrk.lsn.camptocamp.com>

Hello,

Did anyone already try to use amazon's S3 service as a backend and serve
content from private buckets ?

Basically this means having a calculated hash added to the headers
which get sent to the backend server [1].

A guy recently implemented this for nginx's proxy module[2], so I
wondered if it would make sense to have this sort of facility in
varnish too ?

Or maybe is it more the sort of thing which would belong to a C{...}C
block in VCL ?

Marc

[1] http://docs.amazonwebservices.com/AmazonS3/latest/API/RESTServiceGET.html
[2] http://nginx.org/pipermail/nginx/2010-February/018583.html



From bernard at frit.net  Tue Feb  9 13:55:22 2010
From: bernard at frit.net (Bernardf FRIT)
Date: Tue, 09 Feb 2010 14:55:22 +0100
Subject: GRSEC and Varnish (FIXED)
In-Reply-To: <294d5daa1002041010l502a92b7n9d8bf6ec514b574c@mail.gmail.com>
References: <4B684870.9070503@frit.net> <874olylppy.fsf@qurzaw.linpro.no>	
	<294d5daa1002031610p701686c9sa46f7f24aeca49fb@mail.gmail.com>	
	<4B6AEEE3.3000908@frit.net>
	<294d5daa1002041010l502a92b7n9d8bf6ec514b574c@mail.gmail.com>
Message-ID: <4B71694A.2070207@frit.net>

Mark Moseley a ?crit :
> Try putting "ulimit -c unlimited" in your varnishd rc file. I haven't
> needed to get a varnishd core file before, so maybe the devs might be
> able to advise if there's other steps necessary as well. There should
> also be some logs saying that it died (or at least that it restarted);
> dunno what your distro you're using, but in debian, those typically
> end up in /var/log/syslog.
>   
No way to get a core file even with  ulimit -c unlimited.

I use Gentoo and the kernel logs are in /var/log/kern.log
> You could tail varnishncsa to see if there's a common request where it
> seems to segfault at and if there is, you could attach to varnishd
> with "gdb /path/to/varnishd <pid of varnishd>" and try to trigger it.
> Then get the backtrace with 'bt'. But be aware that it'll bog it down
> dreadfully, so i wouldn't advise it in production.
>   
I could not figure out any common request.

So I end up googling "gentoo varnish" and it appears that the Gentoo 
team had released a varnish-2.0.4-r1 package and marked unstable 
varnish-2.0.4 and 2.0.5 gentoo packages. So I installed the r1 package 
yesterday and I didn't get any more segfault since I restarted varnishd.

Thanks for your help and best regards
--
Bernard FRIT





From perbu at varnish-software.com  Tue Feb  9 14:12:36 2010
From: perbu at varnish-software.com (Per Buer)
Date: Tue, 9 Feb 2010 15:12:36 +0100
Subject: Varnish Software
Message-ID: <52220de01002090612t6617242eleb63812bfd2ce628@mail.gmail.com>

Hi list.

Redpill-Linpro ?(RL) has been the main sponsor of Varnish?for the last
three years.

RL is a services company, generating most (probably over 95%) of its
revenue on selling services and products in its local?Scandinavian
market.

Developing a product for a global market takes a different?kind of
organization and a different kind of focus.

Therefore RL has decided to form a separate company around?Varnish:
Varnish Software AS. The company will initially consist of Tollef Fog
Heen, Kristian Lyngst?l and myself, all moving from Redpill Linpro.
Our sales will intially be handled by Redpill Linpro. We'll expand the
staff with more people in the months to come.

So, what does this mean for Varnish?
1. Varnish continues as a BSD-Licensed Open Source project.
2. Varnish users worldwide will be able to get competent?commercial
services, both contracting and service contracts,?from a company who
specializes in Varnish and high performance?web delivery.
3.?We will be able to spend more time and money on developing Varnish.
Our?goal is to make Varnish a de-facto standard for high performance
web sites.?We're not quite there yet - but we will be.

Some of Redpill Linpros service agreement customers will be
transferred to the new entity and some will continue to be handled
directly by R-L. We are hoping to sign up other partners to cover the
whole world.

Don't hesitate getting directly in touch with me if you want to
discuss partnership, employment, a support agreement or if you are
just plain curious. Every detail isn't ironed out yet and more
information will be made available later.



Regards.
Per.


--
Per Andreas Buer ?CEO, Varnish Software AS
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: perbu


From phk at phk.freebsd.dk  Tue Feb  9 13:59:27 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 09 Feb 2010 13:59:27 +0000
Subject: Varnish Software 
In-Reply-To: Your message of "Tue, 09 Feb 2010 15:12:36 +0100."
	<52220de01002090612t6617242eleb63812bfd2ce628@mail.gmail.com> 
Message-ID: <3496.1265723967@critter.freebsd.dk>

In message <52220de01002090612t6617242eleb63812bfd2ce628 at mail.gmail.com>, Per B
uer writes:

>Therefore RL has decided to form a separate company around Varnish:
>Varnish Software AS. The company will initially consist of Tollef Fog
>Heen, Kristian Lyngst?l and myself, all moving from Redpill Linpro.


Welcome Varnish Software!

Although there has never been doubt about Redpill-Linpros heart
being the right place for Varnish, it has never really fit that
well into the RL organization.  A new small focused company sounds
just like what the doctor ordered :-)

As you have guessed by now, I knew about these plans already, and
no, I will not be joining Varnish Software.

I will continue my own little company, where, I develop Varnish,
funded by the Varnish Moral Licenses and do other stuff for my other
customers.

Per has indicated that Varnish Software will pick up a Varnish Moral
License, to replace my current arrangement with RL, so the amount
of time I have available for Varnish is unchanged.

This is a good time to officially thank RL, and now Varnish Software,
for running our the Varnish project server for the Varnish Project:
Much appreciated!


This new development, does give me an excuse for "growing up" the
project a bit, so I have, hopefully for the last time, used my
dictatorial powers and appointed:

        Arther "sky" Bergman (users)
        Kristan Lyngstol (commercial)
        Poul-Henning Kamp (developers)

to the "Interrim Varnish Governing Board", which is tasked with
coming up with some sort of sensible project bylaws, ready for
ratification no later than VUG3.  (mail us your ideas, input etc)


So, back to the keyboards and see you at VUG2 in Amsterdam
(http://www.varnish-cache.org/wiki/VUG2)

Poul-Henning
(Until further notice: Defacto Ruler of The Varnish Project)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From abc at digithi.de  Wed Feb 10 00:02:40 2010
From: abc at digithi.de (Thimo E.)
Date: Wed, 10 Feb 2010 01:02:40 +0100
Subject: Connections to backend not closing
Message-ID: <4B71F7A0.2050308@digithi.de>

Dear all,

first of all, varnish is a really nice software! But... :)
...At the moment I have some problems with varnish and its backend 
connection(s).

Symptom:
After some time of running varnish (with some client connects and so 
one)  I see something like this in netstat -p:
...
tcp        0      0 localhost:1234       localhost:37447         
FIN_WAIT2   19643/webserver
tcp        3      0 localhost:37447         localhost:1234       
CLOSE_WAIT  19139/varnishd
...

- FIN_WAIT2 means the backend webserver has sent a TCP FIN packet, got a 
TCP ACK und waits for the TCP FIN from the other side (varnish).
- The CLOSE_WAIT state means that the varnish received the TCP FIN 
packet, acknowledged it with TCP ACK and shall now close the connection 
with a close() call.

Some time later (at least 5 minutes !) the last entry "CLOSE_WAIT" 
disappears but the "FIN_WAIT2" persists, so the webserver still has a 
semi-open socket:
...
tcp        0      0 localhost:1234       localhost:37447         
FIN_WAIT2   19643/webserver
...

The number of those entries grow over the time.

It seems as if the TCP connection closing in varnish doesn't perform 
correctly, the close() call in varnish is sometimes executed too late.

I am using varnish 2.0.6, linux 2.6.31
The backend is configured als follows:
...
backend vs_1x1 {
     .host = "127.0.0.1";
     .port = "1234";
     .connect_timeout = 5s;
     .first_byte_timeout = 300s;
     .between_bytes_timeout = 300s;
}
...

Any ideas why this happens ? Did I miss something in my backend 
configuration ?

Best regards
   Thimo E.


From schickb at gmail.com  Wed Feb 10 06:54:56 2010
From: schickb at gmail.com (Brad Schick)
Date: Tue, 9 Feb 2010 22:54:56 -0800
Subject: Maintenance message
Message-ID: <2CAA2D26-7B56-4402-88E1-559361135F33@gmail.com>

I have a varnish server working well, but I'd like to have a standby server that does nothing but server up "Sorry we are preforming maintenance". My thought was to write VCL code to check the health of the director, and if that was bad use a different server (something like the example below). But that doesn't work. Any suggestions?

backend web1 {
    .host = "10.0.0.1";
    .probe = {
        .url = "/";
        .window = 5;
        .threshold = 3;
    }
}

backend web2 {
    .host = "10.0.0.2";
    .probe = {
        .url = "/";
        .window = 5;
        .threshold = 3;
    }
}

backend maint {
    .host = "127.0.0.1";
}
                          
director cluster round-robin {
    { .backend = web1; }
    { .backend = web2; }
}

sub vcl_recv {
    if(cluster.healthy){
        set req.backend = cluster;
    } 
    else {
        set req.backend = maint;
    }
    ...
}

sub vcl_fetch {
    if(req.backend == maint) {
        pass; 
    }
   ...
}

From naamab at answers.com  Tue Feb  9 13:40:17 2010
From: naamab at answers.com (Naama Bamberger)
Date: Tue, 9 Feb 2010 07:40:17 -0600
Subject: Error compiling VCL when using '% in regexp 
In-Reply-To: <60459.1265626400@critter.freebsd.dk>
References: Your message of "Sun, 07 Feb 2010 09:20:19 CST."
	<DD929CD9109B0A4D8C34B732A6D35CC43C34E274@MBX03.exg5.exghost.com>
	<60459.1265626400@critter.freebsd.dk>
Message-ID: <DD929CD9109B0A4D8C34B732A6D35CC43C403167@MBX03.exg5.exghost.com>

I already tried using the escaped %25.
The compilation succeeded, but the regexp didn't find a match in the problematic URLs:

	# If the URL ends with % and one digit (a broken hex value) - remove the last 2 characters.
	if (req.url ~ "(.*)%25[0-9a-fA-F]$") {
		set req.url = regsub(req.url, "(.*)%25[0-9a-fA-F]$", "\1");
	}

Thanks for your help, 
Naama

-----Original Message-----
From: phk at critter.freebsd.dk [mailto:phk at critter.freebsd.dk] On Behalf Of Poul-Henning Kamp
Sent: Monday, February 08, 2010 12:53 PM
To: Naama Bamberger
Cc: varnish-misc at projects.linpro.no
Subject: Re: Error compiling VCL when using '% in regexp 

In message <DD929CD9109B0A4D8C34B732A6D35CC43C34E274 at MBX03.exg5.exghost.com>, Naama Bamberger writes:

>I get this error:
>
>Invalid hex char in %xx escape
>(input Line 107 Pos 28)
>        if (req.url ~ "(.*)%[0-9a-fA-F]$") {
>---------------------------###--------------
>

Try: %25

One of the decisions I had most trouble with, was deciding which
kind of escape-mechanism we wanted for strings in VCL.

In the end I settled for URL-%xx encoding, because I pressume
webmasters know it, and because it avoids a nightmare of back-slashes
in regexps.

I'm not 100% convinced that was the perfect decision...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Wed Feb 10 10:00:22 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 10 Feb 2010 10:00:22 +0000
Subject: Maintenance message 
In-Reply-To: Your message of "Tue, 09 Feb 2010 22:54:56 PST."
	<2CAA2D26-7B56-4402-88E1-559361135F33@gmail.com> 
Message-ID: <44429.1265796022@critter.freebsd.dk>

In message <2CAA2D26-7B56-4402-88E1-559361135F33 at gmail.com>, Brad Schick writes
:
>I have a varnish server working well, but I'd like to have a standby
>server that does nothing but server up "Sorry we are preforming
>maintenance". My thought was to write VCL code to check the health
>of the director, and if that was bad use a different server (something
>like the example below). But that doesn't work. Any suggestions?

Actually, it just takes a bit of a detour:

	sub vcl_recv {
		set req.backend = cluster;
		if (!req.backend.healthy) {
			set req.backend = maint;
		}
	}

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Wed Feb 10 10:04:06 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 10 Feb 2010 10:04:06 +0000
Subject: Connections to backend not closing 
In-Reply-To: Your message of "Wed, 10 Feb 2010 01:02:40 +0100."
	<4B71F7A0.2050308@digithi.de> 
Message-ID: <54565.1265796246@critter.freebsd.dk>

In message <4B71F7A0.2050308 at digithi.de>, "Thimo E." writes:
>Dear all,
>
>first of all, varnish is a really nice software! But... :)
>...At the moment I have some problems with varnish and its backend 
>connection(s).
>
>[..]
>
>Some time later (at least 5 minutes !) the last entry "CLOSE_WAIT" 
>disappears but the "FIN_WAIT2" persists, so the webserver still has a 
>semi-open socket:

This is actually per design, varnish keeps backend connections around
if they look like they can be reused, and only revisits them when it
tries to reuse them, so they may linger for quite a while before
varnish discovers they have been closed by the backend.

Apart from the socket hanging around, it is harmless.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From r at roze.lv  Wed Feb 10 11:04:33 2010
From: r at roze.lv (Reinis Rozitis)
Date: Wed, 10 Feb 2010 13:04:33 +0200
Subject: Maintenance message
References: <2CAA2D26-7B56-4402-88E1-559361135F33@gmail.com>
Message-ID: <D4FA51EE01F242B9838AB2FC56BF0FD3@KD5>

Why not use the vcl_error ?
Just customize the default html which is included in the sample config and you can have a nice error page without even the need of a 
extra server.

Or you mean the whole director config doesnt work?

rr

----- Original Message ----- 
From: "Brad Schick" <schickb at gmail.com>
To: <varnish-misc at projects.linpro.no>
Sent: Wednesday, February 10, 2010 8:54 AM
Subject: Maintenance message


>I have a varnish server working well, but I'd like to have a standby server that does nothing but server up "Sorry we are 
>preforming maintenance". My thought was to write VCL code to check the health of the director, and if that was bad use a different 
>server (something like the example below). But that doesn't work. Any suggestions?
>
> backend web1 {
>    .host = "10.0.0.1";
>    .probe = {
>        .url = "/";
>        .window = 5;
>        .threshold = 3;
>    }
> }
>
> backend web2 {
>    .host = "10.0.0.2";
>    .probe = {
>        .url = "/";
>        .window = 5;
>        .threshold = 3;
>    }
> }
>
> backend maint {
>    .host = "127.0.0.1";
> }
>
> director cluster round-robin {
>    { .backend = web1; }
>    { .backend = web2; }
> }
>
> sub vcl_recv {
>    if(cluster.healthy){
>        set req.backend = cluster;
>    }
>    else {
>        set req.backend = maint;
>    }
>    ...
> }
>
> sub vcl_fetch {
>    if(req.backend == maint) {
>        pass;
>    }
>   ...
> }
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
> 



From wrighty+varnishmisc at gmail.com  Wed Feb 10 11:05:30 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Wed, 10 Feb 2010 11:05:30 +0000
Subject: Child panics on OpenSolaris
Message-ID: <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com>

Hello list,

Using the Letsgetdugg[1] article I've installed Varnish on an
OpenSolaris zone.  During testing it works as expected but when it
receives production traffic I'm seeing children die with three
different types of panics[2][3][4] that look like this:

Panic message: Assert error in TCP_nonblocking(), tcp.c line 172:
Panic message: Assert error in TCP_blocking(), tcp.c line 163:
Assert error in VCA_Prep(), cache_acceptor.c line 163:

I've tried both enabling and disabling KeepAlive on the backend server
but doesn't seem to have any effect.  I've also tried a 2GB and 1GB
malloc cache just in case it was a 32bit issue (it's not and I've
since confirmed it's running as a 64bit process).

The VCL I'm using is pretty simple[5], it normalises the host header
and unsets the cookie header if the request is for a static asset.
This is how I'm starting up Varnish at the moment:

newtask -p highfile /opt/sbin/varnishd -f /opt/etc/varnish/firebox.vcl -F \
-p cc_command='/opt/SunStudioExpress/bin/cc -Kpic -G -m64 -o %o %s' \
-T 127.0.0.1:9001 \
-s malloc,1G \
-p sess_timeout=5s \
-p max_restarts=12 \
-p waiter=poll \
-p connect_timeout=0s \
-p sess_workspace=65536

Is there anything that jumps out as incorrect?  Is there some
additional configuration required for Solaris or are these panics to
be expected?

Cheers,

Paul.

[1] - http://letsgetdugg.com/2009/12/04/varnish-on-solaris/

[2] First panic type:
Child (18997) died signal=6
Child (18997) Panic message: Assert error in TCP_nonblocking(), tcp.c line 172:
  Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
(int))&0xff)<<16)| ('f'<<8)|126))), &i)) == 0) not true.
errno = 9 (Bad file number)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  44548b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x44548b]
  445795: /opt/sbin/varnishd'pan_ic+0x1c5 [0x445795]
  fffffd7ff3e5dfec: /opt/lib/libvarnish.so.1.0.0'TCP_nonblocking+0x7c
[0xfffffd7ff3e5dfec]
  419091: /opt/sbin/varnishd'vca_return_session+0x1b1 [0x419091]
  42675d: /opt/sbin/varnishd'cnt_wait+0x2bd [0x42675d]
  42b94a: /opt/sbin/varnishd'CNT_Session+0x4ba [0x42b94a]
  44801b: /opt/sbin/varnishd'wrk_do_cnt_sess+0x19b [0x44801b]
  447614: /opt/sbin/varnishd'wrk_thread_real+0x854 [0x447614]
  447b73: /opt/sbin/varnishd'wrk_thread+0x123 [0x447b73]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 866548 {
  fd = 25, id = 25, xid = 0,
  client = 92.41.40.169:2589,
  step = STP_WAIT,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 8665b8 {
    id = "sess",
    {s,f,r,e} = {8672c0,+18,+32786,+65536},
  },
  http[req] = {
    ws = 8665b8[sess]
      "",
      "/i/template/2009/search_icon_1.gif",
      "HTTP/1.1",
      "Accept: */*",
      "Referer:
http://www.firebox.com/product/2579/Yurakoro-Lucky-Cats?aff=1781",
      "Accept-Language: en-gb",
      "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; GTB6.4; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR
3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.3;
OfficeLivePatch.0.0)",
      "Accept-Encoding: gzip, deflate",
      "Connection: Keep-Alive",
      "host: media.firebox.com",
      "X-Forwarded-For: 92.41.40.169",
  },
},


[3] Second panic type:
Child (12024) said Child starts
Child (12024) died signal=6
Child (12024) Panic message: Assert error in TCP_blocking(), tcp.c line 163:
  Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
(int))&0xff)<<16)| ('f'<<8)|126))), &i)) == 0) not true.
errno = 9 (Bad file number)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  44548b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x44548b]
  445795: /opt/sbin/varnishd'pan_ic+0x1c5 [0x445795]
  fffffd7ff3e5df5c: /opt/lib/libvarnish.so.1.0.0'TCP_blocking+0x7c
[0xfffffd7ff3e5df5c]
  42b686: /opt/sbin/varnishd'CNT_Session+0x1f6 [0x42b686]
  44801b: /opt/sbin/varnishd'wrk_do_cnt_sess+0x19b [0x44801b]
  447614: /opt/sbin/varnishd'wrk_thread_real+0x854 [0x447614]
  447b73: /opt/sbin/varnishd'wrk_thread+0x123 [0x447b73]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
  fffffd7ff653afb0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ff653afb0]
sp = 3491f88 {
  fd = 156, id = 156, xid = 0,
  client = ?.?.?.?:?,
  step = STP_FIRST,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 3491ff8 {
    id = "sess",
    {s,f,r,e} = {3492d00,3492d00,0,+65536},
  },
  http[req] = {
    ws = 3491ff8[sess]
      "",
      "/pic/p2387_search.jpg",
      "HTTP/1.1",
      "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB;
rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)",
      "Accept: image/png,*/*;q=0.5",
      "Accept-Language: en-gb,en;q=0.5",
      "Accept-Encoding: gzip,deflate",
      "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
      "Keep-Alive: 300",
      "Connection: keep-alive",
      "Referer: http://www.firebox.com/admin/allproducts",
      "host: media.firebox.com",
      "X-Forwarded-For: 94.196.164.41",
  },
  worker = fffffd7ff8e08d30 {
    ws = fffffd7ff8e08e78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff8df6c40,fffffd7ff8df6c40,0,+65536},
    },
    },
},

[4] Third panic type:
Child (14402) died signal=6
Child (14402) Panic message: Assert error in VCA_Prep(),
cache_acceptor.c line 163:
  Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof
linger)) == 0) not true.
errno = 9 (Bad file number)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  44548b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x44548b]
  445795: /opt/sbin/varnishd'pan_ic+0x1c5 [0x445795]
  418495: /opt/sbin/varnishd'VCA_Prep+0x255 [0x418495]
  429284: /opt/sbin/varnishd'cnt_first+0xa4 [0x429284]
  42b98e: /opt/sbin/varnishd'CNT_Session+0x4fe [0x42b98e]
  44801b: /opt/sbin/varnishd'wrk_do_cnt_sess+0x19b [0x44801b]
  447614: /opt/sbin/varnishd'wrk_thread_real+0x854 [0x447614]
  447b73: /opt/sbin/varnishd'wrk_thread+0x123 [0x447b73]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
  fffffd7ff653afb0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ff653afb0]
sp = 67ef48 {
  fd = 131, id = 131, xid = 0,
  client = 90.196.3.202:52874,
  step = STP_FIRST,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 67efb8 {
    id = "sess",
    {s,f,r,e} = {67fcc0,+19,0,+65536},
  },
  http[req] = {
    ws = 67efb8[sess]
      "",
      "/i/video_graphics/blankpix.gif",
      "HTTP/1.1",
      "Accept: */*",
      "Referer: http://www.firebox.com/product/2277/Naughty-Knot",
      "Accept-Language: en-us",
      "Accept-Encoding: gzip, deflate",
      "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; GTB0.0; .NET CLR 2.0.50727)",
      "Connection: Keep-Alive",
      "host: media.firebox.com",
      "X-Forwarded-For: 86.156.9.150",
  },
  worker = fffffd7ff87ebd30 {
    ws = fffffd7ff87ebe78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff87d9c40,fffffd7ff87d9c40,0,+65536},
    },
    },
},

[5] firebox.vcl
backend martin {
	.host = "10.0.0.21";
	.port = "80";
}

director dynamic_director round-robin {
	{
		.backend = martin;
	}
}

director static_director round-robin {
	{
		.backend = martin;
	}
}

sub vcl_recv {
	// normalise static requests
	if ( req.http.host ~ "media([0-9]+).firebox.com" ) {
		set req.http.host = "media.firebox.com";
	}
	
	//catch any relative image URLs that haven't been repointed to media
	if ( req.http.host != "media.firebox.com" &&
	     ( req.url ~ "^/pic/.+" || req.url ~ "^/i/.+" ) ) {
			set req.http.host = "media.firebox.com";
	}
	
	// split traffic based on host name
	if ( req.http.host == "media.firebox.com" ) {
		remove req.http.cookie;
		set req.backend = static_director;
	} else {
		// dynamic content that should be cached (ie no cookies required)
		// these patterns should match up with settings.inc on the PHP side
		if ( req.url ~ "^/styles/(.+).css$" ||
		     req.url ~ "^/js/(.+).js$" ) {
			remove req.http.cookie;
		}
		//default all requests to the dynamic backend
		set req.backend = dynamic_director;
	}
}


From phk at phk.freebsd.dk  Wed Feb 10 10:10:14 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 10 Feb 2010 10:10:14 +0000
Subject: Error compiling VCL when using '% in regexp 
In-Reply-To: Your message of "Tue, 09 Feb 2010 07:40:17 CST."
	<DD929CD9109B0A4D8C34B732A6D35CC43C403167@MBX03.exg5.exghost.com> 
Message-ID: <57213.1265796614@critter.freebsd.dk>

In message <DD929CD9109B0A4D8C34B732A6D35CC43C403167 at MBX03.exg5.exghost.com>, N
aama Bamberger writes:
>I already tried using the escaped %25.
>The compilation succeeded, but the regexp didn't find a match in the problematic URLs:
>
>	# If the URL ends with % and one digit (a broken hex value) - remove the last 2 characters.
>	if (req.url ~ "(.*)%25[0-9a-fA-F]$") {
>		set req.url = regsub(req.url, "(.*)%25[0-9a-fA-F]$", "\1");
>	}

I just whipped up a varnishtest case, and it seems to work in -trunk:

	test "random test"

	server s1 {
		rxreq
		expect req.url == "/foo"
		txresp
	} -start

	varnish v1 -vcl+backend {

	sub vcl_recv {
		if (req.url ~ "(.*)%25[0-9a-fA-F]$") {
			set req.url = regsub(req.url, "(.*)%25[0-9a-fA-F]$", "\1");
		}
	}

	} -start

	client c1 {
		txreq -url /foo%a
		rxresp
	} -run

###  c1   Connect to 127.0.0.1:17621
###  c1   Connected to 127.0.0.1:17621 fd is 9
#### c1   txreq| GET /foo%a HTTP/1.1\r\n
#### c1   txreq| \r\n
###  c1   rxresp
###  s1   Accepted socket fd is 4
###  s1   rxreq
#### s1   rxhdr| GET /foo HTTP/1.1\r\n
#### s1   rxhdr| X-Forwarded-For: 127.0.0.1\r\n
#### s1   rxhdr| X-Varnish: 1001\r\n
#### s1   rxhdr| Host: 127.0.0.1\r\n
#### s1   rxhdr| \r\n


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Wed Feb 10 10:11:55 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 10 Feb 2010 10:11:55 +0000
Subject: obj.cacheable vs expires headers? 
In-Reply-To: Your message of "Tue, 09 Feb 2010 11:05:50 +0100."
	<15261481.301265709947078.JavaMail.luc@syntop> 
Message-ID: <57549.1265796715@critter.freebsd.dk>

In message <15261481.301265709947078.JavaMail.luc at syntop>, lstroobant at gmail.com
 writes:

>I'm not sure we're still talking about the same problem. :-)
>Just to be sure: we don't want to cache that dynamic page, but I'm
>wondering why (with those) headers, it's still seen as obj.cacheable
>by Varnish.

As I said, the cacheability is a different decision from how long
time to cache.

The logic of the code is in the sourcefile "rfc2616.c", try to walk
your request through it by hand...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Wed Feb 10 13:00:46 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 10 Feb 2010 13:00:46 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 10 Feb 2010 11:05:30 GMT."
	<282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com> 
Message-ID: <44572.1265806846@critter.freebsd.dk>

In message <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633 at mail.gmail.com>, Paul 
Wright writes:


Hi Paul,

We have a number of tickets on this issue already (626,615,588).

The problem is that EBADF return indicates that Varnish by mistake
has closed a file descriptor, that should still be open.

The alternative explanation, that Solaris can return EBADF because
the other end closed a TCP connection, does not seem to have any
support in Solaris documentation.

We are trying to get a Solaris box running so we can figure this
out once and for all.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From wrighty+varnishmisc at gmail.com  Wed Feb 10 14:15:36 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Wed, 10 Feb 2010 14:15:36 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <44572.1265806846@critter.freebsd.dk>
References: <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com>
	<44572.1265806846@critter.freebsd.dk>
Message-ID: <282e72051002100615x701a37a8o416c9af6d1d7fd38@mail.gmail.com>

On 10 February 2010 13:00, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633 at mail.gmail.com>, Paul
> Wright writes:
>
>
> Hi Paul,
>
> We have a number of tickets on this issue already (626,615,588).
>
> The problem is that EBADF return indicates that Varnish by mistake
> has closed a file descriptor, that should still be open.
>
> The alternative explanation, that Solaris can return EBADF because
> the other end closed a TCP connection, does not seem to have any
> support in Solaris documentation.
>
> We are trying to get a Solaris box running so we can figure this
> out once and for all.

Thanks for the explanation of what's going on.  Looking at those
tickets there are suggestions to try the poll waiter which we're
already using - are there any further tests we could try to help
narrow down this issue?  I'm happy to assist trying out patches.

Cheers,

Paul.


From phk at phk.freebsd.dk  Wed Feb 10 13:53:06 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 10 Feb 2010 13:53:06 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 10 Feb 2010 14:15:36 GMT."
	<282e72051002100615x701a37a8o416c9af6d1d7fd38@mail.gmail.com> 
Message-ID: <57907.1265809986@critter.freebsd.dk>

In message <282e72051002100615x701a37a8o416c9af6d1d7fd38 at mail.gmail.com>, Paul 
Wright writes:

>Thanks for the explanation of what's going on.  Looking at those
>tickets there are suggestions to try the poll waiter which we're
>already using - are there any further tests we could try to help
>narrow down this issue?  I'm happy to assist trying out patches.

I can see three ways to nail this issue:

1. Catch a tcpdump, when it happens, showing that the client side
   did close, and Solaris (incorrectly) returns EBADF.

2. Catch a ktrace/systrace/dtrace, when it happens, that show
   that Varnish incorrectly closes the fd.

3. Setup some synthetic test to show that solaris returns EBADF
   when it shouldn't

If either of those are in your reach, by all means go for it...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From schickb at gmail.com  Wed Feb 10 16:26:03 2010
From: schickb at gmail.com (Brad Schick)
Date: Wed, 10 Feb 2010 08:26:03 -0800
Subject: Maintenance message
In-Reply-To: <D4FA51EE01F242B9838AB2FC56BF0FD3@KD5>
References: <2CAA2D26-7B56-4402-88E1-559361135F33@gmail.com>
	<D4FA51EE01F242B9838AB2FC56BF0FD3@KD5>
Message-ID: <FB92D84A-9A75-42DB-8CE6-EEA30DBFF511@gmail.com>


On Feb 10, 2010, at 3:04 AM, Reinis Rozitis wrote:

>> I have a varnish server working well, but I'd like to have a standby server that does nothing but server up "Sorry we are 
>> preforming maintenance". My thought was to write VCL code to check the health of the director, and if that was bad use a different 
>> server (something like the example below). But that doesn't work. Any suggestions?
> 
> Why not use the vcl_error ?
> Just customize the default html which is included in the sample config and you can have a nice error page without even the need of a 
> extra server.
> 

Thanks for the suggestion, but our error page isn't trivial and I don't like the idea of maintaining the site within a varnish configuration file. It actually won't be an extra server, it will just be on a port on the same machine as varnish. But served by a proper http server.


-Brad

From abc at digithi.de  Thu Feb 11 00:17:08 2010
From: abc at digithi.de (Thimo E.)
Date: Thu, 11 Feb 2010 01:17:08 +0100
Subject: Connections to backend not closing
In-Reply-To: <54565.1265796246@critter.freebsd.dk>
References: <54565.1265796246@critter.freebsd.dk>
Message-ID: <4B734C84.3080006@digithi.de>

Hello Poul-Henning,

thanks for your quick response. I am not sure that this behavour is 
really harmless, at least its not for me :)

After 1 day running varnish I have 140 sockets of the backend webserver 
in FIN_WAIT2 state, this is quite a lot.
(btw; I don't know why FIN_WAIT2 sockets stay for such a long time in 
that state and don't time out...)

With a litte bit more semi-open connections I can get my backend to a 
state where stops responsing because of "Too many open connections" (I 
think 256 connections is the limit at the moment). As you can imagine 
that is quote annoying :)

Is there any possibility to say varnish to close "CLOSE_WAIT" 
connections immediately ? Or do you have other ideas ?

Thanks in advance
   Thimo

Am 10.02.2010 11:04, schrieb Poul-Henning Kamp:
> In message<4B71F7A0.2050308 at digithi.de>, "Thimo E." writes:
>    
>> Dear all,
>>
>> first of all, varnish is a really nice software! But... :)
>> ...At the moment I have some problems with varnish and its backend
>> connection(s).
>>
>> [..]
>>
>> Some time later (at least 5 minutes !) the last entry "CLOSE_WAIT"
>> disappears but the "FIN_WAIT2" persists, so the webserver still has a
>> semi-open socket:
>>      
> This is actually per design, varnish keeps backend connections around
> if they look like they can be reused, and only revisits them when it
> tries to reuse them, so they may linger for quite a while before
> varnish discovers they have been closed by the backend.
>
> Apart from the socket hanging around, it is harmless.
>
>
>    



From michael at dynamine.net  Thu Feb 11 00:29:43 2010
From: michael at dynamine.net (Michael Fischer)
Date: Wed, 10 Feb 2010 16:29:43 -0800
Subject: Connections to backend not closing
In-Reply-To: <4B734C84.3080006@digithi.de>
References: <54565.1265796246@critter.freebsd.dk> <4B734C84.3080006@digithi.de>
Message-ID: <d002c4031002101629g2c471de7w5f363b5ff1dbf485@mail.gmail.com>

On Wed, Feb 10, 2010 at 4:17 PM, Thimo E. <abc at digithi.de> wrote:

> After 1 day running varnish I have 140 sockets of the backend webserver
> in FIN_WAIT2 state, this is quite a lot.


I'm why do you believe this is "a lot"?  Do you have evidence that this is
causing your server to behave suboptimally?  The impact should be no more
than a bit of RAM.

--Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100210/55025769/attachment.html>

From wrighty+varnishmisc at gmail.com  Thu Feb 11 15:39:10 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Thu, 11 Feb 2010 15:39:10 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <57907.1265809986@critter.freebsd.dk>
References: <282e72051002100615x701a37a8o416c9af6d1d7fd38@mail.gmail.com>
	<57907.1265809986@critter.freebsd.dk>
Message-ID: <282e72051002110739y50bc0b16j687bf75692f42ec8@mail.gmail.com>

On 10 February 2010 13:53, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002100615x701a37a8o416c9af6d1d7fd38 at mail.gmail.com>, Paul
> Wright writes:
>
>>Thanks for the explanation of what's going on. ?Looking at those
>>tickets there are suggestions to try the poll waiter which we're
>>already using - are there any further tests we could try to help
>>narrow down this issue? ?I'm happy to assist trying out patches.
>
> I can see three ways to nail this issue:
>
> 1. Catch a tcpdump, when it happens, showing that the client side
> ? did close, and Solaris (incorrectly) returns EBADF.
>
> 2. Catch a ktrace/systrace/dtrace, when it happens, that show
> ? that Varnish incorrectly closes the fd.
>
> 3. Setup some synthetic test to show that solaris returns EBADF
> ? when it shouldn't
>
> If either of those are in your reach, by all means go for it...

I've had a go at 1.) and have two verbose `snoop` traces during child
panics.  I used sp.client from the backtrace to find out the port
number and then looked at just matching packets. From my (limited)
Wireshark comprehension they show the client establishing a connection
to Varnish, issue a GET, receive the response (200 OK).  Then the
client sends a RST packet, from there the connection disappears.
Would this cause the child to panic?

I can't post these traces publicly but are there any other details
that would help?

I've been racking my brains to think if there is any special in our
setup and the only thing that springs to mind is the firewall.  We
have an OpenBSD firewall using PF to redirect HTTP traffic from the
public IP address to the internal web servers which has worked without
issue for a number of years.  During testing the only firewall change
I've made redirects this traffic to Varnish instead.

Paul.


From john at 7fff.com  Thu Feb 11 22:25:18 2010
From: john at 7fff.com (John Norman)
Date: Thu, 11 Feb 2010 17:25:18 -0500
Subject: Not seeing a successful purge
Message-ID: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>

Hi, folks.

I'm trying to purge with the pseudo HTTP "PURGE" method Varnish supports.

I do seem to have a cached page, but the PURGE response suggests that
it's missing.

So . . . any idea why the PURGE isn't working?

In my VCL, my vcl_hash looks like this (I intend it to only hash on
the request URL and compression):

sub vcl_hash {
  set req.hash += req.url;

  if (req.http.Accept-Encoding ~ "gzip") {
    set req.hash += "gzip";
  } else if (req.http.Accept-Encoding ~ "deflate") {
    set req.hash += "deflate";
  }
  return (hash);
}

And the checks for PURGE look like this (full VCL way below):

sub vcl_hit {
  if (req.request == "PURGE") {
    set obj.ttl = 0s;
    error 200 "Purged.";
  }
  if (!obj.cacheable) {
    pass;
  }

  deliver;
}
sub vcl_miss {
  if (req.request == "PURGE") {
    error 404 "Not in cache.";
  }
}

And in vcl_recv:

  if (req.request == "PURGE") {
    lookup;
  }

Below is some output from varnishlog, first showing the return of the
cached page -- then the response for the PURGE.

The request from the browser comes through HAProxy first, then into Varnish.

The PURGE request is via Ruby Mechanize.

4 ReqStart     c 10.253.191.95 60271 904319188
4 RxRequest    c GET
4 RxURL        c /products/sillyputty
4 RxProtocol   c HTTP/1.1
4 RxHeader     c Host: staging1.example.com
4 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
4 RxHeader     c Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
4 RxHeader     c Accept-Language: en-us,en;q=0.5
4 RxHeader     c Accept-Encoding: gzip,deflate
4 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
4 RxHeader     c Keep-Alive: 300
4 RxHeader     c Connection: keep-alive
4 RxHeader     c Cookie: cehq-id=10.252.66.194.1263417178788050;
__utma=240927894.185175319.1263417179.1265907679.1265923273.61;
__utmz=240927894.1263591912.11.2.utmcsr=localhost:3000|utmccn=(referral)|utmcmd=referral|utmcct=/;
__utma=229000926.194920698.1263480064.126591
4 RxHeader     c X-Forwarded-For: 75.150.106.113
4 VCL_call     c recv
4 VCL_return   c lookup
4 VCL_call     c hash
4 VCL_return   c hash
4 Hit          c 904319089
4 VCL_call     c hit
4 VCL_return   c deliver
4 Length       c 13825
4 VCL_call     c deliver
4 VCL_return   c deliver
4 TxProtocol   c HTTP/1.1
4 TxStatus     c 200
4 TxResponse   c OK
4 TxHeader     c Server: Apache/2.2.12 (Ubuntu)
4 TxHeader     c X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.9
4 TxHeader     c Cache-Control: max-age=7680, public
4 TxHeader     c X-Runtime: 56860
4 TxHeader     c ETag: "1de74468f783ce10a7af58decf0b5871"
4 TxHeader     c Status: 200
4 TxHeader     c Vary: Accept-Encoding,User-Agent
4 TxHeader     c Content-Encoding: gzip
4 TxHeader     c Content-Type: text/html; charset=utf-8
4 TxHeader     c Content-Length: 13825
4 TxHeader     c Date: Thu, 11 Feb 2010 22:09:33 GMT
4 TxHeader     c X-Varnish: 904319188 904319089
4 TxHeader     c Age: 852
4 TxHeader     c Via: 1.1 varnish
4 TxHeader     c Connection: keep-alive
4 ReqEnd       c 904319188 1265926173.262102842 1265926173.262276649
0.000060797 0.000109196 0.000064611

4 ReqStart     c 10.253.191.95 60313 904319225
4 RxRequest    c PURGE
4 RxURL        c /products/sillyputty
4 RxProtocol   c HTTP/1.1
4 RxHeader     c Accept: */*
4 RxHeader     c User-Agent: WWW-Mechanize/1.0.0
(http://rubyforge.org/projects/mechanize/)
4 RxHeader     c Connection: keep-alive
4 RxHeader     c Keep-Alive: 300
4 RxHeader     c Accept-Encoding: gzip,identity
4 RxHeader     c Accept-Language: en-us,en;q=0.5
4 RxHeader     c Host: staging1:8000
4 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
4 VCL_call     c recv
4 VCL_return   c lookup
4 VCL_call     c hash
4 VCL_return   c hash
4 VCL_call     c miss
0 Debug        - "VCL_error(404, Not in cache.)"
4 VCL_return   c error
4 VCL_call     c error
4 VCL_return   c deliver
4 Length       c 340
4 VCL_call     c deliver
4 VCL_return   c deliver
4 TxProtocol   c HTTP/1.1
4 TxStatus     c 404
4 TxResponse   c Not in cache.
4 TxHeader     c Server: Varnish
4 TxHeader     c Retry-After: 0
4 TxHeader     c Content-Type: text/html; charset=utf-8
4 TxHeader     c Content-Length: 340
4 TxHeader     c Date: Thu, 11 Feb 2010 22:10:02 GMT
4 TxHeader     c X-Varnish: 904319225
4 TxHeader     c Age: 0
4 TxHeader     c Via: 1.1 varnish
4 TxHeader     c Connection: close
4 ReqEnd       c 904319225 1265926202.794907331 1265926202.795089960
0.000054121 0.000142574 0.000040054

For the sake of completeness, here's the full VCL (the reason for the
director with one server is 'cos on product we round-robin against 3
backends):

backend reviews0 {
  .host = "10.253.191.95";
  .port = "7000";

#    .probe = {
#      .url = "/heartbeat";
#      .timeout = 10.0 s;
#      .interval = 120 s;
#      .window = 10;
#      .threshold = 7;
#    }

}


director reviews round-robin {

    { .backend = reviews0; }

}

sub vcl_hash {
  set req.hash += req.url;

  if (req.http.Accept-Encoding ~ "gzip") {
    set req.hash += "gzip";
  } else if (req.http.Accept-Encoding ~ "deflate") {
    set req.hash += "deflate";
  }
  return (hash);
}

sub vcl_recv {

  set req.backend = reviews;

  set req.grace = 2m;

  unset req.http.user-agent;

  # Workaround for Varnish bug in handling x-forwarded-for
  # The bug should be fixed in 2.0.7, and allow for taking the prior
proxy's x-forwarded-for
  # See http://varnish-cache.org/ticket/601
  #     https://wiki.fourkitchens.com/display/PF/Workaround+for+Varnish+X-Forwarded-For+bug
  if (req.http.X-Forwarded-For) {
    set req.http.X-Real-Forwarded-For = req.http.X-Forwarded-For ", "
regsub(client.ip, ":.*", "");
    unset req.http.X-Forwarded-For;
  } else {
    set req.http.X-Real-Forwarded-For = regsub(client.ip, ":.*", "");
  }

  # Remove some irrelevant parameters from the URL
  set req.url = regsuball(req.url,
"(\?|&)(qid|x|y|country|reviewId)=[^?&]*", "");
  # Put the ? back in if we removed it and need it
  if (req.url !~ "\?" && req.url ~ "&") {
    set req.url = regsub(req.url, "&", "?");
  }

  if (req.request == "PURGE") {
    lookup;
  }

	if (req.request == "POST") {
		pass;
	}

	if (req.request != "GET" && req.request != "HEAD" &&
		req.request != "PUT" && req.request != "POST" &&
		req.request != "TRACE" && req.request != "OPTIONS" &&
		req.request != "DELETE") {

		# Non-RFC2616 or CONNECT
		pass;
	}

  if (req.http.Authorization) {
		# Not cacheable by default
		pass;
  }

	lookup;
}

sub vcl_fetch {

  set obj.grace = 2m;

  unset obj.http.user-agent;

	if (!obj.cacheable) {
	    pass;
	}

	if (obj.http.Pragma ~ "no-cache" ||
	  obj.http.Cache-Control ~ "no-cache" ||
	  obj.http.Cache-Control ~ "private") {
	       pass;
	}

	if (obj.http.Cache-Control ~ "public") {
    unset obj.http.Set-Cookie;
		deliver;
	}
	pass;
}

# Implement PURGE: See http://varnish.projects.linpro.no/wiki/VCLExampleAlexc
sub vcl_hit {
  if (req.request == "PURGE") {
    set obj.ttl = 0s;
    error 200 "Purged.";
  }
  if (!obj.cacheable) {
    pass;
  }

  deliver;
}
sub vcl_miss {
  if (req.request == "PURGE") {
    error 404 "Not in cache.";
  }
}

# Standard error, but without the Guru meditation line
sub vcl_error {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  synthetic {"
 	<?xml version="1.0" encoding="utf-8"?>
 	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 	 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 	<html>
 	  <head>
 	    <title>"} obj.status " " obj.response {"</title>
 	  </head>
 	  <body>
 	    <h1>Error "} obj.status " " obj.response {"</h1>
 	    <p>"} obj.response {"</p>
 	    <hr>
 	  </body>
 	</html>
  "};
  return (deliver);
}


From phk at phk.freebsd.dk  Thu Feb 11 21:54:38 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 11 Feb 2010 21:54:38 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Thu, 11 Feb 2010 15:39:10 GMT."
	<282e72051002110739y50bc0b16j687bf75692f42ec8@mail.gmail.com> 
Message-ID: <1650.1265925278@critter.freebsd.dk>

In message <282e72051002110739y50bc0b16j687bf75692f42ec8 at mail.gmail.com>, Paul 
Wright writes:

>I've had a go at 1.) and have two verbose `snoop` traces during child
>panics.  I used sp.client from the backtrace to find out the port
>number and then looked at just matching packets. From my (limited)
>Wireshark comprehension they show the client establishing a connection
>to Varnish, issue a GET, receive the response (200 OK).  Then the
>client sends a RST packet, from there the connection disappears.
>Would this cause the child to panic?

Questions:

Does the RST arrive after the entire response is sent ?

If so: does the client ACK the response, before the RST ?

If so: how long time elapses between the ACK and the RST ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Thu Feb 11 21:59:32 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 11 Feb 2010 21:59:32 +0000
Subject: Connections to backend not closing 
In-Reply-To: Your message of "Wed, 10 Feb 2010 16:29:43 PST."
	<d002c4031002101629g2c471de7w5f363b5ff1dbf485@mail.gmail.com> 
Message-ID: <1710.1265925572@critter.freebsd.dk>

In message <d002c4031002101629g2c471de7w5f363b5ff1dbf485 at mail.gmail.com>, Micha
el Fischer writes:
>--000e0cd2978a506e4c047f483f78

>> After 1 day running varnish I have 140 sockets of the backend webserver
>> in FIN_WAIT2 state, this is quite a lot.

Well, yes and no.

The normal finwait2 timeout is on the order of most of a day, 60.000
seconds on FreeBSD for instance, so 140 is probably no more than
one socket every ten minutes or so.

If you look in varnishstat, does the number correlate to the 
"Backend Conn." activity counters in any way ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From abc at digithi.de  Thu Feb 11 23:12:56 2010
From: abc at digithi.de (Thimo E.)
Date: Fri, 12 Feb 2010 00:12:56 +0100
Subject: Connections to backend not closing
In-Reply-To: <1710.1265925572@critter.freebsd.dk>
References: <1710.1265925572@critter.freebsd.dk>
Message-ID: <4B748EF8.3050606@digithi.de>

Hello Poul, hello Michael,

 >The impact [of sockets in FIN_WAIT2] should be no more than a bit of RAM.
I disagree slightly :) The application which is waiting in FIN_WAIT2 has 
allocated structures, threads which (may or may not) consume CPU time, 
... and last but not least the value of max opened sockets will be 
reduced by those dead sockets.
And..as I wrote already..due to that many opened sockets my backend 
stops responding because of "Too many open connections".


Situation after 2 days running varnish:

netstat -p:
520 connections in FIN_WAIT2 state

varnishstat:
...
          438         0.00         0.01 Backend conn. reuses
          547         0.00         0.01 Backend conn. was closed
          988         0.00         0.02 Backend conn. recycles
...

>If you look in varnishstat, does the number correlate to the
>"Backend Conn." activity counters in any way ?

Poul, the 547 closed backend connections are quite near to 520 FIN_WAIT2 
connections.

Any suggestions ?

Greets
   Thimo



From bert-jan at bugbyte.nl  Thu Feb 11 23:08:53 2010
From: bert-jan at bugbyte.nl (Bert-Jan de Lange)
Date: Fri, 12 Feb 2010 00:08:53 +0100
Subject: ESI include inserts garbage code
Message-ID: <4B748E05.3060501@bugbyte.nl>

Hi folks,

I'm experimenting with ESI and something weird has come up: varnish is 
adding garbage code to the output.
The public address is the production varnish that doesn't use this yet, 
so you'll need to edit your hosts-file:

81.23.226.44 www.mobilecowboys.nl

My sample page is http://www.mobilecowboys.nl/news/hbptest

It switches randomly between 3 diferent includes all of which are cached:
http://www.mobilecowboys.nl/news/hbpplayer/review_id/1370977981
http://www.mobilecowboys.nl/news/hbpplayer/review_id/1600813923
http://www.mobilecowboys.nl/news/hbpplayer/review_id/1271683253

The extra code looks like checksums. They are consistent for each include.

The relevant debug lines from varnishlog are:
     7 Debug        c "tag {include 
src="/news/hbpplayer/review_id/1370977981"} 0 1 0"
     7 Debug        c "Incl " src="/news/hbpplayer/review_id/1370977981"""

     7 Debug        c "tag {include 
src="/news/hbpplayer/review_id/1600813923"} 0 1 0"
     7 Debug        c "Incl " src="/news/hbpplayer/review_id/1600813923"""

     7 Debug        c "tag {include 
src="/news/hbpplayer/review_id/1271683253"} 0 1 0"
     7 Debug        c "Incl " src="/news/hbpplayer/review_id/1271683253"""

And near the end of a request:
     7 Debug        c "herding"

I'm running varnish 2.0.6 from ports on freebsd 7.2

Thanks,
Bert-Jan


From phk at phk.freebsd.dk  Thu Feb 11 23:28:27 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 11 Feb 2010 23:28:27 +0000
Subject: ESI include inserts garbage code 
In-Reply-To: Your message of "Fri, 12 Feb 2010 00:08:53 +0100."
	<4B748E05.3060501@bugbyte.nl> 
Message-ID: <1961.1265930907@critter.freebsd.dk>

In message <4B748E05.3060501 at bugbyte.nl>, Bert-Jan de Lange writes:
>Hi folks,
>
>I'm experimenting with ESI and something weird has come up: varnish is 
>adding garbage code to the output.

What is the garbage that you are seing ?

If it a separate line with hex digits, then it is the chunked encoding
we use to transmit ESI with to HTTP/1.1 clients...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From bert-jan at bugbyte.nl  Thu Feb 11 23:31:37 2010
From: bert-jan at bugbyte.nl (Bert-Jan de Lange)
Date: Fri, 12 Feb 2010 00:31:37 +0100
Subject: ESI include inserts garbage code
In-Reply-To: <1961.1265930907@critter.freebsd.dk>
References: <1961.1265930907@critter.freebsd.dk>
Message-ID: <4B749359.3080901@bugbyte.nl>

On 12-Feb-2010 00:28, Poul-Henning Kamp wrote:
> In message<4B748E05.3060501 at bugbyte.nl>, Bert-Jan de Lange writes:
>    
>> Hi folks,
>>
>> I'm experimenting with ESI and something weird has come up: varnish is
>> adding garbage code to the output.
>>      
> What is the garbage that you are seing ?
>
> If it a separate line with hex digits, then it is the chunked encoding
> we use to transmit ESI with to HTTP/1.1 clients...
>    
Yes, exactly that. It looks like this:

<start>
1a

<before the include>
53c


Blij verrast waren we toen we de Nokia 5630 Xpressmusic uit de doos 
haalde. Op het eerste gezicht ziet het toestel van Nokia er namelijk erg 
goed uit. Als je daarnaast op basis van de naam ook een goede mp3-speler 
mag verwachten, stijgt de spanning helemaal. Maar zit er ook echt muziek 
in deze telefoon?

Lees de volledige review van de Nokia 5630 op BesteProduct.nl 19

<after the include>
0
<end>


From phk at phk.freebsd.dk  Thu Feb 11 23:48:55 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 11 Feb 2010 23:48:55 +0000
Subject: ESI include inserts garbage code 
In-Reply-To: Your message of "Fri, 12 Feb 2010 00:31:37 +0100."
	<4B749359.3080901@bugbyte.nl> 
Message-ID: <2048.1265932135@critter.freebsd.dk>

In message <4B749359.3080901 at bugbyte.nl>, Bert-Jan de Lange writes:
>On 12-Feb-2010 00:28, Poul-Henning Kamp wrote:

>> If it a separate line with hex digits, then it is the chunked encoding
>> we use to transmit ESI with to HTTP/1.1 clients...
>>    
>Yes, exactly that. It looks like this:

Your client should not show you that.

I fixed a bug in -trunk three days that might relate to this,
(HTTP/1.0 vs HTTP/1.1 confusion).

Or you can try in vcl_deliver to always force the reply protocol
to be HTTP/1.1

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From bert-jan at bugbyte.nl  Thu Feb 11 23:51:48 2010
From: bert-jan at bugbyte.nl (Bert-Jan de Lange)
Date: Fri, 12 Feb 2010 00:51:48 +0100
Subject: ESI include inserts garbage code
In-Reply-To: <2048.1265932135@critter.freebsd.dk>
References: <2048.1265932135@critter.freebsd.dk>
Message-ID: <4B749814.8030205@bugbyte.nl>

On 12-Feb-2010 00:48, Poul-Henning Kamp wrote:
> In message<4B749359.3080901 at bugbyte.nl>, Bert-Jan de Lange writes:
>    
>> On 12-Feb-2010 00:28, Poul-Henning Kamp wrote:
>>      
>    
>>> If it a separate line with hex digits, then it is the chunked encoding
>>> we use to transmit ESI with to HTTP/1.1 clients...
>>>
>>>        
>> Yes, exactly that. It looks like this:
>>      
> Your client should not show you that.
>
> I fixed a bug in -trunk three days that might relate to this,
> (HTTP/1.0 vs HTTP/1.1 confusion).
>
> Or you can try in vcl_deliver to always force the reply protocol
> to be HTTP/1.1
>    
Yes, I see it responds with HTTP/1.0.
I'll fix it in vcl_deliver, no problem.

Thanks !


From bert-jan at bugbyte.nl  Fri Feb 12 00:11:37 2010
From: bert-jan at bugbyte.nl (Bert-Jan de Lange)
Date: Fri, 12 Feb 2010 01:11:37 +0100
Subject: ESI include inserts garbage code {SOLVED]
In-Reply-To: <2048.1265932135@critter.freebsd.dk>
References: <2048.1265932135@critter.freebsd.dk>
Message-ID: <4B749CB9.6080407@bugbyte.nl>

On 12-Feb-2010 00:48, Poul-Henning Kamp wrote:
> In message<4B749359.3080901 at bugbyte.nl>, Bert-Jan de Lange writes:
>    
>> On 12-Feb-2010 00:28, Poul-Henning Kamp wrote:
>>      
>    
>>> If it a separate line with hex digits, then it is the chunked encoding
>>> we use to transmit ESI with to HTTP/1.1 clients...
>>>
>>>        
>> Yes, exactly that. It looks like this:
>>      
> Your client should not show you that.
>
> I fixed a bug in -trunk three days that might relate to this,
> (HTTP/1.0 vs HTTP/1.1 confusion).
>
> Or you can try in vcl_deliver to always force the reply protocol
> to be HTTP/1.1
>
>    

Added to the end of vcl_deliver:

if (resp.http.Transfer-Encoding == "chunked") {
     set resp.proto = regsub(resp.proto, "1\.0", "1.1");
}

The checksums are gone now.


From phk at phk.freebsd.dk  Fri Feb 12 00:14:24 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Feb 2010 00:14:24 +0000
Subject: ESI include inserts garbage code {SOLVED] 
In-Reply-To: Your message of "Fri, 12 Feb 2010 01:11:37 +0100."
	<4B749CB9.6080407@bugbyte.nl> 
Message-ID: <2212.1265933664@critter.freebsd.dk>

In message <4B749CB9.6080407 at bugbyte.nl>, Bert-Jan de Lange writes:

>The checksums are gone now.

Well, they're not really checksums, they are byte counts, but...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From l at lrowe.co.uk  Fri Feb 12 10:49:13 2010
From: l at lrowe.co.uk (Laurence Rowe)
Date: Fri, 12 Feb 2010 11:49:13 +0100
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
Message-ID: <e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>

Hi,

Your PURGE request is getting a different hash than your browser
requests because there is no Accept-Encoding header on the PURGE. (You
see the same problem when using Vary on the response). See
http://varnish-cache.org/wiki/Purging. You can either use <<
purge("req.url ~ " req.url); >> in vcl_recv, or send multiple PURGE
requests with each of the relavant Accept-Encoding values.

Laurence

On 11 February 2010 23:25, John Norman <john at 7fff.com> wrote:
> Hi, folks.
>
> I'm trying to purge with the pseudo HTTP "PURGE" method Varnish supports.
>
> I do seem to have a cached page, but the PURGE response suggests that
> it's missing.
>
> So . . . any idea why the PURGE isn't working?
>
> In my VCL, my vcl_hash looks like this (I intend it to only hash on
> the request URL and compression):
>
> sub vcl_hash {
> ?set req.hash += req.url;
>
> ?if (req.http.Accept-Encoding ~ "gzip") {
> ? ?set req.hash += "gzip";
> ?} else if (req.http.Accept-Encoding ~ "deflate") {
> ? ?set req.hash += "deflate";
> ?}
> ?return (hash);
> }
>
> And the checks for PURGE look like this (full VCL way below):
>
> sub vcl_hit {
> ?if (req.request == "PURGE") {
> ? ?set obj.ttl = 0s;
> ? ?error 200 "Purged.";
> ?}
> ?if (!obj.cacheable) {
> ? ?pass;
> ?}
>
> ?deliver;
> }
> sub vcl_miss {
> ?if (req.request == "PURGE") {
> ? ?error 404 "Not in cache.";
> ?}
> }
>
> And in vcl_recv:
>
> ?if (req.request == "PURGE") {
> ? ?lookup;
> ?}


From phk at phk.freebsd.dk  Fri Feb 12 10:49:21 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Feb 2010 10:49:21 +0000
Subject: Aiming for Varnish 2.1
Message-ID: <4588.1265971761@critter.freebsd.dk>


Thanks to our new energy, we have been able to chase down and close
a fair number of weird bugs in Varnish, and right now, -trunk looks
pretty solid.

Subject to the quantum-murphy-o-meter freaking out, I think we are
ready to cut a 2.1 branch, maybe even in time for VUG2.

This will become the new "-stable" release branch, and it is probably
a good idea for you to plan to migrate to it at some point.

I really appreciate the effort some of you already are throwing at
crashing -trunk for me, and urge everybody to get in on that game
before the release.

I can't offer your cheques signed by Donald Knuth, for each bug
you find, but I really do appreciate the effort and quality of
bug-reports.

To be honest, I have somewhat lost track of what has and what hasn't
been merged into 2.0, so I skimmed the 25k+ line diff between -trunk
and 2.0 and noticed:

 * A lot less bugs.

 * Dynamic minimum sizing of per-object storage.

 * Max number of HTTP headers a parameter.

 * -hcritbit the default, should be faster, self sizing.

 * -spersistent still aprototype, but it might be usable for a limited
   number of setups already now.

 * saint-mode.  It's complicated to explain, but smart.

 * Authentication of CLI connections.

 * New expressive ban/purge syntax

 * ban-lurker to try to keep purge-list length under control

 * New "hash" director, distributes backend traffic according to
   the object hash-key.

 * New "client" directors, distributes backend traffic according to
   client IP#.

 * Separate VCL access to request sent to backend, reply from backend.

 * Elimination of magic numbers in varnishtest testcases (+23 new tests)

 * (More?) correct handling of HTTP/1.0 <-> HTTP/1.1 headers.

 + probably a lot of details I overlooked.

 + whatever bugs we manage to fix before 2.1 is cut.

On the down-side:

 * -spersistent still not done.

 * Various solaris issues still not resolved.

 * You need to change your VCL at bit.

 * We still have a half hundred open tickets.

 * Some new bugs, didn't see them, but I know they are there.


Enjoy,

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


From l at lrowe.co.uk  Fri Feb 12 10:53:16 2010
From: l at lrowe.co.uk (Laurence Rowe)
Date: Fri, 12 Feb 2010 11:53:16 +0100
Subject: Connections to backend not closing
In-Reply-To: <4B748EF8.3050606@digithi.de>
References: <1710.1265925572@critter.freebsd.dk> <4B748EF8.3050606@digithi.de>
Message-ID: <e95443d91002120253p14ef3ee9w2b891022111f90a9@mail.gmail.com>

On 12 February 2010 00:12, Thimo E. <abc at digithi.de> wrote:
> Hello Poul, hello Michael,
>
> ?>The impact [of sockets in FIN_WAIT2] should be no more than a bit of RAM.
> I disagree slightly :) The application which is waiting in FIN_WAIT2 has
> allocated structures, threads which (may or may not) consume CPU time,
> ... and last but not least the value of max opened sockets will be
> reduced by those dead sockets.
> And..as I wrote already..due to that many opened sockets my backend
> stops responding because of "Too many open connections".
>
>
> Situation after 2 days running varnish:
>
> netstat -p:
> 520 connections in FIN_WAIT2 state
>
> varnishstat:
> ...
> ? ? ? ? ?438 ? ? ? ? 0.00 ? ? ? ? 0.01 Backend conn. reuses
> ? ? ? ? ?547 ? ? ? ? 0.00 ? ? ? ? 0.01 Backend conn. was closed
> ? ? ? ? ?988 ? ? ? ? 0.00 ? ? ? ? 0.02 Backend conn. recycles
> ...
>
>>If you look in varnishstat, does the number correlate to the
>>"Backend Conn." activity counters in any way ?
>
> Poul, the 547 closed backend connections are quite near to 520 FIN_WAIT2
> connections.
>
> Any suggestions ?

You might want to increase the ulimit -n for your backend server
process. With nginx set up as a proxy, each open connection consumed 4
file descriptors. (The default is normally 1024).

Laurence


From wrighty+varnishmisc at gmail.com  Fri Feb 12 12:17:59 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Fri, 12 Feb 2010 12:17:59 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <1650.1265925278@critter.freebsd.dk>
References: <282e72051002110739y50bc0b16j687bf75692f42ec8@mail.gmail.com>
	<1650.1265925278@critter.freebsd.dk>
Message-ID: <282e72051002120417w6c8ce8bcha2c96a809e9badc1@mail.gmail.com>

Apologies if this is a duplicate.

On 11 February 2010 21:54, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002110739y50bc0b16j687bf75692f42ec8 at mail.gmail.com>, Paul
> Wright writes:
>
>>I've had a go at 1.) and have two verbose `snoop` traces during child
>>panics. ?I used sp.client from the backtrace to find out the port
>>number and then looked at just matching packets. From my (limited)
>>Wireshark comprehension they show the client establishing a connection
>>to Varnish, issue a GET, receive the response (200 OK). ?Then the
>>client sends a RST packet, from there the connection disappears.
>>Would this cause the child to panic?
>
> Questions:

I've included the summary traces below in case my reading of them is
incorrect (times are relative to the start of snooping).  The first is
a single GET request, the second contains a number of KeepAlive GETs.
Both end in a RST, ACK packet.

> Does the RST arrive after the entire response is sent ?

Yes.

> If so: does the client ACK the response, before the RST ?

In Stream 1 the client ACK the response in the same packet as the RST.
 In Stream 2 there's an ACK and then an ACK, RST.

> If so: how long time elapses between the ACK and the RST ?

0.031s

Paul.

===Stream 1===
No.     Time        Source                Destination           Protocol Info
  30700 10.878818   81.144.251.100        192.168.0.35          TCP
  18763 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1380
  30701 10.878838   192.168.0.35          81.144.251.100        TCP
  http > 18763 [SYN, ACK] Seq=0 Ack=1 Win=64860 Len=0 MSS=1460
  30703 10.885352   81.144.251.100        192.168.0.35          TCP
  18763 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
  30704 10.885758   81.144.251.100        192.168.0.35          HTTP
  GET /flash/hpf.swf HTTP/1.0
  30705 10.885778   192.168.0.35          81.144.251.100        TCP
  http > 18763 [ACK] Seq=1 Ack=818 Win=64860 Len=0
  30711 10.887222   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  30712 10.887231   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  30730 10.896227   81.144.251.100        192.168.0.35          TCP
  18763 > http [ACK] Seq=818 Ack=1562 Win=65535 Len=0
  30731 10.896242   192.168.0.35          81.144.251.100        HTTP
  HTTP/1.1 200 OK  (application/x-shockwave-flash)
  30798 10.938749   81.144.251.100        192.168.0.35          TCP
  18763 > http [RST, ACK] Seq=818 Ack=2802 Win=0 Len=0


===Stream 2===
No.     Time        Source                Destination           Protocol Info
  29059 10.157730   81.144.251.100        192.168.0.35          TCP
  46174 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1380
  29060 10.157765   192.168.0.35          81.144.251.100        TCP
  http > 46174 [SYN, ACK] Seq=0 Ack=1 Win=64860 Len=0 MSS=1460
  29115 10.174576   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
  29116 10.174716   81.144.251.100        192.168.0.35          HTTP
  GET /i/home/inthepress/inthepress_22ctvodka.jpg HTTP/1.0
  29118 10.174750   192.168.0.35          81.144.251.100        TCP
  http > 46174 [ACK] Seq=1 Ack=598 Win=64860 Len=0
  29120 10.174847   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29121 10.174888   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29156 10.183128   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=598 Ack=1567 Win=65535 Len=0
  29157 10.183144   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29158 10.183156   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29159 10.183166   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29177 10.190576   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=598 Ack=5707 Win=65535 Len=0
  29178 10.190593   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29179 10.190604   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29180 10.190615   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29181 10.190624   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29200 10.197563   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=598 Ack=9847 Win=65535 Len=0
  29201 10.197580   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29202 10.197592   192.168.0.35          81.144.251.100        HTTP
  HTTP/1.1 200 OK  (JPEG JFIF image)
  29225 10.205114   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=598 Ack=12766 Win=65535 Len=0
  29305 10.232454   81.144.251.100        192.168.0.35          HTTP
  GET /i/home/inthepress/inthepress_cuvee.jpg HTTP/1.0
  29306 10.232469   192.168.0.35          81.144.251.100        TCP
  http > 46174 [ACK] Seq=12766 Ack=1414 Win=64860 Len=0
  29307 10.232648   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29309 10.232682   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29310 10.232695   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29311 10.232705   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29312 10.232716   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29313 10.232726   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29367 10.251798   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1414 Ack=15712 Win=65535 Len=0
  29368 10.251906   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29369 10.251925   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29370 10.251937   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29371 10.251949   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29378 10.252476   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1414 Ack=18472 Win=65535 Len=0
  29379 10.252496   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29380 10.252508   192.168.0.35          81.144.251.100        TCP
  [TCP segment of a reassembled PDU]
  29381 10.252517   192.168.0.35          81.144.251.100        HTTP
  HTTP/1.1 200 OK  (JPEG JFIF image)
  29382 10.253163   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1414 Ack=19852 Win=65535 Len=0
  29410 10.261167   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1414 Ack=22612 Win=65535 Len=0
  29411 10.261172   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1414 Ack=26752 Win=65535 Len=0
  29412 10.261176   81.144.251.100        192.168.0.35          TCP
  46174 > http [ACK] Seq=1414 Ack=28490 Win=65535 Len=0
  29555 10.292370   81.144.251.100        192.168.0.35          TCP
  46174 > http [RST, ACK] Seq=1414 Ack=28490 Win=0 Len=0


From phk at phk.freebsd.dk  Fri Feb 12 12:37:56 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Feb 2010 12:37:56 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Fri, 12 Feb 2010 12:17:59 GMT."
	<282e72051002120417w6c8ce8bcha2c96a809e9badc1@mail.gmail.com> 
Message-ID: <43513.1265978276@critter.freebsd.dk>

In message <282e72051002120417w6c8ce8bcha2c96a809e9badc1 at mail.gmail.com>, Paul 
Wright writes:

>> If so: how long time elapses between the ACK and the RST ?
>
>0.031s

Interesting.

Can you try to run with this patch:

http://phk.freebsd.dk/misc/poll.patch

And see what values it puts in your varnishlog for these connections ?

I wonder if Solaris has some kind of "I already told you it were
closed once" logic...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From john at 7fff.com  Fri Feb 12 15:50:55 2010
From: john at 7fff.com (John Norman)
Date: Fri, 12 Feb 2010 10:50:55 -0500
Subject: Not seeing a successful purge
In-Reply-To: <e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
Message-ID: <b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>

Thanks, Laurence. But . . .

Am I misreading the varnishlog I quoted? The Accept-Encoding headers
seem both to contain gzip:

Here's the Accept-Encoding from the browser:

4 RxHeader     c Accept-Encoding: gzip,deflate

Here it is from the PURGE:

4 RxHeader     c Accept-Encoding: gzip,identity

(Both quoted from my original message.)

They both contain gzip, so the hash should be the URL + gzip:

sub vcl_hash {
  set req.hash += req.url;

  if (req.http.Accept-Encoding ~ "gzip") {
    set req.hash += "gzip";
  } else if (req.http.Accept-Encoding ~ "deflate") {
    set req.hash += "deflate";
  }
  return (hash);
}

So, I'm still not seeing why the purge isn't hitting:

>From the browser's GET:

4 VCL_return   c hash
4 Hit          c 904319089
4 VCL_call     c hit
4 VCL_return   c deliver

>From the PURGE request:

4 VCL_call     c hash
4 VCL_return   c hash
4 VCL_call     c miss
0 Debug        - "VCL_error(404, Not in cache.)"

On Fri, Feb 12, 2010 at 5:49 AM, Laurence Rowe <l at lrowe.co.uk> wrote:
> Hi,
>
> Your PURGE request is getting a different hash than your browser
> requests because there is no Accept-Encoding header on the PURGE. (You
> see the same problem when using Vary on the response). See
> http://varnish-cache.org/wiki/Purging. You can either use <<
> purge("req.url ~ " req.url); >> in vcl_recv, or send multiple PURGE
> requests with each of the relavant Accept-Encoding values.
>
> Laurence
>
> On 11 February 2010 23:25, John Norman <john at 7fff.com> wrote:
>> Hi, folks.
>>
>> I'm trying to purge with the pseudo HTTP "PURGE" method Varnish supports.
>>
>> I do seem to have a cached page, but the PURGE response suggests that
>> it's missing.
>>
>> So . . . any idea why the PURGE isn't working?
>>
>> In my VCL, my vcl_hash looks like this (I intend it to only hash on
>> the request URL and compression):
>>
>> sub vcl_hash {
>> ?set req.hash += req.url;
>>
>> ?if (req.http.Accept-Encoding ~ "gzip") {
>> ? ?set req.hash += "gzip";
>> ?} else if (req.http.Accept-Encoding ~ "deflate") {
>> ? ?set req.hash += "deflate";
>> ?}
>> ?return (hash);
>> }
>>
>> And the checks for PURGE look like this (full VCL way below):
>>
>> sub vcl_hit {
>> ?if (req.request == "PURGE") {
>> ? ?set obj.ttl = 0s;
>> ? ?error 200 "Purged.";
>> ?}
>> ?if (!obj.cacheable) {
>> ? ?pass;
>> ?}
>>
>> ?deliver;
>> }
>> sub vcl_miss {
>> ?if (req.request == "PURGE") {
>> ? ?error 404 "Not in cache.";
>> ?}
>> }
>>
>> And in vcl_recv:
>>
>> ?if (req.request == "PURGE") {
>> ? ?lookup;
>> ?}
>


From john at 7fff.com  Fri Feb 12 16:54:52 2010
From: john at 7fff.com (John Norman)
Date: Fri, 12 Feb 2010 11:54:52 -0500
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
Message-ID: <b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>

Here's a bit more on my "purge" problem -- a comparison of a purge
that works on my development machine, vs. one that doesn't work on my
staging system.

On both, the browser request goes to haproxy, then to varnish. The VCL
is identical, as quoted in a prior e-mail. The backends are different:
on my local, it's the Ruby webrick server; on staging, it's
Apache+Passenger.

Again, I'm not purging through varnishadm: This is using the
pseudo-http-method PURGE.

One thing I can say about the staging environment if that if I do a
non-browser request using mechanize from the staging system itself,
then the later purge DOES work. In that case, the two differences are:
The user-agent is the same for both the get and the purge; and
requesting IP would be the same for both the get and the purge.

Here are the log details.

DEVELOPMENT -- first the browser request, showing the hit; then the
purge, showing the hit. Awesome!

11 ReqStart     c 127.0.0.1 50808 1691945259
11 RxRequest    c GET
11 RxURL        c /products/sillyputty
11 RxProtocol   c HTTP/1.1
11 RxHeader     c Host: localhost
11 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
X 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
11 RxHeader     c Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
11 RxHeader     c Accept-Language: en-us,en;q=0.5
11 RxHeader     c Accept-Encoding: gzip,deflate
11 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
11 RxHeader     c Keep-Alive: 300
11 RxHeader     c Connection: close
11 RxHeader     c Referer: http://localhost/
11 RxHeader     c Cookie:
remember_token=f27172bfab54dc47d20b6d8c853afb8677fa2d11
11 RxHeader     c X-Forwarded-For: 127.0.0.1
11 VCL_call     c recv
11 VCL_return   c lookup
11 VCL_call     c hash
11 VCL_return   c hash
11 Hit          c 1691945214
11 VCL_call     c hit
11 VCL_return   c deliver
11 Length       c 201518
11 VCL_call     c deliver
11 VCL_return   c deliver
11 TxProtocol   c HTTP/1.1
11 TxStatus     c 200
11 TxResponse   c OK
11 TxHeader     c Cache-Control: max-age=8280, public
11 TxHeader     c X-Runtime: 818
11 TxHeader     c Content-Type: text/html; charset=utf-8
11 TxHeader     c Etag: "f29fbc0160d276fb97a298bf5bce8ff3"
11 TxHeader     c Server: WEBrick/1.3.1 (Ruby/1.9.1/2009-07-16)
11 TxHeader     c Content-Length: 201518
11 TxHeader     c Date: Fri, 12 Feb 2010 16:19:33 GMT
11 TxHeader     c X-Varnish: 1691945259 1691945214
11 TxHeader     c Age: 14
11 TxHeader     c Via: 1.1 varnish
11 TxHeader     c Connection: close
11 ReqEnd       c 1691945259 1265991573.541040897 1265991573.547173977
0.000077009 0.000055075 0.006078005

11 ReqStart     c ::1 51006 1691945309
11 RxRequest    c PURGE
11 RxURL        c /products/sillyputty
11 RxProtocol   c HTTP/1.1
11 RxHeader     c Accept: */*
11 RxHeader     c User-Agent: WWW-Mechanize/1.0.0
(http://rubyforge.org/projects/mechanize/)
11 RxHeader     c Connection: keep-alive
11 RxHeader     c Keep-Alive: 300
11 RxHeader     c Accept-Encoding: gzip,identity
11 RxHeader     c Accept-Language: en-us,en;q=0.5
11 RxHeader     c Host: localhost:8000
11 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
11 VCL_call     c recv
11 VCL_return   c lookup
11 VCL_call     c hash
11 VCL_return   c hash
11 Hit          c 1691945214
11 VCL_call     c hit
11 TTL          c 1691945214 VCL 0 1265991617
 0 Debug        - "VCL_error(200, Purged.)"
11 VCL_return   c error
11 VCL_call     c error
11 VCL_return   c deliver
11 Length       c 322
11 VCL_call     c deliver
11 VCL_return   c deliver
11 TxProtocol   c HTTP/1.1
11 TxStatus     c 200
11 TxResponse   c Purged.
11 TxHeader     c Server: Varnish
11 TxHeader     c Retry-After: 0
11 TxHeader     c Content-Type: text/html; charset=utf-8
11 TxHeader     c Content-Length: 322
11 TxHeader     c Date: Fri, 12 Feb 2010 16:20:16 GMT
11 TxHeader     c X-Varnish: 1691945309
11 TxHeader     c Age: 0
11 TxHeader     c Via: 1.1 varnish
11 TxHeader     c Connection: close
11 ReqEnd       c 1691945309 1265991616.884471893 1265991616.884622097
0.000173807 0.000099182 0.000051022

---------------------------------------

Now my problematic STAGING system -- first the GET with the hit, then
the purge that fails to hit.

4 ReqStart     c 10.253.191.95 45944 904319331
4 RxRequest    c GET
4 RxURL        c /products/sillyputty
4 RxProtocol   c HTTP/1.1
4 RxHeader     c Host: staging1.example.com
4 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
4 RxHeader     c Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
4 RxHeader     c Accept-Language: en-us,en;q=0.5
4 RxHeader     c Accept-Encoding: gzip,deflate
4 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
4 RxHeader     c Keep-Alive: 300
4 RxHeader     c Connection: keep-alive
4 RxHeader     c Referer: http://staging1.example.com/
4 RxHeader     c Cookie: cehq-id=10.252.66.194.1263417178788050;
__utma=240927894.185175319.1263417179.1265907679.1265923273.61;
__utmz=240927894.1263591912.11.2.utmcsr=localhost:3000|utmccn=(referral)|utmcmd=referral|utmcct=/;
__utma=229000926.194920698.1263480064.126592
4 RxHeader     c X-Forwarded-For: 75.150.106.113
4 VCL_call     c recv
4 VCL_return   c lookup
4 VCL_call     c hash
4 VCL_return   c hash
4 Hit          c 904319258
4 VCL_call     c hit
4 VCL_return   c deliver
4 Length       c 8471
4 VCL_call     c deliver
4 VCL_return   c deliver
4 TxProtocol   c HTTP/1.1
4 TxStatus     c 200
4 TxResponse   c OK
4 TxHeader     c Server: Apache/2.2.12 (Ubuntu)
4 TxHeader     c X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.9
4 TxHeader     c Cache-Control: max-age=8520, public
4 TxHeader     c X-Runtime: 6052
4 TxHeader     c ETag: "94c1d0e1f26f0117dfc9bf3573a39f5a"
4 TxHeader     c Status: 200
4 TxHeader     c Vary: Accept-Encoding,User-Agent
4 TxHeader     c Content-Encoding: gzip
4 TxHeader     c Content-Type: text/html; charset=utf-8
4 TxHeader     c Content-Length: 8471
4 TxHeader     c Date: Fri, 12 Feb 2010 16:07:58 GMT
4 TxHeader     c X-Varnish: 904319331 904319258
4 TxHeader     c Age: 180
4 TxHeader     c Via: 1.1 varnish
4 TxHeader     c Connection: keep-alive
4 ReqEnd       c 904319331 1265990878.630007267 1265990878.630154371
0.000055075 0.000094652 0.000052452


4 ReqStart     c 10.253.191.95 38696 904319371
4 RxRequest    c PURGE
4 RxURL        c /products/sillyputty
4 RxProtocol   c HTTP/1.1
4 RxHeader     c Accept: */*
4 RxHeader     c User-Agent: WWW-Mechanize/1.0.0
(http://rubyforge.org/projects/mechanize/)
4 RxHeader     c Connection: keep-alive
4 RxHeader     c Keep-Alive: 300
4 RxHeader     c Accept-Encoding: gzip,identity
4 RxHeader     c Accept-Language: en-us,en;q=0.5
4 RxHeader     c Host: staging1.example.com:8000
4 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
4 VCL_call     c recv
4 VCL_return   c lookup
4 VCL_call     c hash
4 VCL_return   c hash
4 VCL_call     c miss
0 Debug        - "VCL_error(404, Not in cache.)"
4 VCL_return   c error
4 VCL_call     c error
4 VCL_return   c deliver
4 Length       c 340
4 VCL_call     c deliver
4 VCL_return   c deliver
4 TxProtocol   c HTTP/1.1
4 TxStatus     c 404
4 TxResponse   c Not in cache.
4 TxHeader     c Server: Varnish
4 TxHeader     c Retry-After: 0
4 TxHeader     c Content-Type: text/html; charset=utf-8
4 TxHeader     c Content-Length: 340
4 TxHeader     c Date: Fri, 12 Feb 2010 16:09:58 GMT
4 TxHeader     c X-Varnish: 904319371
4 TxHeader     c Age: 0
4 TxHeader     c Via: 1.1 varnish
4 TxHeader     c Connection: close
4 ReqEnd       c 904319371 1265990998.368539810 1265990998.368721724
0.000052691 0.000142813 0.000039101


From wrighty+varnishmisc at gmail.com  Fri Feb 12 17:49:39 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Fri, 12 Feb 2010 17:49:39 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <43513.1265978276@critter.freebsd.dk>
References: <282e72051002120417w6c8ce8bcha2c96a809e9badc1@mail.gmail.com>
	<43513.1265978276@critter.freebsd.dk>
Message-ID: <282e72051002120949u56eb6914mbd55e5a355931a38@mail.gmail.com>

On 12 February 2010 12:37, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002120417w6c8ce8bcha2c96a809e9badc1 at mail.gmail.com>, Paul
> Wright writes:
>
>>> If so: how long time elapses between the ACK and the RST ?
>>
>>0.031s
>
> Interesting.
>
> Can you try to run with this patch:
>
> http://phk.freebsd.dk/misc/poll.patch
>
> And see what values it puts in your varnishlog for these connections ?
>
> I wonder if Solaris has some kind of "I already told you it were
> closed once" logic...

Here's a snippet from varnishlog for one of these panics (also
attached to this email in case line wraps wreck formatting):

  143 ReqEnd       c 1290159921 1265995548.765989065
1265995548.766152620 0.394018888 0.000070572 0.000092983
  143 Debug        c "herding"
  143 Debug        c "Poll: 1 / 1"
  143 ReqStart     c 78.105.40.8 54467 1290159956
  143 RxRequest    c GET
  143 RxURL        c /i/template/2009/footer_bottom.gif
  143 RxProtocol   c HTTP/1.1
  143 RxHeader     c Accept: */*
  143 RxHeader     c Referer: http://www.firebox.com/?aff=1661
  143 RxHeader     c Accept-Language: en-GB
  143 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 8.0;
Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR
3.5.30729; .NET CLR 3.0.30729)
  143 RxHeader     c Accept-Encoding: gzip, deflate
  143 RxHeader     c Host: media1.firebox.com
  143 RxHeader     c Connection: Keep-Alive
  143 RxHeader     c Cookie: user_session=XXXX;
locale=company_id%3A0%2Ccurrency_id%3A0%2Clanguage_id%3A0%2Ccountry%3AUnited+Kingdom;
xp_list=52%3D1; LS_timeEntered=2010-02-12+17%3A25%3A45;
LS_siteID=9zbw6_pUJdo-CEmBfO.mTMjnl23RueBRWg; intl_aff=111
  143 VCL_call     c recv
  143 VCL_return   c lookup
  143 VCL_call     c hash
  143 VCL_return   c hash
  143 Hit          c 1290147201
  143 VCL_call     c hit
  143 VCL_return   c deliver
  143 Length       c 256
  143 VCL_call     c deliver
  143 VCL_return   c deliver
  143 TxProtocol   c HTTP/1.1
  143 TxStatus     c 200
  143 TxResponse   c OK
  143 TxHeader     c Server: Apache
  143 TxHeader     c Last-Modified: Mon, 11 May 2009 10:47:04 GMT
  143 TxHeader     c ETag: "ae80a9-100-469a0b2e6da00"
  143 TxHeader     c Cache-Control: max-age=2592000
  143 TxHeader     c Expires: Sun, 14 Mar 2010 17:22:56 GMT
  143 TxHeader     c Content-Type: image/gif
  143 TxHeader     c Content-Length: 256
  143 TxHeader     c Date: Fri, 12 Feb 2010 17:25:49 GMT
  143 TxHeader     c X-Varnish: 1290159956 1290147201
  143 TxHeader     c Age: 172
  143 TxHeader     c Via: 1.1 varnish
  143 TxHeader     c Connection: keep-alive
  143 ReqEnd       c 1290159956 1265995549.060598135
1265995549.060703278 0.294445515 0.000055552 0.000049591

Child (19545) died signal=6
Child (19545) Panic message: Assert error in TCP_nonblocking(), tcp.c line 172:
  Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
(int))&0xff)<<16)| ('f'<<8)|126))), &i)) == 0) not true.
errno = 9 (Bad file number)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  4454cb: /opt/sbin/varnishd'pan_backtrace+0x1b [0x4454cb]
  4457d5: /opt/sbin/varnishd'pan_ic+0x1c5 [0x4457d5]
  fffffd7ff2fcdfec: /opt/lib/libvarnish.so.1.0.0'TCP_nonblocking+0x7c
[0xfffffd7ff2fcdfec]
  419091: /opt/sbin/varnishd'vca_return_session+0x1b1 [0x419091]
  42679d: /opt/sbin/varnishd'cnt_wait+0x2bd [0x42679d]
  42b98a: /opt/sbin/varnishd'CNT_Session+0x4ba [0x42b98a]
  44805b: /opt/sbin/varnishd'wrk_do_cnt_sess+0x19b [0x44805b]
  447654: /opt/sbin/varnishd'wrk_thread_real+0x854 [0x447654]
  447bb3: /opt/sbin/varnishd'wrk_thread+0x123 [0x447bb3]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = c84b38 {
  fd = 143, id = 143, xid = 0,
  client = 78.105.40.8:54467,
  step = STP_WAIT,
  handling = deliver,
  restarts = 0, esis = 0
  ws = c84ba8 {
    id = "sess",
    {s,f,r,e} = {c858b0,+18,+32786,+65536},
  },
  http[req] = {
    ws = c84ba8[sess]
      "",
      "/i/template/2009/footer_bottom.gif",
      "HTTP/1.1",
      "Accept: */*",
      "Referer: http://www.firebox.com/?aff=1661",
      "Accept-Language: en-GB",
      "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1;
Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR
3.0.30729)",
      "Accept-Encoding: gzip, deflate",
      "Connection: Keep-Alive",
      "host: media.firebox.com",
      "X-Forwarded-For: 78.105.40.8",
  },
},

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: varnish_child.143.log
Type: application/octet-stream
Size: 3779 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100212/4719c7e7/attachment.obj>

From phk at phk.freebsd.dk  Fri Feb 12 18:26:18 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Feb 2010 18:26:18 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Fri, 12 Feb 2010 17:49:39 GMT."
	<282e72051002120949u56eb6914mbd55e5a355931a38@mail.gmail.com> 
Message-ID: <89581.1265999178@critter.freebsd.dk>

In message <282e72051002120949u56eb6914mbd55e5a355931a38 at mail.gmail.com>, Paul 
Wright writes:

>> I wonder if Solaris has some kind of "I already told you it were
>> closed once" logic...
>
>Here's a snippet from varnishlog for one of these panics (also
>attached to this email in case line wraps wreck formatting):

Interesting!

This time the EBADF comes in the original worker thread, before we
hand the file descriptor over to the waiter, eliminating that entire
ball of wax from the picture.

>  419091: /opt/sbin/varnishd'vca_return_session+0x1b1 [0x419091]
>  42679d: /opt/sbin/varnishd'cnt_wait+0x2bd [0x42679d]

I can find absolutely no trace of EBADF meaning "remote end closed"
in the Solaris docs or other docs on the web, but that as far as I
can tell that is indeed what happens here.

But as a kernel programmer, I can see where this might come from:

Receiving a TCP-RST means that the socket is never going to be
useful again.  Since you already have the socket/pcb locked, taking
it entirely out of its missery right away is cheap and more efficient,
than waiting for the process to notice and issue a close(2) on it,
and then have to relock the socket/pcb again etc. etc.

Next time you try to use the filedescriptor, there is no socket
and EBADF ensues.

Reasoning that most programs notice the return value, and call
strerror(3) not caring very much what the exact value of errno
is, you can get away with returning EBADF.

Varnish however, is written my a cranky old FreeBSD kernel hacker,
who has no pretentions about writing correct code the first time,
so 10% of the lines are asserts and yes I actually _do_ care about
the specific errno's returned.

And EBADF is not just any errorcode, it is the only errno which
has universally been recognized as meaning "programmer screwed up",
because you can only get it if you muck up your filedescriptors.

Or as one of the first hits Google gave me, when researching this
more politely but no less firmly describes it:

	Bad file number (EBADF): The file descriptor references a
	file that is either not open or is open for a conflicting
	purpose. (eg, a read(2) is specified against a file that
	is open for write(2) or vice-versa.) This is a programming
	bug.

	(http://www.princeton.edu/~unix/Solaris/troubleshoot/error.html)

If I had implemented the hack I suspect Solaris contains, I would
have found some bit somewhere, to make sure the errno would be the
correct, documented and expected:

	#define ECONNRESET      54     /* Connection reset by peer */

Somebody with a Solaris service contract, if such things still
exist, should report this as a bug to them...

I will add a workaround to Varnish, with a suitable sarcastic
commentary...

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From john at 7fff.com  Fri Feb 12 18:44:19 2010
From: john at 7fff.com (John Norman)
Date: Fri, 12 Feb 2010 13:44:19 -0500
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
	<b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
Message-ID: <b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>

I think it's the backend's (Apache/Passenger) header:

    Vary: Accept-Encoding,User-Agent

Which seems to prevent (???) this from working in my vcl_hash:

  if (req.http.Accept-Encoding ~ "gzip") {
    set req.hash += "gzip";
  } // etc

The Varnish doc says: "But by default, Varnish will perform no
transforms on the headers singled out by Vary: for comparison"
(http://varnish-cache.org/wiki/ArchitectureVary).

So . . . I'm not sure what I should do. If the backend says "Vary" for
Accept-Encoding, does that mean that I should or should not be able to
access that header for the purposes of setting the hash?

What I am observing is:

browser makes request with Accept-Encoding: gzip,deflate

When I try to purge, the request with the purge says: Accept-Encoding:
gzip,identity

Even though "gzip" is in the request for both the browser
Accept-Encoding, and for the purge, they seem to be getting hashed
differently.

If when I do a purge, I force Accept-Encoding: gzip,deflate, then it
matches what the browser did exactly, and I am able to purge
successfully.

On Fri, Feb 12, 2010 at 11:54 AM, John Norman <john at 7fff.com> wrote:
> Here's a bit more on my "purge" problem -- a comparison of a purge
> that works on my development machine, vs. one that doesn't work on my
> staging system.
>
> On both, the browser request goes to haproxy, then to varnish. The VCL
> is identical, as quoted in a prior e-mail. The backends are different:
> on my local, it's the Ruby webrick server; on staging, it's
> Apache+Passenger.
>
> Again, I'm not purging through varnishadm: This is using the
> pseudo-http-method PURGE.
>
> One thing I can say about the staging environment if that if I do a
> non-browser request using mechanize from the staging system itself,
> then the later purge DOES work. In that case, the two differences are:
> The user-agent is the same for both the get and the purge; and
> requesting IP would be the same for both the get and the purge.
>
> Here are the log details.
>
> DEVELOPMENT -- first the browser request, showing the hit; then the
> purge, showing the hit. Awesome!
>
> 11 ReqStart ? ? c 127.0.0.1 50808 1691945259
> 11 RxRequest ? ?c GET
> 11 RxURL ? ? ? ?c /products/sillyputty
> 11 RxProtocol ? c HTTP/1.1
> 11 RxHeader ? ? c Host: localhost
> 11 RxHeader ? ? c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
> X 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
> 11 RxHeader ? ? c Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> 11 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
> 11 RxHeader ? ? c Accept-Encoding: gzip,deflate
> 11 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> 11 RxHeader ? ? c Keep-Alive: 300
> 11 RxHeader ? ? c Connection: close
> 11 RxHeader ? ? c Referer: http://localhost/
> 11 RxHeader ? ? c Cookie:
> remember_token=f27172bfab54dc47d20b6d8c853afb8677fa2d11
> 11 RxHeader ? ? c X-Forwarded-For: 127.0.0.1
> 11 VCL_call ? ? c recv
> 11 VCL_return ? c lookup
> 11 VCL_call ? ? c hash
> 11 VCL_return ? c hash
> 11 Hit ? ? ? ? ?c 1691945214
> 11 VCL_call ? ? c hit
> 11 VCL_return ? c deliver
> 11 Length ? ? ? c 201518
> 11 VCL_call ? ? c deliver
> 11 VCL_return ? c deliver
> 11 TxProtocol ? c HTTP/1.1
> 11 TxStatus ? ? c 200
> 11 TxResponse ? c OK
> 11 TxHeader ? ? c Cache-Control: max-age=8280, public
> 11 TxHeader ? ? c X-Runtime: 818
> 11 TxHeader ? ? c Content-Type: text/html; charset=utf-8
> 11 TxHeader ? ? c Etag: "f29fbc0160d276fb97a298bf5bce8ff3"
> 11 TxHeader ? ? c Server: WEBrick/1.3.1 (Ruby/1.9.1/2009-07-16)
> 11 TxHeader ? ? c Content-Length: 201518
> 11 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:19:33 GMT
> 11 TxHeader ? ? c X-Varnish: 1691945259 1691945214
> 11 TxHeader ? ? c Age: 14
> 11 TxHeader ? ? c Via: 1.1 varnish
> 11 TxHeader ? ? c Connection: close
> 11 ReqEnd ? ? ? c 1691945259 1265991573.541040897 1265991573.547173977
> 0.000077009 0.000055075 0.006078005
>
> 11 ReqStart ? ? c ::1 51006 1691945309
> 11 RxRequest ? ?c PURGE
> 11 RxURL ? ? ? ?c /products/sillyputty
> 11 RxProtocol ? c HTTP/1.1
> 11 RxHeader ? ? c Accept: */*
> 11 RxHeader ? ? c User-Agent: WWW-Mechanize/1.0.0
> (http://rubyforge.org/projects/mechanize/)
> 11 RxHeader ? ? c Connection: keep-alive
> 11 RxHeader ? ? c Keep-Alive: 300
> 11 RxHeader ? ? c Accept-Encoding: gzip,identity
> 11 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
> 11 RxHeader ? ? c Host: localhost:8000
> 11 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> 11 VCL_call ? ? c recv
> 11 VCL_return ? c lookup
> 11 VCL_call ? ? c hash
> 11 VCL_return ? c hash
> 11 Hit ? ? ? ? ?c 1691945214
> 11 VCL_call ? ? c hit
> 11 TTL ? ? ? ? ?c 1691945214 VCL 0 1265991617
> ?0 Debug ? ? ? ?- "VCL_error(200, Purged.)"
> 11 VCL_return ? c error
> 11 VCL_call ? ? c error
> 11 VCL_return ? c deliver
> 11 Length ? ? ? c 322
> 11 VCL_call ? ? c deliver
> 11 VCL_return ? c deliver
> 11 TxProtocol ? c HTTP/1.1
> 11 TxStatus ? ? c 200
> 11 TxResponse ? c Purged.
> 11 TxHeader ? ? c Server: Varnish
> 11 TxHeader ? ? c Retry-After: 0
> 11 TxHeader ? ? c Content-Type: text/html; charset=utf-8
> 11 TxHeader ? ? c Content-Length: 322
> 11 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:20:16 GMT
> 11 TxHeader ? ? c X-Varnish: 1691945309
> 11 TxHeader ? ? c Age: 0
> 11 TxHeader ? ? c Via: 1.1 varnish
> 11 TxHeader ? ? c Connection: close
> 11 ReqEnd ? ? ? c 1691945309 1265991616.884471893 1265991616.884622097
> 0.000173807 0.000099182 0.000051022
>
> ---------------------------------------
>
> Now my problematic STAGING system -- first the GET with the hit, then
> the purge that fails to hit.
>
> 4 ReqStart ? ? c 10.253.191.95 45944 904319331
> 4 RxRequest ? ?c GET
> 4 RxURL ? ? ? ?c /products/sillyputty
> 4 RxProtocol ? c HTTP/1.1
> 4 RxHeader ? ? c Host: staging1.example.com
> 4 RxHeader ? ? c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
> 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
> 4 RxHeader ? ? c Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> 4 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
> 4 RxHeader ? ? c Accept-Encoding: gzip,deflate
> 4 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> 4 RxHeader ? ? c Keep-Alive: 300
> 4 RxHeader ? ? c Connection: keep-alive
> 4 RxHeader ? ? c Referer: http://staging1.example.com/
> 4 RxHeader ? ? c Cookie: cehq-id=10.252.66.194.1263417178788050;
> __utma=240927894.185175319.1263417179.1265907679.1265923273.61;
> __utmz=240927894.1263591912.11.2.utmcsr=localhost:3000|utmccn=(referral)|utmcmd=referral|utmcct=/;
> __utma=229000926.194920698.1263480064.126592
> 4 RxHeader ? ? c X-Forwarded-For: 75.150.106.113
> 4 VCL_call ? ? c recv
> 4 VCL_return ? c lookup
> 4 VCL_call ? ? c hash
> 4 VCL_return ? c hash
> 4 Hit ? ? ? ? ?c 904319258
> 4 VCL_call ? ? c hit
> 4 VCL_return ? c deliver
> 4 Length ? ? ? c 8471
> 4 VCL_call ? ? c deliver
> 4 VCL_return ? c deliver
> 4 TxProtocol ? c HTTP/1.1
> 4 TxStatus ? ? c 200
> 4 TxResponse ? c OK
> 4 TxHeader ? ? c Server: Apache/2.2.12 (Ubuntu)
> 4 TxHeader ? ? c X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.9
> 4 TxHeader ? ? c Cache-Control: max-age=8520, public
> 4 TxHeader ? ? c X-Runtime: 6052
> 4 TxHeader ? ? c ETag: "94c1d0e1f26f0117dfc9bf3573a39f5a"
> 4 TxHeader ? ? c Status: 200
> 4 TxHeader ? ? c Vary: Accept-Encoding,User-Agent
> 4 TxHeader ? ? c Content-Encoding: gzip
> 4 TxHeader ? ? c Content-Type: text/html; charset=utf-8
> 4 TxHeader ? ? c Content-Length: 8471
> 4 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:07:58 GMT
> 4 TxHeader ? ? c X-Varnish: 904319331 904319258
> 4 TxHeader ? ? c Age: 180
> 4 TxHeader ? ? c Via: 1.1 varnish
> 4 TxHeader ? ? c Connection: keep-alive
> 4 ReqEnd ? ? ? c 904319331 1265990878.630007267 1265990878.630154371
> 0.000055075 0.000094652 0.000052452
>
>
> 4 ReqStart ? ? c 10.253.191.95 38696 904319371
> 4 RxRequest ? ?c PURGE
> 4 RxURL ? ? ? ?c /products/sillyputty
> 4 RxProtocol ? c HTTP/1.1
> 4 RxHeader ? ? c Accept: */*
> 4 RxHeader ? ? c User-Agent: WWW-Mechanize/1.0.0
> (http://rubyforge.org/projects/mechanize/)
> 4 RxHeader ? ? c Connection: keep-alive
> 4 RxHeader ? ? c Keep-Alive: 300
> 4 RxHeader ? ? c Accept-Encoding: gzip,identity
> 4 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
> 4 RxHeader ? ? c Host: staging1.example.com:8000
> 4 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> 4 VCL_call ? ? c recv
> 4 VCL_return ? c lookup
> 4 VCL_call ? ? c hash
> 4 VCL_return ? c hash
> 4 VCL_call ? ? c miss
> 0 Debug ? ? ? ?- "VCL_error(404, Not in cache.)"
> 4 VCL_return ? c error
> 4 VCL_call ? ? c error
> 4 VCL_return ? c deliver
> 4 Length ? ? ? c 340
> 4 VCL_call ? ? c deliver
> 4 VCL_return ? c deliver
> 4 TxProtocol ? c HTTP/1.1
> 4 TxStatus ? ? c 404
> 4 TxResponse ? c Not in cache.
> 4 TxHeader ? ? c Server: Varnish
> 4 TxHeader ? ? c Retry-After: 0
> 4 TxHeader ? ? c Content-Type: text/html; charset=utf-8
> 4 TxHeader ? ? c Content-Length: 340
> 4 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:09:58 GMT
> 4 TxHeader ? ? c X-Varnish: 904319371
> 4 TxHeader ? ? c Age: 0
> 4 TxHeader ? ? c Via: 1.1 varnish
> 4 TxHeader ? ? c Connection: close
> 4 ReqEnd ? ? ? c 904319371 1265990998.368539810 1265990998.368721724
> 0.000052691 0.000142813 0.000039101
>


From michael at dynamine.net  Fri Feb 12 20:20:40 2010
From: michael at dynamine.net (Michael Fischer)
Date: Fri, 12 Feb 2010 12:20:40 -0800
Subject: Child panics on OpenSolaris
In-Reply-To: <89581.1265999178@critter.freebsd.dk>
References: <282e72051002120949u56eb6914mbd55e5a355931a38@mail.gmail.com>
	<89581.1265999178@critter.freebsd.dk>
Message-ID: <d002c4031002121220r6cfbd012u35ae128a43f69ffc@mail.gmail.com>

On Fri, Feb 12, 2010 at 10:26 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

I can find absolutely no trace of EBADF meaning "remote end closed"
> in the Solaris docs or other docs on the web, but that as far as I
> can tell that is indeed what happens here.
>

Source code is at http://src.opensolaris.org/source/ if you feel like
digging through it.


> If I had implemented the hack I suspect Solaris contains, I would
> have found some bit somewhere, to make sure the errno would be the
> correct, documented and expected:
>
>        #define ECONNRESET      54     /* Connection reset by peer */
>
> Somebody with a Solaris service contract, if such things still
> exist, should report this as a bug to them...


I have a feeling such a change will be nontrivial because TCP is implemented
under STREAMS under Solaris.  I don't intend to discourage anyone from
trying, though.

--Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100212/9516f31f/attachment.html>

From kb+varnish at slide.com  Fri Feb 12 23:22:24 2010
From: kb+varnish at slide.com (Ken Brownfield)
Date: Fri, 12 Feb 2010 15:22:24 -0800
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
	<b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
	<b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
Message-ID: <AF78DE27-54BE-44F0-88E1-3C61FEDBDF8C@slide.com>

For any cache, not just Varnish, the Accept-Encoding header used for the purge (or a regular cache hit) must match the request header /exactly/.  If you use anything other than exactly "Accept-Encoding: gzip,deflate" your purge will miss.  So this is the expected behavior, AFAIK.

Any other header specified in Vary must also match exactly for a hit (and optional purge) to occur.

You could do some hashing hacks to augment the standard functionality, but it might become a bit of a mess.  I haven't needed to find out, though.
-- 
Ken

On Feb 12, 2010, at 10:44 AM, John Norman wrote:

> I think it's the backend's (Apache/Passenger) header:
> 
>    Vary: Accept-Encoding,User-Agent
> 
> Which seems to prevent (???) this from working in my vcl_hash:
> 
>  if (req.http.Accept-Encoding ~ "gzip") {
>    set req.hash += "gzip";
>  } // etc
> 
> The Varnish doc says: "But by default, Varnish will perform no
> transforms on the headers singled out by Vary: for comparison"
> (http://varnish-cache.org/wiki/ArchitectureVary).
> 
> So . . . I'm not sure what I should do. If the backend says "Vary" for
> Accept-Encoding, does that mean that I should or should not be able to
> access that header for the purposes of setting the hash?
> 
> What I am observing is:
> 
> browser makes request with Accept-Encoding: gzip,deflate
> 
> When I try to purge, the request with the purge says: Accept-Encoding:
> gzip,identity
> 
> Even though "gzip" is in the request for both the browser
> Accept-Encoding, and for the purge, they seem to be getting hashed
> differently.
> 
> If when I do a purge, I force Accept-Encoding: gzip,deflate, then it
> matches what the browser did exactly, and I am able to purge
> successfully.
> 
> On Fri, Feb 12, 2010 at 11:54 AM, John Norman <john at 7fff.com> wrote:
>> Here's a bit more on my "purge" problem -- a comparison of a purge
>> that works on my development machine, vs. one that doesn't work on my
>> staging system.
>> 
>> On both, the browser request goes to haproxy, then to varnish. The VCL
>> is identical, as quoted in a prior e-mail. The backends are different:
>> on my local, it's the Ruby webrick server; on staging, it's
>> Apache+Passenger.
>> 
>> Again, I'm not purging through varnishadm: This is using the
>> pseudo-http-method PURGE.
>> 
>> One thing I can say about the staging environment if that if I do a
>> non-browser request using mechanize from the staging system itself,
>> then the later purge DOES work. In that case, the two differences are:
>> The user-agent is the same for both the get and the purge; and
>> requesting IP would be the same for both the get and the purge.
>> 
>> Here are the log details.
>> 
>> DEVELOPMENT -- first the browser request, showing the hit; then the
>> purge, showing the hit. Awesome!
>> 
>> 11 ReqStart     c 127.0.0.1 50808 1691945259
>> 11 RxRequest    c GET
>> 11 RxURL        c /products/sillyputty
>> 11 RxProtocol   c HTTP/1.1
>> 11 RxHeader     c Host: localhost
>> 11 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
>> X 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
>> 11 RxHeader     c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> 11 RxHeader     c Accept-Language: en-us,en;q=0.5
>> 11 RxHeader     c Accept-Encoding: gzip,deflate
>> 11 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 11 RxHeader     c Keep-Alive: 300
>> 11 RxHeader     c Connection: close
>> 11 RxHeader     c Referer: http://localhost/
>> 11 RxHeader     c Cookie:
>> remember_token=f27172bfab54dc47d20b6d8c853afb8677fa2d11
>> 11 RxHeader     c X-Forwarded-For: 127.0.0.1
>> 11 VCL_call     c recv
>> 11 VCL_return   c lookup
>> 11 VCL_call     c hash
>> 11 VCL_return   c hash
>> 11 Hit          c 1691945214
>> 11 VCL_call     c hit
>> 11 VCL_return   c deliver
>> 11 Length       c 201518
>> 11 VCL_call     c deliver
>> 11 VCL_return   c deliver
>> 11 TxProtocol   c HTTP/1.1
>> 11 TxStatus     c 200
>> 11 TxResponse   c OK
>> 11 TxHeader     c Cache-Control: max-age=8280, public
>> 11 TxHeader     c X-Runtime: 818
>> 11 TxHeader     c Content-Type: text/html; charset=utf-8
>> 11 TxHeader     c Etag: "f29fbc0160d276fb97a298bf5bce8ff3"
>> 11 TxHeader     c Server: WEBrick/1.3.1 (Ruby/1.9.1/2009-07-16)
>> 11 TxHeader     c Content-Length: 201518
>> 11 TxHeader     c Date: Fri, 12 Feb 2010 16:19:33 GMT
>> 11 TxHeader     c X-Varnish: 1691945259 1691945214
>> 11 TxHeader     c Age: 14
>> 11 TxHeader     c Via: 1.1 varnish
>> 11 TxHeader     c Connection: close
>> 11 ReqEnd       c 1691945259 1265991573.541040897 1265991573.547173977
>> 0.000077009 0.000055075 0.006078005
>> 
>> 11 ReqStart     c ::1 51006 1691945309
>> 11 RxRequest    c PURGE
>> 11 RxURL        c /products/sillyputty
>> 11 RxProtocol   c HTTP/1.1
>> 11 RxHeader     c Accept: */*
>> 11 RxHeader     c User-Agent: WWW-Mechanize/1.0.0
>> (http://rubyforge.org/projects/mechanize/)
>> 11 RxHeader     c Connection: keep-alive
>> 11 RxHeader     c Keep-Alive: 300
>> 11 RxHeader     c Accept-Encoding: gzip,identity
>> 11 RxHeader     c Accept-Language: en-us,en;q=0.5
>> 11 RxHeader     c Host: localhost:8000
>> 11 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 11 VCL_call     c recv
>> 11 VCL_return   c lookup
>> 11 VCL_call     c hash
>> 11 VCL_return   c hash
>> 11 Hit          c 1691945214
>> 11 VCL_call     c hit
>> 11 TTL          c 1691945214 VCL 0 1265991617
>>  0 Debug        - "VCL_error(200, Purged.)"
>> 11 VCL_return   c error
>> 11 VCL_call     c error
>> 11 VCL_return   c deliver
>> 11 Length       c 322
>> 11 VCL_call     c deliver
>> 11 VCL_return   c deliver
>> 11 TxProtocol   c HTTP/1.1
>> 11 TxStatus     c 200
>> 11 TxResponse   c Purged.
>> 11 TxHeader     c Server: Varnish
>> 11 TxHeader     c Retry-After: 0
>> 11 TxHeader     c Content-Type: text/html; charset=utf-8
>> 11 TxHeader     c Content-Length: 322
>> 11 TxHeader     c Date: Fri, 12 Feb 2010 16:20:16 GMT
>> 11 TxHeader     c X-Varnish: 1691945309
>> 11 TxHeader     c Age: 0
>> 11 TxHeader     c Via: 1.1 varnish
>> 11 TxHeader     c Connection: close
>> 11 ReqEnd       c 1691945309 1265991616.884471893 1265991616.884622097
>> 0.000173807 0.000099182 0.000051022
>> 
>> ---------------------------------------
>> 
>> Now my problematic STAGING system -- first the GET with the hit, then
>> the purge that fails to hit.
>> 
>> 4 ReqStart     c 10.253.191.95 45944 904319331
>> 4 RxRequest    c GET
>> 4 RxURL        c /products/sillyputty
>> 4 RxProtocol   c HTTP/1.1
>> 4 RxHeader     c Host: staging1.example.com
>> 4 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
>> 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
>> 4 RxHeader     c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> 4 RxHeader     c Accept-Language: en-us,en;q=0.5
>> 4 RxHeader     c Accept-Encoding: gzip,deflate
>> 4 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 4 RxHeader     c Keep-Alive: 300
>> 4 RxHeader     c Connection: keep-alive
>> 4 RxHeader     c Referer: http://staging1.example.com/
>> 4 RxHeader     c Cookie: cehq-id=10.252.66.194.1263417178788050;
>> __utma=240927894.185175319.1263417179.1265907679.1265923273.61;
>> __utmz=240927894.1263591912.11.2.utmcsr=localhost:3000|utmccn=(referral)|utmcmd=referral|utmcct=/;
>> __utma=229000926.194920698.1263480064.126592
>> 4 RxHeader     c X-Forwarded-For: 75.150.106.113
>> 4 VCL_call     c recv
>> 4 VCL_return   c lookup
>> 4 VCL_call     c hash
>> 4 VCL_return   c hash
>> 4 Hit          c 904319258
>> 4 VCL_call     c hit
>> 4 VCL_return   c deliver
>> 4 Length       c 8471
>> 4 VCL_call     c deliver
>> 4 VCL_return   c deliver
>> 4 TxProtocol   c HTTP/1.1
>> 4 TxStatus     c 200
>> 4 TxResponse   c OK
>> 4 TxHeader     c Server: Apache/2.2.12 (Ubuntu)
>> 4 TxHeader     c X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.9
>> 4 TxHeader     c Cache-Control: max-age=8520, public
>> 4 TxHeader     c X-Runtime: 6052
>> 4 TxHeader     c ETag: "94c1d0e1f26f0117dfc9bf3573a39f5a"
>> 4 TxHeader     c Status: 200
>> 4 TxHeader     c Vary: Accept-Encoding,User-Agent
>> 4 TxHeader     c Content-Encoding: gzip
>> 4 TxHeader     c Content-Type: text/html; charset=utf-8
>> 4 TxHeader     c Content-Length: 8471
>> 4 TxHeader     c Date: Fri, 12 Feb 2010 16:07:58 GMT
>> 4 TxHeader     c X-Varnish: 904319331 904319258
>> 4 TxHeader     c Age: 180
>> 4 TxHeader     c Via: 1.1 varnish
>> 4 TxHeader     c Connection: keep-alive
>> 4 ReqEnd       c 904319331 1265990878.630007267 1265990878.630154371
>> 0.000055075 0.000094652 0.000052452
>> 
>> 
>> 4 ReqStart     c 10.253.191.95 38696 904319371
>> 4 RxRequest    c PURGE
>> 4 RxURL        c /products/sillyputty
>> 4 RxProtocol   c HTTP/1.1
>> 4 RxHeader     c Accept: */*
>> 4 RxHeader     c User-Agent: WWW-Mechanize/1.0.0
>> (http://rubyforge.org/projects/mechanize/)
>> 4 RxHeader     c Connection: keep-alive
>> 4 RxHeader     c Keep-Alive: 300
>> 4 RxHeader     c Accept-Encoding: gzip,identity
>> 4 RxHeader     c Accept-Language: en-us,en;q=0.5
>> 4 RxHeader     c Host: staging1.example.com:8000
>> 4 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 4 VCL_call     c recv
>> 4 VCL_return   c lookup
>> 4 VCL_call     c hash
>> 4 VCL_return   c hash
>> 4 VCL_call     c miss
>> 0 Debug        - "VCL_error(404, Not in cache.)"
>> 4 VCL_return   c error
>> 4 VCL_call     c error
>> 4 VCL_return   c deliver
>> 4 Length       c 340
>> 4 VCL_call     c deliver
>> 4 VCL_return   c deliver
>> 4 TxProtocol   c HTTP/1.1
>> 4 TxStatus     c 404
>> 4 TxResponse   c Not in cache.
>> 4 TxHeader     c Server: Varnish
>> 4 TxHeader     c Retry-After: 0
>> 4 TxHeader     c Content-Type: text/html; charset=utf-8
>> 4 TxHeader     c Content-Length: 340
>> 4 TxHeader     c Date: Fri, 12 Feb 2010 16:09:58 GMT
>> 4 TxHeader     c X-Varnish: 904319371
>> 4 TxHeader     c Age: 0
>> 4 TxHeader     c Via: 1.1 varnish
>> 4 TxHeader     c Connection: close
>> 4 ReqEnd       c 904319371 1265990998.368539810 1265990998.368721724
>> 0.000052691 0.000142813 0.000039101
>> 
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc



From phk at phk.freebsd.dk  Sat Feb 13 20:26:24 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 13 Feb 2010 20:26:24 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Fri, 12 Feb 2010 18:26:18 GMT."
	<89581.1265999178@critter.freebsd.dk> 
Message-ID: <30639.1266092784@critter.freebsd.dk>

In message <89581.1265999178 at critter.freebsd.dk>, "Poul-Henning Kamp" writes:
>In message <282e72051002120949u56eb6914mbd55e5a355931a38 at mail.gmail.com>, Paul 

>>Here's a snippet from varnishlog for one of these panics (also
>>attached to this email in case line wraps wreck formatting):
>
>Interesting!
>
>This time the EBADF comes in the original worker thread, before we
>hand the file descriptor over to the waiter, eliminating that entire
>ball of wax from the picture.

I'm still not 100% convinced that EBADF is not me screwing something
up, so I have gone over the poll-waiter and made it even more
paranoid and conservative than before.

Can I get you to give -trunk r4561 a swing, and see if that changes
anything ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From l at lrowe.co.uk  Sat Feb 13 22:43:55 2010
From: l at lrowe.co.uk (Laurence Rowe)
Date: Sat, 13 Feb 2010 23:43:55 +0100
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
	<b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
	<b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
Message-ID: <e95443d91002131443x68b8fe04q5c74f67b46c578ea@mail.gmail.com>

Given your backend is issuing a Vary header, I would just remove your
vcl_hash customisation and instead add a little header normalisation
to vcl_recv. We use the snippet from
http://varnish-cache.org/wiki/FAQ/Compression with success. You'll
still have to issue two PURGE requests, one with the gzip in the
Accept Encoding and one without.

Laurence


2010/2/12 John Norman <john at 7fff.com>:
> I think it's the backend's (Apache/Passenger) header:
>
> ? ?Vary: Accept-Encoding,User-Agent
>
> Which seems to prevent (???) this from working in my vcl_hash:
>
> ?if (req.http.Accept-Encoding ~ "gzip") {
> ? ?set req.hash += "gzip";
> ?} // etc
>
> The Varnish doc says: "But by default, Varnish will perform no
> transforms on the headers singled out by Vary: for comparison"
> (http://varnish-cache.org/wiki/ArchitectureVary).
>
> So . . . I'm not sure what I should do. If the backend says "Vary" for
> Accept-Encoding, does that mean that I should or should not be able to
> access that header for the purposes of setting the hash?
>
> What I am observing is:
>
> browser makes request with Accept-Encoding: gzip,deflate
>
> When I try to purge, the request with the purge says: Accept-Encoding:
> gzip,identity
>
> Even though "gzip" is in the request for both the browser
> Accept-Encoding, and for the purge, they seem to be getting hashed
> differently.
>
> If when I do a purge, I force Accept-Encoding: gzip,deflate, then it
> matches what the browser did exactly, and I am able to purge
> successfully.
>
> On Fri, Feb 12, 2010 at 11:54 AM, John Norman <john at 7fff.com> wrote:
>> Here's a bit more on my "purge" problem -- a comparison of a purge
>> that works on my development machine, vs. one that doesn't work on my
>> staging system.
>>
>> On both, the browser request goes to haproxy, then to varnish. The VCL
>> is identical, as quoted in a prior e-mail. The backends are different:
>> on my local, it's the Ruby webrick server; on staging, it's
>> Apache+Passenger.
>>
>> Again, I'm not purging through varnishadm: This is using the
>> pseudo-http-method PURGE.
>>
>> One thing I can say about the staging environment if that if I do a
>> non-browser request using mechanize from the staging system itself,
>> then the later purge DOES work. In that case, the two differences are:
>> The user-agent is the same for both the get and the purge; and
>> requesting IP would be the same for both the get and the purge.
>>
>> Here are the log details.
>>
>> DEVELOPMENT -- first the browser request, showing the hit; then the
>> purge, showing the hit. Awesome!
>>
>> 11 ReqStart ? ? c 127.0.0.1 50808 1691945259
>> 11 RxRequest ? ?c GET
>> 11 RxURL ? ? ? ?c /products/sillyputty
>> 11 RxProtocol ? c HTTP/1.1
>> 11 RxHeader ? ? c Host: localhost
>> 11 RxHeader ? ? c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS
>> X 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
>> 11 RxHeader ? ? c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> 11 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
>> 11 RxHeader ? ? c Accept-Encoding: gzip,deflate
>> 11 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 11 RxHeader ? ? c Keep-Alive: 300
>> 11 RxHeader ? ? c Connection: close
>> 11 RxHeader ? ? c Referer: http://localhost/
>> 11 RxHeader ? ? c Cookie:
>> remember_token=f27172bfab54dc47d20b6d8c853afb8677fa2d11
>> 11 RxHeader ? ? c X-Forwarded-For: 127.0.0.1
>> 11 VCL_call ? ? c recv
>> 11 VCL_return ? c lookup
>> 11 VCL_call ? ? c hash
>> 11 VCL_return ? c hash
>> 11 Hit ? ? ? ? ?c 1691945214
>> 11 VCL_call ? ? c hit
>> 11 VCL_return ? c deliver
>> 11 Length ? ? ? c 201518
>> 11 VCL_call ? ? c deliver
>> 11 VCL_return ? c deliver
>> 11 TxProtocol ? c HTTP/1.1
>> 11 TxStatus ? ? c 200
>> 11 TxResponse ? c OK
>> 11 TxHeader ? ? c Cache-Control: max-age=8280, public
>> 11 TxHeader ? ? c X-Runtime: 818
>> 11 TxHeader ? ? c Content-Type: text/html; charset=utf-8
>> 11 TxHeader ? ? c Etag: "f29fbc0160d276fb97a298bf5bce8ff3"
>> 11 TxHeader ? ? c Server: WEBrick/1.3.1 (Ruby/1.9.1/2009-07-16)
>> 11 TxHeader ? ? c Content-Length: 201518
>> 11 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:19:33 GMT
>> 11 TxHeader ? ? c X-Varnish: 1691945259 1691945214
>> 11 TxHeader ? ? c Age: 14
>> 11 TxHeader ? ? c Via: 1.1 varnish
>> 11 TxHeader ? ? c Connection: close
>> 11 ReqEnd ? ? ? c 1691945259 1265991573.541040897 1265991573.547173977
>> 0.000077009 0.000055075 0.006078005
>>
>> 11 ReqStart ? ? c ::1 51006 1691945309
>> 11 RxRequest ? ?c PURGE
>> 11 RxURL ? ? ? ?c /products/sillyputty
>> 11 RxProtocol ? c HTTP/1.1
>> 11 RxHeader ? ? c Accept: */*
>> 11 RxHeader ? ? c User-Agent: WWW-Mechanize/1.0.0
>> (http://rubyforge.org/projects/mechanize/)
>> 11 RxHeader ? ? c Connection: keep-alive
>> 11 RxHeader ? ? c Keep-Alive: 300
>> 11 RxHeader ? ? c Accept-Encoding: gzip,identity
>> 11 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
>> 11 RxHeader ? ? c Host: localhost:8000
>> 11 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 11 VCL_call ? ? c recv
>> 11 VCL_return ? c lookup
>> 11 VCL_call ? ? c hash
>> 11 VCL_return ? c hash
>> 11 Hit ? ? ? ? ?c 1691945214
>> 11 VCL_call ? ? c hit
>> 11 TTL ? ? ? ? ?c 1691945214 VCL 0 1265991617
>> ?0 Debug ? ? ? ?- "VCL_error(200, Purged.)"
>> 11 VCL_return ? c error
>> 11 VCL_call ? ? c error
>> 11 VCL_return ? c deliver
>> 11 Length ? ? ? c 322
>> 11 VCL_call ? ? c deliver
>> 11 VCL_return ? c deliver
>> 11 TxProtocol ? c HTTP/1.1
>> 11 TxStatus ? ? c 200
>> 11 TxResponse ? c Purged.
>> 11 TxHeader ? ? c Server: Varnish
>> 11 TxHeader ? ? c Retry-After: 0
>> 11 TxHeader ? ? c Content-Type: text/html; charset=utf-8
>> 11 TxHeader ? ? c Content-Length: 322
>> 11 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:20:16 GMT
>> 11 TxHeader ? ? c X-Varnish: 1691945309
>> 11 TxHeader ? ? c Age: 0
>> 11 TxHeader ? ? c Via: 1.1 varnish
>> 11 TxHeader ? ? c Connection: close
>> 11 ReqEnd ? ? ? c 1691945309 1265991616.884471893 1265991616.884622097
>> 0.000173807 0.000099182 0.000051022
>>
>> ---------------------------------------
>>
>> Now my problematic STAGING system -- first the GET with the hit, then
>> the purge that fails to hit.
>>
>> 4 ReqStart ? ? c 10.253.191.95 45944 904319331
>> 4 RxRequest ? ?c GET
>> 4 RxURL ? ? ? ?c /products/sillyputty
>> 4 RxProtocol ? c HTTP/1.1
>> 4 RxHeader ? ? c Host: staging1.example.com
>> 4 RxHeader ? ? c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
>> 10.5; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB7.0
>> 4 RxHeader ? ? c Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> 4 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
>> 4 RxHeader ? ? c Accept-Encoding: gzip,deflate
>> 4 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 4 RxHeader ? ? c Keep-Alive: 300
>> 4 RxHeader ? ? c Connection: keep-alive
>> 4 RxHeader ? ? c Referer: http://staging1.example.com/
>> 4 RxHeader ? ? c Cookie: cehq-id=10.252.66.194.1263417178788050;
>> __utma=240927894.185175319.1263417179.1265907679.1265923273.61;
>> __utmz=240927894.1263591912.11.2.utmcsr=localhost:3000|utmccn=(referral)|utmcmd=referral|utmcct=/;
>> __utma=229000926.194920698.1263480064.126592
>> 4 RxHeader ? ? c X-Forwarded-For: 75.150.106.113
>> 4 VCL_call ? ? c recv
>> 4 VCL_return ? c lookup
>> 4 VCL_call ? ? c hash
>> 4 VCL_return ? c hash
>> 4 Hit ? ? ? ? ?c 904319258
>> 4 VCL_call ? ? c hit
>> 4 VCL_return ? c deliver
>> 4 Length ? ? ? c 8471
>> 4 VCL_call ? ? c deliver
>> 4 VCL_return ? c deliver
>> 4 TxProtocol ? c HTTP/1.1
>> 4 TxStatus ? ? c 200
>> 4 TxResponse ? c OK
>> 4 TxHeader ? ? c Server: Apache/2.2.12 (Ubuntu)
>> 4 TxHeader ? ? c X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.9
>> 4 TxHeader ? ? c Cache-Control: max-age=8520, public
>> 4 TxHeader ? ? c X-Runtime: 6052
>> 4 TxHeader ? ? c ETag: "94c1d0e1f26f0117dfc9bf3573a39f5a"
>> 4 TxHeader ? ? c Status: 200
>> 4 TxHeader ? ? c Vary: Accept-Encoding,User-Agent
>> 4 TxHeader ? ? c Content-Encoding: gzip
>> 4 TxHeader ? ? c Content-Type: text/html; charset=utf-8
>> 4 TxHeader ? ? c Content-Length: 8471
>> 4 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:07:58 GMT
>> 4 TxHeader ? ? c X-Varnish: 904319331 904319258
>> 4 TxHeader ? ? c Age: 180
>> 4 TxHeader ? ? c Via: 1.1 varnish
>> 4 TxHeader ? ? c Connection: keep-alive
>> 4 ReqEnd ? ? ? c 904319331 1265990878.630007267 1265990878.630154371
>> 0.000055075 0.000094652 0.000052452
>>
>>
>> 4 ReqStart ? ? c 10.253.191.95 38696 904319371
>> 4 RxRequest ? ?c PURGE
>> 4 RxURL ? ? ? ?c /products/sillyputty
>> 4 RxProtocol ? c HTTP/1.1
>> 4 RxHeader ? ? c Accept: */*
>> 4 RxHeader ? ? c User-Agent: WWW-Mechanize/1.0.0
>> (http://rubyforge.org/projects/mechanize/)
>> 4 RxHeader ? ? c Connection: keep-alive
>> 4 RxHeader ? ? c Keep-Alive: 300
>> 4 RxHeader ? ? c Accept-Encoding: gzip,identity
>> 4 RxHeader ? ? c Accept-Language: en-us,en;q=0.5
>> 4 RxHeader ? ? c Host: staging1.example.com:8000
>> 4 RxHeader ? ? c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> 4 VCL_call ? ? c recv
>> 4 VCL_return ? c lookup
>> 4 VCL_call ? ? c hash
>> 4 VCL_return ? c hash
>> 4 VCL_call ? ? c miss
>> 0 Debug ? ? ? ?- "VCL_error(404, Not in cache.)"
>> 4 VCL_return ? c error
>> 4 VCL_call ? ? c error
>> 4 VCL_return ? c deliver
>> 4 Length ? ? ? c 340
>> 4 VCL_call ? ? c deliver
>> 4 VCL_return ? c deliver
>> 4 TxProtocol ? c HTTP/1.1
>> 4 TxStatus ? ? c 404
>> 4 TxResponse ? c Not in cache.
>> 4 TxHeader ? ? c Server: Varnish
>> 4 TxHeader ? ? c Retry-After: 0
>> 4 TxHeader ? ? c Content-Type: text/html; charset=utf-8
>> 4 TxHeader ? ? c Content-Length: 340
>> 4 TxHeader ? ? c Date: Fri, 12 Feb 2010 16:09:58 GMT
>> 4 TxHeader ? ? c X-Varnish: 904319371
>> 4 TxHeader ? ? c Age: 0
>> 4 TxHeader ? ? c Via: 1.1 varnish
>> 4 TxHeader ? ? c Connection: close
>> 4 ReqEnd ? ? ? c 904319371 1265990998.368539810 1265990998.368721724
>> 0.000052691 0.000142813 0.000039101
>>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From slink at schokola.de  Sun Feb 14 17:53:36 2010
From: slink at schokola.de (Nils Goroll)
Date: Sun, 14 Feb 2010 18:53:36 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com>
References: <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com>
Message-ID: <4B7838A0.1030707@schokola.de>

Paul,

have I missed anything or have you not yet stated which version of OpenSolaris 
(uname -v) you're using? If you don't use a standard build, could you please 
give the hg changeset you're on?

Nils


From slink at schokola.de  Sun Feb 14 18:11:30 2010
From: slink at schokola.de (Nils Goroll)
Date: Sun, 14 Feb 2010 19:11:30 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <89581.1265999178@critter.freebsd.dk>
References: <89581.1265999178@critter.freebsd.dk>
Message-ID: <4B783CD2.3030503@schokola.de>

Hi Poul-Henning and all,

> If I had implemented the hack I suspect Solaris contains, I would
> have found some bit somewhere, to make sure the errno would be the
> correct, documented and expected:
> 
> 	#define ECONNRESET      54     /* Connection reset by peer */
> 
> Somebody with a Solaris service contract, if such things still
> exist, should report this as a bug to them...
> 
> I will add a workaround to Varnish, with a suitable sarcastic
> commentary...

I can't tell at this point if this is a Solaris or a Varnish issue, but I can 
tell for sure that I have never seen it on 2.0.3 with a couple of additional 
fixes running a *high* traffic site. The main difference between this version 
and trunk with respect to TCP is, IIUC, the lack of tcp_linger. Maybe that gives 
a clue on where to look, but on the other hand this might be absolutely the 
wrong war to go.

Regarding Solaris, this piece of code here

http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/tcp/tcp.c#11049

documents the errnos that SHOULD be set upon reception of an RST depending on 
various conditions.

Regarding sarcasm: Please add the comment when the current hypothesis proves 
true, but my experience is that in many cases the Solaris guys are quite fuzzy 
about documentation.

I volunteer to get this fixed in OpenSolaris should it turn out that the issue 
is root caused there.

Nils


From tfheen at varnish-software.com  Mon Feb 15 08:29:58 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Mon, 15 Feb 2010 09:29:58 +0100
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
	(John Norman's message of "Fri, 12 Feb 2010 13:44:19 -0500")
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
	<b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
	<b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
Message-ID: <87sk92nbp5.fsf@qurzaw.linpro.no>

]] John Norman 

| I think it's the backend's (Apache/Passenger) header:
| 
|     Vary: Accept-Encoding,User-Agent
| 
| Which seems to prevent (???) this from working in my vcl_hash:
| 
|   if (req.http.Accept-Encoding ~ "gzip") {
|     set req.hash += "gzip";
|   } // etc

No, that works fine, but is useless.  Varnish does Vary handling
automatically.

| The Varnish doc says: "But by default, Varnish will perform no
| transforms on the headers singled out by Vary: for comparison"
| (http://varnish-cache.org/wiki/ArchitectureVary).

Yes, this means that if you know your backend only cares about
gzip/non-gzip, you should normalise the header in vcl_recv.  Varnish
can't know this, as it requires knowledge of your backend and
application.

However, even if you changed that, you still have a Vary on
user-agent. This is generally a really bad idea, and you should try to
see if you can vary on something else.  If you don't, you are going to
see poor hit rates. (Assuming that you're not just caching for a
corporate intranet where everybody has _exactly_ the same versions of
browser, etc.)

| So . . . I'm not sure what I should do. If the backend says "Vary" for
| Accept-Encoding, does that mean that I should or should not be able to
| access that header for the purposes of setting the hash?

Normalise Accept-Encoding, stop adding it to the hash.

| What I am observing is:
| 
| browser makes request with Accept-Encoding: gzip,deflate
| 
| When I try to purge, the request with the purge says: Accept-Encoding:
| gzip,identity
| 
| Even though "gzip" is in the request for both the browser
| Accept-Encoding, and for the purge, they seem to be getting hashed
| differently.

No, they hash to the same object but as the Vary-ed string differs the
Vary handling makes it out to be different objects.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From wrighty+varnishmisc at gmail.com  Mon Feb 15 09:30:53 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Mon, 15 Feb 2010 09:30:53 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <4B7838A0.1030707@schokola.de>
References: <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com>
	<4B7838A0.1030707@schokola.de>
Message-ID: <282e72051002150130i22cb10a4u7528b078e4e405bb@mail.gmail.com>

On 14 February 2010 17:53, Nils Goroll <slink at schokola.de> wrote:
> Paul,
>
> have I missed anything or have you not yet stated which version of
> OpenSolaris (uname -v) you're using? If you don't use a standard build,
> could you please give the hg changeset you're on?
>

You're right, I'd forgotten to mention it before now.

[root at varnish bin]# uname -a
SunOS varnish 5.11 snv_111b i86pc i386 i86pc

Cheers,

Paul.


From wrighty+varnishmisc at gmail.com  Mon Feb 15 11:22:36 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Mon, 15 Feb 2010 11:22:36 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <30639.1266092784@critter.freebsd.dk>
References: <89581.1265999178@critter.freebsd.dk>
	<30639.1266092784@critter.freebsd.dk>
Message-ID: <282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com>

On 13 February 2010 20:26, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> I'm still not 100% convinced that EBADF is not me screwing something
> up, so I have gone over the poll-waiter and made it even more
> paranoid and conservative than before.
>
> Can I get you to give -trunk r4561 a swing, and see if that changes
> anything ?

I just ran r4561 for about 10 minutes and observed the same error with
a client halfway through a KeepAlive session:

Child (3504) died signal=6
Child (3504) Panic message: Assert error in TCP_nonblocking(), tcp.c line 172:
  Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
(int))&0xff)<<16)| ('f'<<8)|126))), &i)) == 0) not true.
errno = 9 (Bad file number)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  4457db: /opt/sbin/varnishd'pan_backtrace+0x1b [0x4457db]
  445ae5: /opt/sbin/varnishd'pan_ic+0x1c5 [0x445ae5]
  fffffd7ff2efdfec: /opt/lib/libvarnish.so.1.0.0'TCP_nonblocking+0x7c
[0xfffffd7ff2efdfec]
  419091: /opt/sbin/varnishd'vca_return_session+0x1b1 [0x419091]
  426aad: /opt/sbin/varnishd'cnt_wait+0x2bd [0x426aad]
  42bc3a: /opt/sbin/varnishd'CNT_Session+0x4ba [0x42bc3a]
  44835b: /opt/sbin/varnishd'wrk_do_cnt_sess+0x19b [0x44835b]
  447954: /opt/sbin/varnishd'wrk_thread_real+0x854 [0x447954]
  447eb3: /opt/sbin/varnishd'wrk_thread+0x123 [0x447eb3]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 2b37678 {
  fd = 61, id = 61, xid = 0,
  client = 85.189.148.82:15824,
  step = STP_WAIT,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 2b376e8 {
    id = "sess",
    {s,f,r,e} = {2b383f0,+20,+32788,+65536},
  },
  http[req] = {
    ws = 2b376e8[sess]
      "",
      "/i/video_graphics/starb_0.gif",
      "HTTP/1.1",
      "Accept: */*",
      "Referer:
http://www.firebox.com/product/993/Firebox-of-Retro-Sweets?aff=1108",
      "Accept-Language: en-gb",
      "UA-CPU: x86",
      "Accept-Encoding: gzip, deflate",
      "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
.NET CLR 1.0.3705)",
      "Connection: Keep-Alive",
      "host: media.firebox.com",
      "X-Forwarded-For: 85.189.148.82",
  },
},

   61 ReqEnd       c 958037480 1266232359.325721025
1266232359.325860262 0.306401968 0.000052452 0.000086784
   61 Debug        c "herding"
   61 Debug        c "Poll: 0 / 1"
   61 ReqStart     c 85.189.148.82 15824 958037491
   61 RxRequest    c GET
   61 RxURL        c /i/video_graphics/starb_0.gif
   61 RxProtocol   c HTTP/1.1
   61 RxHeader     c Accept: */*
   61 RxHeader     c Referer:
http://www.firebox.com/product/993/Firebox-of-Retro-Sweets?aff=1108
   61 RxHeader     c Accept-Language: en-gb
   61 RxHeader     c UA-CPU: x86
   61 RxHeader     c Accept-Encoding: gzip, deflate
   61 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 5.1; .NET CLR 1.0.3705)
   61 RxHeader     c Host: media4.firebox.com
   61 RxHeader     c Connection: Keep-Alive
   61 RxHeader     c Cookie: user_session=XXXX;
locale=company_id%3A0%2Ccurrency_id%3A0%2Clanguage_id%3A0%2Ccountry%3AUnited+Kingdom;
xp_list=52%3D2; aff=1108; intl_aff=000%3D1108%252C1268824352;
__utma=64137912.663836520.1266233079.1266233079.1266
   61 VCL_call     c recv
   61 VCL_return   c lookup
   61 VCL_call     c hash
   61 VCL_return   c hash
   61 Hit          c 958027384
   61 VCL_call     c hit
   61 VCL_return   c deliver
   61 Length       c 125
   61 VCL_call     c deliver
   61 VCL_return   c deliver
   61 TxProtocol   c HTTP/1.1
   61 TxStatus     c 200
   61 TxResponse   c OK
   61 TxHeader     c Server: Apache
   61 TxHeader     c Last-Modified: Mon, 26 Feb 2007 16:53:44 GMT
   61 TxHeader     c ETag: "1708031-7d-42a63fbf35600"
   61 TxHeader     c Cache-Control: max-age=2592000
   61 TxHeader     c Expires: Wed, 17 Mar 2010 11:09:26 GMT
   61 TxHeader     c Content-Type: image/gif
   61 TxHeader     c Content-Length: 125
   61 TxHeader     c Date: Mon, 15 Feb 2010 11:12:39 GMT
   61 TxHeader     c X-Varnish: 958037491 958027384
   61 TxHeader     c Age: 193
   61 TxHeader     c Via: 1.1 varnish
   61 TxHeader     c Connection: keep-alive
   61 ReqEnd       c 958037491 1266232359.455624580
1266232359.455763578 0.129764318 0.000072718 0.000066280

Cheers,

Paul.


From slink at schokola.de  Mon Feb 15 11:27:00 2010
From: slink at schokola.de (Nils Goroll)
Date: Mon, 15 Feb 2010 12:27:00 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <282e72051002150130i22cb10a4u7528b078e4e405bb@mail.gmail.com>
References: <282e72051002100305m5d7a0d1fj3a1afac6ea7dd633@mail.gmail.com>	
	<4B7838A0.1030707@schokola.de>
	<282e72051002150130i22cb10a4u7528b078e4e405bb@mail.gmail.com>
Message-ID: <4B792F84.3060809@schokola.de>

Hi Paul,

> You're right, I'd forgotten to mention it before now.
> 
> [root at varnish bin]# uname -a
> SunOS varnish 5.11 snv_111b i86pc i386 i86pc

Good, thank you. Then at least this shouldn't be a bug introduced with the major 
changes of the ip datapath refactoring project 
http://hub.opensolaris.org/bin/view/Project+ip-refactor/WebHome

Nils


From phk at phk.freebsd.dk  Mon Feb 15 11:42:59 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 15 Feb 2010 11:42:59 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Mon, 15 Feb 2010 11:22:36 GMT."
	<282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com> 
Message-ID: <41935.1266234179@critter.freebsd.dk>

In message <282e72051002150322l57063a9ds98143093910c2673 at mail.gmail.com>, Paul 
Wright writes:
>On 13 February 2010 20:26, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
>> I'm still not 100% convinced that EBADF is not me screwing something
>> up, so I have gone over the poll-waiter and made it even more
>> paranoid and conservative than before.
>>
>> Can I get you to give -trunk r4561 a swing, and see if that changes
>> anything ?
>
>I just ran r4561 for about 10 minutes and observed the same error with
>a client halfway through a KeepAlive session:

Is there any way (dtrace ?) you can log which systemcalls happen,
I would really like to be 100% sure that varnish does not close that
socket by mistake...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From slink at schokola.de  Mon Feb 15 11:54:30 2010
From: slink at schokola.de (Nils Goroll)
Date: Mon, 15 Feb 2010 12:54:30 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com>
References: <89581.1265999178@critter.freebsd.dk>	<30639.1266092784@critter.freebsd.dk>
	<282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com>
Message-ID: <4B7935F6.3090307@schokola.de>

Hi Poul-Henning,

Victor added a comment to http://varnish-cache.org/ticket/629:

http://pastie.org/791964

child (28980) Started
Child (28980) said Closed fds: 3 5 6 9 10 12 13
Child (28980) said Child starts
Child (28980) said managed to mmap 536870912 bytes of 536870912
Child (28980) died signal=6
Child (28980) Panic message: Assert error in vca_main(), cache_waiter_ports.c 
line 175:
   Condition((errno == EINTR) || (errno == ETIME)) not true.
errno = 9 (Bad file number)
Backtrace:
   42e405: /opt/extra/sbin/varnishd'pan_ic+0x95 [0x42e405]
   fffffd7ffefa4ee0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ffefa4ee0]

I definitely do not see this in my patched up 2.0.3 (varnish running for weeks 
on 7 servers now), so IMHO, this is another hint into the direction of some 
change in trunk.

Nils


From slink at schokola.de  Mon Feb 15 12:31:20 2010
From: slink at schokola.de (Nils Goroll)
Date: Mon, 15 Feb 2010 13:31:20 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com>
References: <89581.1265999178@critter.freebsd.dk>	<30639.1266092784@critter.freebsd.dk>
	<282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com>
Message-ID: <4B793E98.2020807@schokola.de>

Poul-Henning,

> Child (3504) died signal=6
> Child (3504) Panic message: Assert error in TCP_nonblocking(), tcp.c line 172:
>   Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
> (int))&0xff)<<16)| ('f'<<8)|126))), &i)) == 0) not true.
> errno = 9 (Bad file number)
> thread = (cache-worker)
> ident = -smalloc,-hcritbit,poll
> Backtrace:
>   4457db: /opt/sbin/varnishd'pan_backtrace+0x1b [0x4457db]
>   445ae5: /opt/sbin/varnishd'pan_ic+0x1c5 [0x445ae5]
>   fffffd7ff2efdfec: /opt/lib/libvarnish.so.1.0.0'TCP_nonblocking+0x7c
> [0xfffffd7ff2efdfec]
>   419091: /opt/sbin/varnishd'vca_return_session+0x1b1 [0x419091]
>   426aad: /opt/sbin/varnishd'cnt_wait+0x2bd [0x426aad]
>   42bc3a: /opt/sbin/varnishd'CNT_Session+0x4ba [0x42bc3a]
>   44835b: /opt/sbin/varnishd'wrk_do_cnt_sess+0x19b [0x44835b]
>   447954: /opt/sbin/varnishd'wrk_thread_real+0x854 [0x447954]
>   447eb3: /opt/sbin/varnishd'wrk_thread+0x123 [0x447eb3]

Just an idea from checking differences between the code I use and trunk: In 
cnt_wait, shouldn't we check pfd[0].revents for POLLERR and POLLHUP? Could it be 
that Solaris assumes that delivery an error once should suffice, so further use 
of the fd will return EBADF?

Again, I haven't investigated further, sorry for the noise if this turns out to 
be stupid.

Nils


From phk at phk.freebsd.dk  Mon Feb 15 12:40:50 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 15 Feb 2010 12:40:50 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Mon, 15 Feb 2010 13:31:20 +0100."
	<4B793E98.2020807@schokola.de> 
Message-ID: <42090.1266237650@critter.freebsd.dk>

In message <4B793E98.2020807 at schokola.de>, Nils Goroll writes:
>Poul-Henning,
>

>Just an idea from checking differences between the code I use and trunk: In 
>cnt_wait, shouldn't we check pfd[0].revents for POLLERR and POLLHUP? Could it be 
>that Solaris assumes that delivery an error once should suffice, so further use 
>of the fd will return EBADF?

That was one of my theories, but it does not fit the facs of the case,
and it would violate POSIX, which I doubt Solaris would do...

The best contender is still that varnish closes the fd by mistake,
but I'll be damned if I can find where...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From slink at schokola.de  Mon Feb 15 17:29:52 2010
From: slink at schokola.de (Nils Goroll)
Date: Mon, 15 Feb 2010 18:29:52 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <42090.1266237650@critter.freebsd.dk>
References: <42090.1266237650@critter.freebsd.dk>
Message-ID: <4B798490.3030903@schokola.de>

Hi Poul-Henning,

> That was one of my theories, but it does not fit the facs of the case,

I don't understand what contradicts this hypothesis?

> and it would violate POSIX, which I doubt Solaris would do...

Just out of interest: Do you have a reference why that would violate POSIX?

http://www.opengroup.org/onlinepubs/009695399/functions/poll.html doesn't tell.

> The best contender is still that varnish closes the fd by mistake,
> but I'll be damned if I can find where...

Please let's come back to the basics and your initial hypothesis one last time:
Suppose the RST gets received between the poll() and ioctl() in TCP_nonblocking.

Why should the ioctl not be allowed to return EBADF in that case? For instance,
this man page

Ioctl Requests                                       streamio(7I)



NAME
      streamio - STREAMS ioctl commands

SYNOPSIS
      #include <sys/types.h>
      #include <stropts.h>
      #include <sys/conf.h>

      int ioctl(int fildes, int command, ... /*arg*/);

only mentions a hand full of error codes and then there is this:

http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/proto_set.c#tli_errs

I'm not sure this is the exact mapping for this case, but it looks like it...

Nils



From justinp at newmediagateway.com  Mon Feb 15 21:56:01 2010
From: justinp at newmediagateway.com (Justin Pasher)
Date: Mon, 15 Feb 2010 15:56:01 -0600
Subject: Understand "hit for pass" cache objects
Message-ID: <4B79C2F1.9050901@newmediagateway.com>

Hello,

I have just started using Varnish 2.0.6 in the past week as a 
replacement for Squid. So far, I love the fine grained control you have 
over what goes into cache (as opposed to Squid's "I'll cache it when I 
feel it's supposed to be cached, but not tell you why" approach). That 
said, I'm trying to better understand the "hit for pass" cache objects 
that Varnish will sometimes create. Here is basic flow of my vcl (much 
of it is based on the concepts on the intro page: 
http://varnish-cache.org/wiki/Introduction)

vcl_recv:
Default action is "lookup". Action changes to "pass" if ...
* Cache-Control or Pragma headers has "no-cache"
* HTTP auth is in use (Authorization header)
* Request contains cookie "bypass_cache=true"
* Request type is not GET, HEAD, POST, PUT, TRACE, OPTIONS, DELETE

vcl_fetch:
Default action is "deliver". Action changes to "pass" if ...
* Response is deemed uncacheable (!obj.cacheable)
* Response contains Cache-Control headers that say "no-cache"
* HTTP auth is in use (Authorization header)
* Request contains cookie "bypass_cache=true"
* Response contains Set-Cookie header

Now on to the problem at hand. My understanding (please correct any 
errors) of the "hit for pass" object is that any time the action is 
"pass" within vcl_fetch, Varnish will create a "hit for pass" object to 
make future requests for the same URL hash go straight to the back end 
instead of lining them up serially and waiting for a response from the 
first request. Until that object's TTL expires, the "hit for pass" 
object will remain in cache and never be replaced with a fresh object 
from the backend.

Here is what is happening my my example.

Client A visits the URL http://www.example.com/. Since this is the first 
time they visit the site, the backend code tries to start a session (PHP 
code), which sends a Set-Cookie header in the response. In vcl_fetch, 
Varnish sees the Set-Cookie header and issues the "pass" action. Now 
there is a "hit for pass" cache object with a TTL based upon the 
Cache-Control/Expires headers or the default TTL (let's assume 120 seconds).

Client B visit the same URL http://www.example.com/. Varnish finds a 
"hit for pass" object in the cache, so it sends the request directly to 
the backend. This same thing will continue for any future clients until 
120 seconds have elapsed.

Herein lies my dilemma. A request for the same URL 
(http://www.example.com/) is sometimes cacheable and sometimes not 
cacheable (it usually depends on whether it's the first time a user 
visits the site and the Set-Cookie header has to be sent). What this 
means is if I have a very heavy hit URL as a landing page from Google, 
most of the time there will be a "hit for pass" cache object in Varnish, 
since most people going to that page will have a Set-Cookie header. The 
only time it will cache the page is if I'm lucky and someone visits the 
page while there is no "hit for pass" cache object and their request 
doesn't result in a "pass" action from vcl_fetch.

In my situation, I think I could avoid this problem altogether if I 
could make Varnish store a DIFFERENT set of headers in the cache object 
than the headers return to the client. For example, if I receive a 
response with a Set-Cookie header, I would remove the Set-Cookie header 
from the soon-to-be-cached object (so it wouldn't serve that header up 
for everyone), but LEAVE the Set-Cookie header for the individual that 
made the original request. This would allow the page to cache normally 
even if the only requests going to that page result in a Set-Cookie 
header. However, from what I've been able to see, there is no way to do 
this.

Does anyone have any recommendations to get around this? In a perfect 
world, my caching server would work this way:

* vcl_recv: If any criteria from A through D are met, don't pull this 
request from cache and go to the backend
* vcl_fetch: If any criteria from E through G are met, send the object 
straight to the client without touching the cache.

The "without touching the cache" portion seems to be where I am falling 
down.

-- 
Justin Pasher


From l at lrowe.co.uk  Mon Feb 15 22:20:24 2010
From: l at lrowe.co.uk (Laurence Rowe)
Date: Mon, 15 Feb 2010 22:20:24 +0000
Subject: Understand "hit for pass" cache objects
In-Reply-To: <4B79C2F1.9050901@newmediagateway.com>
References: <4B79C2F1.9050901@newmediagateway.com>
Message-ID: <e95443d91002151420na11a09dp756e82a0e610742f@mail.gmail.com>

On 15 February 2010 21:56, Justin Pasher <justinp at newmediagateway.com> wrote:
> Hello,
>
> I have just started using Varnish 2.0.6 in the past week as a
> replacement for Squid. So far, I love the fine grained control you have
> over what goes into cache (as opposed to Squid's "I'll cache it when I
> feel it's supposed to be cached, but not tell you why" approach). That
> said, I'm trying to better understand the "hit for pass" cache objects
> that Varnish will sometimes create. Here is basic flow of my vcl (much
> of it is based on the concepts on the intro page:
> http://varnish-cache.org/wiki/Introduction)
>
> vcl_recv:
> Default action is "lookup". Action changes to "pass" if ...
> * Cache-Control or Pragma headers has "no-cache"
> * HTTP auth is in use (Authorization header)
> * Request contains cookie "bypass_cache=true"
> * Request type is not GET, HEAD, POST, PUT, TRACE, OPTIONS, DELETE
>
> vcl_fetch:
> Default action is "deliver". Action changes to "pass" if ...
> * Response is deemed uncacheable (!obj.cacheable)
> * Response contains Cache-Control headers that say "no-cache"
> * HTTP auth is in use (Authorization header)
> * Request contains cookie "bypass_cache=true"
> * Response contains Set-Cookie header
>
> Now on to the problem at hand. My understanding (please correct any
> errors) of the "hit for pass" object is that any time the action is
> "pass" within vcl_fetch, Varnish will create a "hit for pass" object to
> make future requests for the same URL hash go straight to the back end
> instead of lining them up serially and waiting for a response from the
> first request. Until that object's TTL expires, the "hit for pass"
> object will remain in cache and never be replaced with a fresh object
> from the backend.
>
> Here is what is happening my my example.
>
> Client A visits the URL http://www.example.com/. Since this is the first
> time they visit the site, the backend code tries to start a session (PHP
> code), which sends a Set-Cookie header in the response. In vcl_fetch,
> Varnish sees the Set-Cookie header and issues the "pass" action. Now
> there is a "hit for pass" cache object with a TTL based upon the
> Cache-Control/Expires headers or the default TTL (let's assume 120 seconds).
>
> Client B visit the same URL http://www.example.com/. Varnish finds a
> "hit for pass" object in the cache, so it sends the request directly to
> the backend. This same thing will continue for any future clients until
> 120 seconds have elapsed.
>
> Herein lies my dilemma. A request for the same URL
> (http://www.example.com/) is sometimes cacheable and sometimes not
> cacheable (it usually depends on whether it's the first time a user
> visits the site and the Set-Cookie header has to be sent). What this
> means is if I have a very heavy hit URL as a landing page from Google,
> most of the time there will be a "hit for pass" cache object in Varnish,
> since most people going to that page will have a Set-Cookie header. The
> only time it will cache the page is if I'm lucky and someone visits the
> page while there is no "hit for pass" cache object and their request
> doesn't result in a "pass" action from vcl_fetch.
>
> In my situation, I think I could avoid this problem altogether if I
> could make Varnish store a DIFFERENT set of headers in the cache object
> than the headers return to the client. For example, if I receive a
> response with a Set-Cookie header, I would remove the Set-Cookie header
> from the soon-to-be-cached object (so it wouldn't serve that header up
> for everyone), but LEAVE the Set-Cookie header for the individual that
> made the original request. This would allow the page to cache normally
> even if the only requests going to that page result in a Set-Cookie
> header. However, from what I've been able to see, there is no way to do
> this.

Why not cache the object with the Set-Cookie header in vcl_fetch, then
in vcl_deliver remove the header for users without your cookie,
something like:


    if (req.http.cookie ~ "(^|; )my_cookie=") {
        remove obj.http.Set-Cookie;
    }

Of course, this means that if a user with your cookie is the first to
see the object, a new user may never get sent to the backend and have
the cookie set, but then you can't have that and  also send them
cached responses without re-engineering the way your backend sets
cookies. You may be able to work around that with restarts though.

> Does anyone have any recommendations to get around this? In a perfect
> world, my caching server would work this way:
>
> * vcl_recv: If any criteria from A through D are met, don't pull this
> request from cache and go to the backend
> * vcl_fetch: If any criteria from E through G are met, send the object
> straight to the client without touching the cache.
>
> The "without touching the cache" portion seems to be where I am falling
> down.

You can achieve this using a Vary, I use something similar for serving
cached pages to anonymous users but personalised dynamic pages to
logged in users):

In vcl_recv:

    if (req.http.cookie ~ "(^|; )mycookie=") {
        set req.http.X-My-Cookie = "true";
    }

in vcl_fetch:

    set obj.http.Vary = "X-My-Cookie";
    if (req.http.X-My-Cookie) {
        pass;
    }

Laurence


From phk at phk.freebsd.dk  Mon Feb 15 22:33:25 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 15 Feb 2010 22:33:25 +0000
Subject: Understand "hit for pass" cache objects 
In-Reply-To: Your message of "Mon, 15 Feb 2010 15:56:01 CST."
	<4B79C2F1.9050901@newmediagateway.com> 
Message-ID: <64024.1266273205@critter.freebsd.dk>

In message <4B79C2F1.9050901 at newmediagateway.com>, Justin Pasher writes:

>Now on to the problem at hand. My understanding (please correct any 
>errors) of the "hit for pass" object is that any time the action is 
>"pass" within vcl_fetch, Varnish will create a "hit for pass" object to 
>make future requests for the same URL hash go straight to the back end 
>instead of lining them up serially and waiting for a response from the 
>first request. Until that object's TTL expires, the "hit for pass" 
>object will remain in cache and never be replaced with a fresh object 
>from the backend.

Correct.

>In my situation, I think I could avoid this problem altogether if I 
>could make Varnish store a DIFFERENT set of headers in the cache object 
>than the headers return to the client. For example, if I receive a 
>response with a Set-Cookie header, I would remove the Set-Cookie header 
>from the soon-to-be-cached object (so it wouldn't serve that header up 
>for everyone), but LEAVE the Set-Cookie header for the individual that 
>made the original request.

I guess you could do that, something like:

	sub vcl_fetch {
		set req.http.myfoo = beresp.http.set-cookie;
		unset beresp.http.set-cookie;
	}

	sub vcl_deliver {
		if (req.http.myfoo) {
			set resp.http.set-cookie = req.http.myfoo;
		}
	}

But doing this means that the next user that comes without the
cookie, will get the cached copy, and no set-cookie header ?

	
-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From justinp at newmediagateway.com  Mon Feb 15 22:42:51 2010
From: justinp at newmediagateway.com (Justin Pasher)
Date: Mon, 15 Feb 2010 16:42:51 -0600
Subject: Understand "hit for pass" cache objects
In-Reply-To: <e95443d91002151420na11a09dp756e82a0e610742f@mail.gmail.com>
References: <4B79C2F1.9050901@newmediagateway.com>
	<e95443d91002151420na11a09dp756e82a0e610742f@mail.gmail.com>
Message-ID: <4B79CDEB.1030406@newmediagateway.com>

Laurence Rowe wrote:
>> In my situation, I think I could avoid this problem altogether if I
>> could make Varnish store a DIFFERENT set of headers in the cache object
>> than the headers return to the client. For example, if I receive a
>> response with a Set-Cookie header, I would remove the Set-Cookie header
>> from the soon-to-be-cached object (so it wouldn't serve that header up
>> for everyone), but LEAVE the Set-Cookie header for the individual that
>> made the original request. This would allow the page to cache normally
>> even if the only requests going to that page result in a Set-Cookie
>> header. However, from what I've been able to see, there is no way to do
>> this.
>>     
>
> Why not cache the object with the Set-Cookie header in vcl_fetch, then
> in vcl_deliver remove the header for users without your cookie,
> something like:
>
>
>     if (req.http.cookie ~ "(^|; )my_cookie=") {
>         remove obj.http.Set-Cookie;
>     }
>   

Hmm.. That's an interesting idea, but I see two potential problems. The 
main one is that "req" is not available in vcl_deliver() (neither is 
"obj", but "resp" would be what I want to change anyway). The other 
problem I see is that if an object is cached with the Set-Cookie header, 
then someone who has NOT been to the site before hits that same URL, it 
will pull from the cache, notice that they don't have the "my_cookie" 
set yet, and ignore the remove line, thus passing the original 
Set-Cookie header, which would actually be someone else's cookie (the 
value of the cookie identifies their session ID). If I really could get 
the desired behavior, then I do understand that subsequent visits to the 
same page by other people would be served from cache and thus not 
receive a Set-Cookie header in their response (which is fine). That's 
the trade-off for allowing a page to be cached.

> You can achieve this using a Vary, I use something similar for serving
> cached pages to anonymous users but personalised dynamic pages to
> logged in users):
>
> In vcl_recv:
>
>     if (req.http.cookie ~ "(^|; )mycookie=") {
>         set req.http.X-My-Cookie = "true";
>     }
>
> in vcl_fetch:
>
>     set obj.http.Vary = "X-My-Cookie";
>     if (req.http.X-My-Cookie) {
>         pass;
>     }
>   

If I understand correctly, this would still cause a "hit for pass" cache 
object to be created, since the final action is "pass". I've figured out 
the way to avoid the "hit for pass" cache object is to "set obj.ttl = 
0s", but that only half solves my problem. If 1000 people visiting a 
particular page are doing so for the first time (thus they do not have a 
session cookie), it will never end of storing a cached version of the 
page because it will hit a "pass" action, then not store an object in cache.


-- 
Justin Pasher


From justinp at newmediagateway.com  Mon Feb 15 22:46:17 2010
From: justinp at newmediagateway.com (Justin Pasher)
Date: Mon, 15 Feb 2010 16:46:17 -0600
Subject: Understand "hit for pass" cache objects
In-Reply-To: <64024.1266273205@critter.freebsd.dk>
References: <64024.1266273205@critter.freebsd.dk>
Message-ID: <4B79CEB9.90607@newmediagateway.com>

Poul-Henning Kamp wrote:
> I guess you could do that, something like:
>
> 	sub vcl_fetch {
> 		set req.http.myfoo = beresp.http.set-cookie;
> 		unset beresp.http.set-cookie;
> 	}
>
> 	sub vcl_deliver {
> 		if (req.http.myfoo) {
> 			set resp.http.set-cookie = req.http.myfoo;
> 		}
> 	}
>
> But doing this means that the next user that comes without the
> cookie, will get the cached copy, and no set-cookie header ?
>   

That's actually fine (and expected). That seems to be the way Squid 
works. I actually had a similar idea myself. However, like my reply to 
Laurence, the "req" object isn't available in vcl_deliver()... or maybe 
trunk allows that? I'm currently running 2.0.6.


-- 
Justin Pasher


From rtshilston at gmail.com  Mon Feb 15 22:50:16 2010
From: rtshilston at gmail.com (Rob S)
Date: Mon, 15 Feb 2010 22:50:16 +0000
Subject: Understand "hit for pass" cache objects
In-Reply-To: <4B79C2F1.9050901@newmediagateway.com>
References: <4B79C2F1.9050901@newmediagateway.com>
Message-ID: <4B79CFA8.8080908@gmail.com>

Justin Pasher wrote:
> Hello,
>
> Herein lies my dilemma. A request for the same URL 
> (http://www.example.com/) is sometimes cacheable and sometimes not 
> cacheable (it usually depends on whether it's the first time a user 
> visits the site and the Set-Cookie header has to be sent). What this 
> means is if I have a very heavy hit URL as a landing page from Google, 
> most of the time there will be a "hit for pass" cache object in Varnish, 
> since most people going to that page will have a Set-Cookie header.

Justin,

Rather than answer your question (which other people are answering), I'd 
suggest you reconsider using sessions and selectively caching full 
pages.  There are several other solutions that might work for you - for 
example, including personalised content via ESI, or overlaying it 
client-side with javascript.  We're using a combination of these to 
great effect - and ensure that any page containing a session cookie is 
never cached.

Obviously the based answer would depend on the nature of your apps, but 
it might be worth looking at in the longer term.  There's more than one 
way to crack an egg.



Rob


From rtshilston at gmail.com  Mon Feb 15 22:52:01 2010
From: rtshilston at gmail.com (Rob S)
Date: Mon, 15 Feb 2010 22:52:01 +0000
Subject: Understand "hit for pass" cache objects
In-Reply-To: <4B79CFA8.8080908@gmail.com>
References: <4B79C2F1.9050901@newmediagateway.com> <4B79CFA8.8080908@gmail.com>
Message-ID: <4B79D011.1090706@gmail.com>

Rob S wrote:
> Justin Pasher wrote:
>   
>> Hello,
>>
>> Herein lies my dilemma. A request for the same URL 
>> (http://www.example.com/) is sometimes cacheable and sometimes not 
>> cacheable (it usually depends on whether it's the first time a user 
>> visits the site and the Set-Cookie header has to be sent). What this 
>> means is if I have a very heavy hit URL as a landing page from Google, 
>> most of the time there will be a "hit for pass" cache object in Varnish, 
>> since most people going to that page will have a Set-Cookie header.
>>     
>
> Justin,
>
> Rather than answer your question (which other people are answering), I'd 
> suggest you reconsider using sessions and selectively caching full 
> pages.  There are several other solutions that might work for you - for 
> example, including personalised content via ESI, or overlaying it 
> client-side with javascript.  We're using a combination of these to 
> great effect - and ensure that any page containing a session cookie is 
> never cached.
>
> Obviously the based 
I meant "appropriate"  - goodness knows what I was typing!

> answer would depend on the nature of your apps, but 
> it might be worth looking at in the longer term.  There's more than one 
> way to crack an egg.
>
>   
> Rob
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>   



From phk at phk.freebsd.dk  Tue Feb 16 12:06:24 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 16 Feb 2010 12:06:24 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Sun, 14 Feb 2010 19:11:30 +0100."
	<4B783CD2.3030503@schokola.de> 
Message-ID: <66594.1266321984@critter.freebsd.dk>

In message <4B783CD2.3030503 at schokola.de>, Nils Goroll writes:

>Regarding Solaris, this piece of code here
>
>http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/tcp/tcp.c#11049
>

Yes, I read that, and that's one of the reasons I am still not convinced
that this is indeed a Solaris issue.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From john at 7fff.com  Tue Feb 16 14:36:08 2010
From: john at 7fff.com (John Norman)
Date: Tue, 16 Feb 2010 09:36:08 -0500
Subject: Not seeing a successful purge
In-Reply-To: <87sk92nbp5.fsf@qurzaw.linpro.no>
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
	<b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
	<b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
	<87sk92nbp5.fsf@qurzaw.linpro.no>
Message-ID: <b6b8b6b71002160636l4223720el97e612dec2edf9f@mail.gmail.com>

Thanks Ken, Laurence, and Tollef.

I'm going to add the normalization for gzip/deflate in vcl_recv

But for user-agent:

While my backend does say: "Vary: User-Agent" I do also have this in vcl_recv:

      unset req.http.user-agent;

Isn't that enough (i.e., if I unset req.http.user-agent in my VCL, can
I leave Vary: User-Agent on the backend)? I ask because it may be
problematic to fix the backend in this case.

We have no content that differs depending on the user agent.

On Mon, Feb 15, 2010 at 3:29 AM, Tollef Fog Heen
<tfheen at varnish-software.com> wrote:
>
> Yes, this means that if you know your backend only cares about
> gzip/non-gzip, you should normalise the header in vcl_recv. ?Varnish
> can't know this, as it requires knowledge of your backend and
> application.
>
> However, even if you changed that, you still have a Vary on
> user-agent.


From phk at phk.freebsd.dk  Tue Feb 16 20:48:45 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 16 Feb 2010 20:48:45 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Mon, 15 Feb 2010 11:22:36 GMT."
	<282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com> 
Message-ID: <81081.1266353325@critter.freebsd.dk>


OK,

It took me a day to liberate a machine to install OpenSolaris on.

Then it took most of a day to remember why I really like FreeBSD
over Solaris.

Then I got distracted by the failing non-blocking connect to backends
and ran truss.

Then I found the root-cause of the problem.

We need CFLAGS to contain -mt on solaris, otherwise errno does not
get macro-fied to be per-thread.

That's where the: EBADF comes from, some entirely different
filedescriptor a long time ago, in the master process...

try:
	env CFLAGS=-mt sh configure

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From slink at schokola.de  Wed Feb 17 09:59:22 2010
From: slink at schokola.de (Nils Goroll)
Date: Wed, 17 Feb 2010 10:59:22 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <81081.1266353325@critter.freebsd.dk>
References: <81081.1266353325@critter.freebsd.dk>
Message-ID: <4B7BBDFA.7080502@schokola.de>

Hi Poul-Henning and all,

> We need CFLAGS to contain -mt on solaris, otherwise errno does not
> get macro-fied to be per-thread.
> 
> That's where the: EBADF comes from, some entirely different
> filedescriptor a long time ago, in the master process...

Fantastic. Thank you for putting so much effort into this.

But also: Stupid I didn't think about this. See how I'm compiling varnish since 
I started working with it:

## 64bit
LDFLAGS="-lpthread"
CFLAGS="-D_REENTRANT -m64" \
VCC_CC="exec gcc -fpic -D_REENTRANT -m64 -shared -o %o %s" \
./configure \
	'--enable-debugging-symbols' \
	'--enable-developer-warnings' \
	'--enable-dependency-tracking' \
	....

IIUC, this effectively has the same effect as -mt for SunCC:

User Commands                                               cc(1)



NAME
      cc - C compiler

[...]

      -mt  Use this option to compile and link multithreaded code.
           The -mt option assures that libraries are linked in the
           appropriate order.

           This option passes -D_REENTRANT to the preprocessor and
           passes -lthread in the correct order to ld.

           If you are using POSIX threads, you must link with the
           options -mt -lpthread.

Nils


From phk at phk.freebsd.dk  Wed Feb 17 10:04:29 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 17 Feb 2010 10:04:29 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 17 Feb 2010 10:59:22 +0100."
	<4B7BBDFA.7080502@schokola.de> 
Message-ID: <11606.1266401069@critter.freebsd.dk>

In message <4B7BBDFA.7080502 at schokola.de>, Nils Goroll writes:
>Hi Poul-Henning and all,
>
>> We need CFLAGS to contain -mt on solaris, otherwise errno does not
>> get macro-fied to be per-thread.
>> 
>> That's where the: EBADF comes from, some entirely different
>> filedescriptor a long time ago, in the master process...
>
>Fantastic. Thank you for putting so much effort into this.
>
>But also: Stupid I didn't think about this. See how I'm compiling varnish since 
>I started working with it:

Yeah, we clearly need to improve the autocrap magic a bit to get stuff
like this right.

I have added a runtime test now, which panics the child process if the
errno variable is not working properly.

>VCC_CC="exec gcc -fpic -D_REENTRANT -m64 -shared -o %o %s"

Right now our VCC_CC default is for the sun-compiler I think ("-Kpic"),

That's another piece of autocrap stuff that needs fixed...


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From slink at schokola.de  Wed Feb 17 10:11:33 2010
From: slink at schokola.de (Nils Goroll)
Date: Wed, 17 Feb 2010 11:11:33 +0100
Subject: Child panics on OpenSolaris
In-Reply-To: <11606.1266401069@critter.freebsd.dk>
References: <11606.1266401069@critter.freebsd.dk>
Message-ID: <4B7BC0D5.7080000@schokola.de>

Hi Poul-Henning,

> Yeah, we clearly need to improve the autocrap magic a bit to get stuff
> like this right.

Yes. I'm sorry for not having documented this a year ago. Would have saved a lot 
of pain and effort...

> I have added a runtime test now, which panics the child process if the
> errno variable is not working properly.

Great!

>> VCC_CC="exec gcc -fpic -D_REENTRANT -m64 -shared -o %o %s"
> 
> Right now our VCC_CC default is for the sun-compiler I think ("-Kpic"),

Yes. The reason I prefer gcc is simply that SunCC is not available everywhere 
and if I understand the licence correctly, it is still only free to use for 
developers and development purposes.

> That's another piece of autocrap stuff that needs fixed...

Do you want me to do it?

Nils


From wrighty+varnishmisc at gmail.com  Wed Feb 17 10:30:29 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Wed, 17 Feb 2010 10:30:29 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <81081.1266353325@critter.freebsd.dk>
References: <282e72051002150322l57063a9ds98143093910c2673@mail.gmail.com>
	<81081.1266353325@critter.freebsd.dk>
Message-ID: <282e72051002170230k7ae8e0c8hc2d5226ca9288d51@mail.gmail.com>

On 16 February 2010 20:48, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> OK,
>
> It took me a day to liberate a machine to install OpenSolaris on.
>
> Then it took most of a day to remember why I really like FreeBSD
> over Solaris.
>
> Then I got distracted by the failing non-blocking connect to backends
> and ran truss.
>
> Then I found the root-cause of the problem.
>
> We need CFLAGS to contain -mt on solaris, otherwise errno does not
> get macro-fied to be per-thread.
>
> That's where the: EBADF comes from, some entirely different
> filedescriptor a long time ago, in the master process...
>
> try:
> ? ? ? ?env CFLAGS=-mt sh configure

Thanks so much for looking into this.  I spent yesterday attempting to
get some useful debug information out of dtrace with little success -
I either ended up with megabytes of debug dumps or empty files
depending on my D script.  Not exactly successful.

I've compiled with the additional -mt flag, here's my current
compilation process:

make clean
./autogen.sh
CFLAGS="-m64 -mt" CC=/opt/SunStudioExpress/bin/cc  ./configure --prefix=/opt
make
make install

And I'm starting up with:

newtask -p highfile /opt/sbin/varnishd -f /opt/etc/varnish/firebox.vcl -F \
-p cc_command='/opt/SunStudioExpress/bin/cc -Kpic -G -m64 -o %o %s' \
-T 127.0.0.1:9001 \
-s malloc,1G \
-p sess_timeout=5s \
-p max_restarts=12 \
-p waiter=poll \
-p connect_timeout=0s \
-p sess_workspace=65536

Varnish seems to be a *lot* happier and panics less regularly.  Panics
now all seem to suggest the error is "Connection reset by peer"
instead of EBADF

child (14052) Started
Child (14052) said Closed fds: 3 4 5 9 10 12 13
Child (14052) said Child starts
Child (14052) died signal=6
Child (14052) Panic message: Assert error in TCP_nonblocking(), tcp.c line 172:
  Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
(int))&0xff)<<16)| ('f'<<8)|126))), &i)) == 0) not true.
errno = 131 (Connection reset by peer)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447adb: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447adb]
  447de5: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447de5]
  fffffd7ff181e6da: /opt/lib/libvarnish.so.1.0.0'TCP_nonblocking+0x8a
[0xfffffd7ff181e6da]
  41924e: /opt/sbin/varnishd'vca_return_session+0x1de [0x41924e]
  4276ea: /opt/sbin/varnishd'cnt_wait+0x2ea [0x4276ea]
  42ccd6: /opt/sbin/varnishd'CNT_Session+0x526 [0x42ccd6]
  44a7ef: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a7ef]
  449d62: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449d62]
  44a315: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a315]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 1742b68 {
  fd = 40, id = 40, xid = 0,
  client = 94.226.122.36:3380,
  step = STP_WAIT,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 1742bd8 {
    id = "sess",
    {s,f,r,e} = {17438e0,+19,+32787,+65536},
  },
  http[req] = {
    ws = 1742bd8[sess]
      "",
      "/pic/p2607_small.jpg",
      "HTTP/1.1",
      "Accept: */*",
      "Referer: http://www.firebox.com/?aff=1759/",
      "Accept-Language: nl-be",
      "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0)",
      "Accept-Encoding: gzip, deflate",
      "Connection: Keep-Alive",
      "host: media.firebox.com",
      "X-Forwarded-For: 94.226.122.36",
  },
},


And I'm also seeing the same error occur in http_copyheader() - could
this be due to the Range: aspect of the client request?

Child (12008) died signal=6
Child (12008) Panic message: Assert error in http_copyheader(),
cache_http.c line 647:
  Condition(n < to->shd) not true.
errno = 131 (Connection reset by peer)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447adb: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447adb]
  447de5: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447de5]
  440791: /opt/sbin/varnishd'http_copyheader+0x1c1 [0x440791]
  4423b1: /opt/sbin/varnishd'http_FilterFields+0xdc1 [0x4423b1]
  429c4d: /opt/sbin/varnishd'cnt_fetch+0x11fd [0x429c4d]
  42cf3a: /opt/sbin/varnishd'CNT_Session+0x78a [0x42cf3a]
  44a7ef: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a7ef]
  449d62: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449d62]
  44a315: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a315]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 397bf38 {
  fd = 56, id = 56, xid = 1848010778,
  client = 82.71.124.65:60324,
  step = STP_FETCH,
  handling = pass,
  err_code = 206, err_reason = (null),
  restarts = 0, esis = 0
  ws = 397bfa8 {
    id = "sess",
    {s,f,r,e} = {397ccb0,+900,0,+65536},
  },
  http[req] = {
    ws = 397bfa8[sess]
      "GET",
      "/xml/rss.top20.000.xml",
      "HTTP/1.1",
      "Host: www.firebox.com",
      "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6",
      "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
      "Accept-Language: en-gb,en;q=0.5",
      "Accept-Encoding: gzip,deflate",
      "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
      "Keep-Alive: 115",
      "Connection: keep-alive",
      "X-Moz: livebookmarks",
      "Cookie: user_session=XXXX;
locale=company_id%3A0%2Ccurrency_id%3A0%2Clanguage_id%3A0%2Ccountry%3AUnited+Kingdom;
xp_list=52%3D1;
__utma=64137912.1325032789.1266225177.1266397371.1266400910.11;
__utmc=64137912;
__utmz=64137912.1266225177.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none);
__utmb=64137912",
      "Range: bytes=2494-",
      "If-Range: "14b800b-678d-47fc841cd4140"",
      "Cache-Control: max-age=0",
      "X-Forwarded-For: 82.71.124.65",
  },
  worker = fffffd7ff7017d30 {
    ws = fffffd7ff7017e78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff7005c40,+323,0,+65536},
    },
    http[bereq] = {
      ws = fffffd7ff7017e78[wrk]
        "GET",
        "/xml/rss.top20.000.xml",
        "HTTP/1.1",
        "Host: www.firebox.com",
        "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6",
        "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
        "Accept-Language: en-gb,en;q=0.5",
        "Accept-Encoding: gzip,deflate",
        "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
        "X-Moz: livebookmarks",
        "Cookie: user_session=XXXX;
locale=company_id%3A0%2Ccurrency_id%3A0%2Clanguage_id%3A0%2Ccountry%3AUnited+Kingdom;
xp_list=52%3D1;
__utma=64137912.1325032789.1266225177.1266397371.1266400910.11;
__utmc=64137912;
__utmz=64137912.1266225177.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none);
__utmb=64137912",
        "Range: bytes=2494-",
        "If-Range: "14b800b-678d-47fc841cd4140"",
        "X-Forwarded-For: 82.71.124.65",
        "X-Varnish: 1848010778",
    },
    http[beresp] = {
      ws = fffffd7ff7017e78[wrk]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Wed, 17 Feb 2010 10:03:18 GMT",
        "Server: Apache",
        "Last-Modified: Wed, 17 Feb 2010 09:13:01 GMT",
        "ETag: "14b800b-678d-47fc841cd4140"",
        "Accept-Ranges: bytes",
        "Content-Length: 24015",
        "Content-Range: bytes 2494-26508/26509",
        "Connection: close",
        "Content-Type: application/xml",
    },
    },
    vcl = {
      srcname = {
        "input",
        "Default",
      },
    },
  obj = 7202020 {
    xid = 1848010778,
    ws = 7202040 {
      id = "obj",
      {s,f,r,e} = {7202225,7202225,0,+220},
    },
    http[obj] = {
      ws = 7202040[obj]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Wed, 17 Feb 2010 10:03:18 GMT",
        "Server: Apache",
        "Last-Modified: Wed, 17 Feb 2010 09:13:01 GMT",
        "ETag: "14b800b-678d-47fc841cd4140"",
    },
    len = 0,
    store = {
    },
  },
},

Cheers,

Paul.


From phk at phk.freebsd.dk  Wed Feb 17 10:52:07 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 17 Feb 2010 10:52:07 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 17 Feb 2010 11:11:33 +0100."
	<4B7BC0D5.7080000@schokola.de> 
Message-ID: <24645.1266403927@critter.freebsd.dk>

In message <4B7BC0D5.7080000 at schokola.de>, Nils Goroll writes:

>> That's another piece of autocrap stuff that needs fixed...
>
>Do you want me to do it?

Send patches!

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Wed Feb 17 10:57:22 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 17 Feb 2010 10:57:22 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 17 Feb 2010 10:30:29 GMT."
	<282e72051002170230k7ae8e0c8hc2d5226ca9288d51@mail.gmail.com> 
Message-ID: <24680.1266404242@critter.freebsd.dk>

In message <282e72051002170230k7ae8e0c8hc2d5226ca9288d51 at mail.gmail.com>, Paul 
Wright writes:

>I've compiled with the additional -mt flag, here's my current
>compilation process:

Please pull a brand new -trunk, I have added a check for errno 
working and I would like to make sure that passes for you also.

>Child (14052) Panic message: Assert error in TCP_nonblocking(), tcp.c line =
>172:
>  Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
>(int))&0xff)<<16)| ('f'<<8)|126))), &i)) =3D=3D 0) not true.
>errno =3D 131 (Connection reset by peer)


Now, _this_ errno I can actually belive, because that matches
the packet traces we have seen, and it is a plausible scenario.

The fact that Solaris docs does not mention ECONNRESET as a legal
error return for ioctl is a minor detail in that context.

The difference here is that the traditional BSD stack does not
return ECONNRESET until you try to move data on the socket,
giving you much simpler error checking on socket-state changes
(ioctl, fcntl, setsockopt, getsockopt etc)

So now that we have reached the root-cause, I need to go through
and do complex error-checking for all the socket-state calls.

Hopefully done later today...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From wrighty+varnishmisc at gmail.com  Wed Feb 17 11:10:58 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Wed, 17 Feb 2010 11:10:58 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <24680.1266404242@critter.freebsd.dk>
References: <282e72051002170230k7ae8e0c8hc2d5226ca9288d51@mail.gmail.com>
	<24680.1266404242@critter.freebsd.dk>
Message-ID: <282e72051002170310g565a26d8s98170fcebb9b2997@mail.gmail.com>

On 17 February 2010 10:57, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002170230k7ae8e0c8hc2d5226ca9288d51 at mail.gmail.com>, Paul
> Wright writes:
>
>>I've compiled with the additional -mt flag, here's my current
>>compilation process:
>
> Please pull a brand new -trunk, I have added a check for errno
> working and I would like to make sure that passes for you also.

I have pulled the latest revision and can confirm that unlink("/")
failed as expected.  I ran it briefly and saw this panic:

Child (28554) died signal=6
Child (28554) Panic message: Assert error in http_copyheader(),
cache_http.c line 647:
  Condition(n < to->shd) not true.
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447adb: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447adb]
  447de5: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447de5]
  440791: /opt/sbin/varnishd'http_copyheader+0x1c1 [0x440791]
  4423b1: /opt/sbin/varnishd'http_FilterFields+0xdc1 [0x4423b1]
  429c4d: /opt/sbin/varnishd'cnt_fetch+0x11fd [0x429c4d]
  42cf3a: /opt/sbin/varnishd'CNT_Session+0x78a [0x42cf3a]
  44a7ef: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a7ef]
  449d62: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449d62]
  44a315: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a315]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 18c9b78 {
  fd = 38, id = 38, xid = 789049749,
  client = 82.71.124.65:58190,
  step = STP_FETCH,
  handling = pass,
  err_code = 206, err_reason = (null),
  restarts = 0, esis = 0
  ws = 18c9be8 {
    id = "sess",
    {s,f,r,e} = {18ca8f0,+884,0,+65536},
  },
  http[req] = {
    ws = 18c9be8[sess]
      "GET",
      "/xml/rss.top20.000.xml",
      "HTTP/1.1",
      "Host: www.firebox.com",
      "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6",
      "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
      "Accept-Language: en-gb,en;q=0.5",
      "Accept-Encoding: gzip,deflate",
      "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
      "Keep-Alive: 115",
      "Connection: keep-alive",
      "X-Moz: livebookmarks",
      "Cookie: user_session=XXXX;
locale=company_id%3A0%2Ccurrency_id%3A0%2Clanguage_id%3A0%2Ccountry%3AUnited+Kingdom;
xp_list=52%3D1;
__utma=64137912.1325032789.1266225177.1266397371.1266400910.11;
__utmc=64137912;
__utmz=64137912.1266225177.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)",
      "Range: bytes=15136-",
      "If-Range: "14b800b-678d-47fc91860e540"",
      "Cache-Control: max-age=0",
      "X-Forwarded-For: 82.71.124.65",
  },
  worker = fffffd7ff69fad30 {
    ws = fffffd7ff69fae78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff69e8c40,+323,0,+65536},
    },
    http[bereq] = {
      ws = fffffd7ff69fae78[wrk]
        "GET",
        "/xml/rss.top20.000.xml",
        "HTTP/1.1",
        "Host: www.firebox.com",
        "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6",
        "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
        "Accept-Language: en-gb,en;q=0.5",
        "Accept-Encoding: gzip,deflate",
        "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
        "X-Moz: livebookmarks",
        "Cookie: user_session=XXXX;
locale=company_id%3A0%2Ccurrency_id%3A0%2Clanguage_id%3A0%2Ccountry%3AUnited+Kingdom;
xp_list=52%3D1;
__utma=64137912.1325032789.1266225177.1266397371.1266400910.11;
__utmc=64137912;
__utmz=64137912.1266225177.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)",
        "Range: bytes=15136-",
        "If-Range: "14b800b-678d-47fc91860e540"",
        "X-Forwarded-For: 82.71.124.65",
        "X-Varnish: 789049749",
    },
    http[beresp] = {
      ws = fffffd7ff69fae78[wrk]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Wed, 17 Feb 2010 10:48:30 GMT",
        "Server: Apache",
        "Last-Modified: Wed, 17 Feb 2010 10:13:01 GMT",
        "ETag: "14b800b-678d-47fc91860e540"",
        "Accept-Ranges: bytes",
        "Content-Length: 11373",
        "Content-Range: bytes 15136-26508/26509",
        "Connection: close",
        "Content-Type: application/xml",
    },
    },
    vcl = {
      srcname = {
        "input",
        "Default",
      },
    },
  obj = 33336a0 {
    xid = 789049749,
    ws = 33336c0 {
      id = "obj",
      {s,f,r,e} = {33338a5,33338a5,0,+220},
    },
    http[obj] = {
      ws = 33336c0[obj]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Wed, 17 Feb 2010 10:48:30 GMT",
        "Server: Apache",
        "Last-Modified: Wed, 17 Feb 2010 10:13:01 GMT",
        "ETag: "14b800b-678d-47fc91860e540"",
    },
    len = 0,
    store = {
    },
  },
},


>>Child (14052) Panic message: Assert error in TCP_nonblocking(), tcp.c line =
>>172:
>> ?Condition((ioctl(sock, ((int)((uint32_t)(0x80000000|(((sizeof
>>(int))&0xff)<<16)| ('f'<<8)|126))), &i)) =3D=3D 0) not true.
>>errno =3D 131 (Connection reset by peer)
>
>
> Now, _this_ errno I can actually belive, because that matches
> the packet traces we have seen, and it is a plausible scenario.
>
> The fact that Solaris docs does not mention ECONNRESET as a legal
> error return for ioctl is a minor detail in that context.
>
> The difference here is that the traditional BSD stack does not
> return ECONNRESET until you try to move data on the socket,
> giving you much simpler error checking on socket-state changes
> (ioctl, fcntl, setsockopt, getsockopt etc)
>
> So now that we have reached the root-cause, I need to go through
> and do complex error-checking for all the socket-state calls.
>
> Hopefully done later today...

Grand.

Paul.


From phk at phk.freebsd.dk  Wed Feb 17 11:14:30 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 17 Feb 2010 11:14:30 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 17 Feb 2010 11:10:58 GMT."
	<282e72051002170310g565a26d8s98170fcebb9b2997@mail.gmail.com> 
Message-ID: <24770.1266405270@critter.freebsd.dk>

In message <282e72051002170310g565a26d8s98170fcebb9b2997 at mail.gmail.com>, Paul 
Wright writes:
>On 17 February 2010 10:57, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

>I have pulled the latest revision and can confirm that unlink("/")
>failed as expected.  I ran it briefly and saw this panic:
>
>Child (28554) died signal=3D6
>Child (28554) Panic message: Assert error in http_copyheader(),
>cache_http.c line 647:
>  Condition(n < to->shd) not true.

Sounds like you got too many headers from the backend, if so, 
consider increasing the parameter 'http_headers'


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From wrighty+varnishmisc at gmail.com  Wed Feb 17 16:52:26 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Wed, 17 Feb 2010 16:52:26 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <24770.1266405270@critter.freebsd.dk>
References: <282e72051002170310g565a26d8s98170fcebb9b2997@mail.gmail.com>
	<24770.1266405270@critter.freebsd.dk>
Message-ID: <282e72051002170852g532cd8acqb570e6db4b82974c@mail.gmail.com>

On 17 February 2010 11:14, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002170310g565a26d8s98170fcebb9b2997 at mail.gmail.com>, Paul
> Wright writes:
>>On 17 February 2010 10:57, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
>>I have pulled the latest revision and can confirm that unlink("/")
>>failed as expected. ?I ran it briefly and saw this panic:
>>
>>Child (28554) died signal=3D6
>>Child (28554) Panic message: Assert error in http_copyheader(),
>>cache_http.c line 647:
>> ?Condition(n < to->shd) not true.
>
> Sounds like you got too many headers from the backend, if so,
> consider increasing the parameter 'http_headers'

I pulled r4574 with the new TCP_Assert() changes, I increased
http_headers to 128 and it ran like a champ for 25 minutes.  Then a
client made a Range request resulting in a "Partial Content" response
which produced the panic included below.  I've boiled down the request
to a simple curl command that consistently panics the child:

curl -v -H "Range: bytes=0-1" -H "Cookie: foo" http://192.168.0.35/robots.txt

(The cookie header ensures the request is passed through to the
backend. Curl will respond with "Failure when receiving data from the
peer".)

I note that ticket #466 mentions that Varnish doesn't support Range
requests and r3910 should stop such requests passing though - is this
expected behaviour?  Should I stop the backend from generating partial
content responses?  Or should there be a check for such requests and
they should be piped instead of passed?

Paul.

Child (21350) died signal=6
Child (21350) Panic message: Assert error in http_copyheader(),
cache_http.c line 647:
  Condition(n < to->shd) not true.
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447b2b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447b2b]
  447e35: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447e35]
  4407e1: /opt/sbin/varnishd'http_copyheader+0x1c1 [0x4407e1]
  442401: /opt/sbin/varnishd'http_FilterFields+0xdc1 [0x442401]
  429c9d: /opt/sbin/varnishd'cnt_fetch+0x11fd [0x429c9d]
  42cf8a: /opt/sbin/varnishd'CNT_Session+0x78a [0x42cf8a]
  44a83f: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a83f]
  449db2: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449db2]
  44a365: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a365]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 1140e08 {
  fd = 77, id = 77, xid = 133352112,
  client = 66.235.125.136:38373,
  step = STP_FETCH,
  handling = pass,
  err_code = 206, err_reason = (null),
  restarts = 0, esis = 0
  ws = 1140e78 {
    id = "sess",
    {s,f,r,e} = {1142400,+388,0,+65536},
  },
  http[req] = {
    ws = 1140e78[sess]
      "GET",
      "/robots.txt",
      "HTTP/1.1",
      "TE: deflate,gzip;q=0.3",
      "Connection: TE, close",
      "From: robots at pronto.com",
      "Host: www.firebox.com",
      "Range: bytes=0-199999",
      "User-Agent: RedCarpet/1.4 (http://www.pronto.com/robots.html)",
      "Cookie: CFTOKEN=aeed9fb6cc27a0f7-8F680632-1517-0C84-6887BD4A85FF98A8;
CFID=128110309",
      "Cookie2: $Version="1"",
      "X-Forwarded-For: 66.235.125.136",
  },
  worker = fffffd7ff7813d30 {
    ws = fffffd7ff7813e78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff7801c40,+528,0,+65536},
    },
    http[bereq] = {
      ws = fffffd7ff7813e78[wrk]
        "GET",
        "/robots.txt",
        "HTTP/1.1",
        "From: robots at pronto.com",
        "Host: www.firebox.com",
        "Range: bytes=0-199999",
        "User-Agent: RedCarpet/1.4 (http://www.pronto.com/robots.html)",
        "Cookie:
CFTOKEN=aeed9fb6cc27a0f7-8F680632-1517-0C84-6887BD4A85FF98A8;
CFID=128110309",
        "Cookie2: $Version="1"",
        "X-Forwarded-For: 66.235.125.136",
        "X-Varnish: 133352112",
    },
    http[beresp] = {
      ws = fffffd7ff7813e78[wrk]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Wed, 17 Feb 2010 16:25:42 GMT",
        "Server: Apache",
        "Last-Modified: Fri, 11 Dec 2009 18:15:28 GMT",
        "ETag: "19c0073-de-47a77e88b9000"",
        "Accept-Ranges: bytes",
        "Content-Length: 222",
        "Content-Range: bytes 0-221/222",
        "Connection: close",
        "Content-Type: text/plain",
    },
    },
    vcl = {
      srcname = {
        "input",
        "Default",
      },
    },
  obj = 8c1d8a0 {
    xid = 133352112,
    ws = 8c1d8c0 {
      id = "obj",
      {s,f,r,e} = {8c1daa5,8c1daa5,0,+213},
    },
    http[obj] = {
      ws = 8c1d8c0[obj]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Wed, 17 Feb 2010 16:25:42 GMT",
        "Server: Apache",
        "Last-Modified: Fri, 11 Dec 2009 18:15:28 GMT",
        "ETag: "19c0073-de-47a77e88b9000"",
    },
    len = 0,
    store = {
    },
  },
},


From phk at phk.freebsd.dk  Wed Feb 17 18:46:26 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 17 Feb 2010 18:46:26 +0000
Subject: Child panics on OpenSolaris 
In-Reply-To: Your message of "Wed, 17 Feb 2010 16:52:26 GMT."
	<282e72051002170852g532cd8acqb570e6db4b82974c@mail.gmail.com> 
Message-ID: <6331.1266432386@critter.freebsd.dk>

In message <282e72051002170852g532cd8acqb570e6db4b82974c at mail.gmail.com>, Paul 
Wright writes:

>(The cookie header ensures the request is passed through to the
>backend. Curl will respond with "Failure when receiving data from the
>peer".)

How on earth did you get the Range header to be passed through to
the backend ?  It should have been filtered out...

Can you capture a varnishlog for this one ?

Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From wrighty+varnishmisc at gmail.com  Thu Feb 18 10:08:11 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Thu, 18 Feb 2010 10:08:11 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <6331.1266432386@critter.freebsd.dk>
References: <282e72051002170852g532cd8acqb570e6db4b82974c@mail.gmail.com>
	<6331.1266432386@critter.freebsd.dk>
Message-ID: <282e72051002180208o1a3d33e1p82e14b9443677b03@mail.gmail.com>

On 17 February 2010 18:46, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002170852g532cd8acqb570e6db4b82974c at mail.gmail.com>, Paul
> Wright writes:
>
>>(The cookie header ensures the request is passed through to the
>>backend. Curl will respond with "Failure when receiving data from the
>>peer".)
>
> How on earth did you get the Range header to be passed through to
> the backend ? ?It should have been filtered out...
>
> Can you capture a varnishlog for this one ?

Here's the output:

    0 CLI          - Rd ping
    0 CLI          - Wr 200 PONG 1266486712 1.0
    5 SessionOpen  c 192.168.0.30 60069 :80
    5 ReqStart     c 192.168.0.30 60069 1736091917
    5 RxRequest    c GET
    5 RxURL        c /robots.txt
    5 RxProtocol   c HTTP/1.1
    5 RxHeader     c User-Agent: curl/7.19.4 (i386-pc-solaris2.11)
libcurl/7.19.4 OpenSSL/0.9.8a zlib/1.2.3 libidn/1.9
    5 RxHeader     c Host: 192.168.0.35
    5 RxHeader     c Accept: */*
    5 RxHeader     c Range: bytes=0-1
    5 RxHeader     c Cookie: foo
    5 VCL_call     c recv
    5 VCL_return   c pass
    5 VCL_call     c hash
    5 VCL_return   c hash
    5 VCL_call     c pass
    5 VCL_return   c pass
    9 BackendOpen  b martin 192.168.0.35 54372 192.168.0.31 80
    5 Backend      c 9 dynamic_director martin
    9 TxRequest    b GET
    9 TxURL        b /robots.txt
    9 TxProtocol   b HTTP/1.1
    9 TxHeader     b User-Agent: curl/7.19.4 (i386-pc-solaris2.11)
libcurl/7.19.4 OpenSSL/0.9.8a zlib/1.2.3 libidn/1.9
    9 TxHeader     b Host: 192.168.0.35
    9 TxHeader     b Accept: */*
    9 TxHeader     b Range: bytes=0-1
    9 TxHeader     b Cookie: foo
    9 TxHeader     b X-Forwarded-For: 192.168.0.30
    9 TxHeader     b X-Varnish: 1736091917
    0 WorkThread   - fffffd7ff9e00d30 start
    0 CLI          - Rd vcl.load "boot" ./vcl.ORk8t3RP.so
    0 CLI          - Wr 200 Loaded "./vcl.ORk8t3RP.so" as "boot"
    0 CLI          - Rd vcl.use "boot"
    0 CLI          - Wr 200
    0 CLI          - Rd start
    0 Debug        - "Acceptor poll space increased to 512"
    0 Debug        - "Acceptor is poll"
    0 CLI          - Wr 200
    0 WorkThread   - fffffd7ff9206d30 start
    0 WorkThread   - fffffd7ff9007d30 start
    0 WorkThread   - fffffd7ff8e08d30 start
    0 WorkThread   - fffffd7ff8c09d30 start
    0 WorkThread   - fffffd7ff8a0ad30 start
    0 WorkThread   - fffffd7ff880bd30 start
    0 WorkThread   - fffffd7ff860cd30 start
    0 WorkThread   - fffffd7ff840dd30 start
    0 WorkThread   - fffffd7ff820ed30 start

The VCL used hasn't changed substantially from the original included
at the beginning of this thread, only vcl_recv is defined and I don't
think it's doing anything stupid.

sub vcl_recv {
        // normalise static requests
        if ( req.http.host ~ "media([0-9]+).firebox.com" ) {
                set req.http.host = "media.firebox.com";
        }

        //catch any relative image URLs that haven't been repointed to media
        if ( req.http.host != "media.firebox.com" &&
             ( req.url ~ "^/pic/.+" || req.url ~ "^/i/.+" ) ) {
                        set req.http.host = "media.firebox.com";
        }

        // split traffic based on host name
        if ( req.http.host == "media.firebox.com" ) {
                remove req.http.cookie;
                set req.backend = static_director;
        } else {
                // dynamic content that should be cached (ie no
cookies required)
                // these patterns should match up with settings.inc on
the PHP side
                if ( req.url ~ "^/styles/(.+).css$" ||
                     req.url ~ "^/js/(.+).js$" ) {
                        remove req.http.cookie;
                }
                //default all requests to the dynamic backend
                set req.backend = dynamic_director;
        }
}

This is on r4574, compiled with Sun Studio.

Cheers,

Paul.

Child (2570) died signal=6
Child (2570) Panic message: Assert error in http_copyheader(),
cache_http.c line 647:
  Condition(n < to->shd) not true.
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447b2b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447b2b]
  447e35: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447e35]
  4407e1: /opt/sbin/varnishd'http_copyheader+0x1c1 [0x4407e1]
  442401: /opt/sbin/varnishd'http_FilterFields+0xdc1 [0x442401]
  429c9d: /opt/sbin/varnishd'cnt_fetch+0x11fd [0x429c9d]
  42cf8a: /opt/sbin/varnishd'CNT_Session+0x78a [0x42cf8a]
  44a83f: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a83f]
  449db2: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449db2]
  44a365: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a365]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
sp = 5eec58 {
  fd = 5, id = 5, xid = 1315520023,
  client = 192.168.0.30:41925,
  step = STP_FETCH,
  handling = pass,
  err_code = 206, err_reason = (null),
  restarts = 0, esis = 0
  ws = 5eecc8 {
    id = "sess",
    {s,f,r,e} = {5f0250,+257,0,+65536},
  },
  http[req] = {
    ws = 5eecc8[sess]
      "GET",
      "/robots.txt",
      "HTTP/1.1",
      "User-Agent: curl/7.19.4 (i386-pc-solaris2.11) libcurl/7.19.4
OpenSSL/0.9.8a zlib/1.2.3 libidn/1.9",
      "Host: 192.168.0.35",
      "Accept: */*",
      "Range: bytes=0-1",
      "Cookie: foo",
      "X-Forwarded-For: 192.168.0.30",
  },
  worker = fffffd7ff820ed30 {
    ws = fffffd7ff820ee78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff81fcc40,+305,0,+65536},
    },
    http[bereq] = {
      ws = fffffd7ff820ee78[wrk]
        "GET",
        "/robots.txt",
        "HTTP/1.1",
        "User-Agent: curl/7.19.4 (i386-pc-solaris2.11) libcurl/7.19.4
OpenSSL/0.9.8a zlib/1.2.3 libidn/1.9",
        "Host: 192.168.0.35",
        "Accept: */*",
        "Range: bytes=0-1",
        "Cookie: foo",
        "X-Forwarded-For: 192.168.0.30",
        "X-Varnish: 1315520023",
    },
    http[beresp] = {
      ws = fffffd7ff820ee78[wrk]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Thu, 18 Feb 2010 09:57:51 GMT",
        "Server: Apache",
        "Last-Modified: Fri, 11 Dec 2009 18:15:28 GMT",
        "ETag: "19c0073-de-47a77e88b9000"",
        "Accept-Ranges: bytes",
        "Content-Length: 2",
        "Content-Range: bytes 0-1/222",
        "Connection: close",
        "Content-Type: text/plain",
    },
    },
    vcl = {
      srcname = {
        "input",
        "Default",
      },
    },
  obj = 600260 {
    xid = 1315520023,
    ws = 600280 {
      id = "obj",
      {s,f,r,e} = {600465,600465,0,+213},
    },
    http[obj] = {
      ws = 600280[obj]
        "HTTP/1.1",
        "206",
        "Partial Content",
        "Date: Thu, 18 Feb 2010 09:57:51 GMT",
        "Server: Apache",
        "Last-Modified: Fri, 11 Dec 2009 18:15:28 GMT",
        "ETag: "19c0073-de-47a77e88b9000"",
    },
    len = 0,
    store = {
    },
  },
},


From wrighty+varnishmisc at gmail.com  Thu Feb 18 12:07:06 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Thu, 18 Feb 2010 12:07:06 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <282e72051002180208o1a3d33e1p82e14b9443677b03@mail.gmail.com>
References: <282e72051002170852g532cd8acqb570e6db4b82974c@mail.gmail.com>
	<6331.1266432386@critter.freebsd.dk>
	<282e72051002180208o1a3d33e1p82e14b9443677b03@mail.gmail.com>
Message-ID: <282e72051002180407ndb416beoc464b441d86fa475@mail.gmail.com>

On 18 February 2010 10:08, Paul Wright <wrighty+varnishmisc at gmail.com> wrote:
> On 17 February 2010 18:46, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> In message <282e72051002170852g532cd8acqb570e6db4b82974c at mail.gmail.com>, Paul
>> Wright writes:
>>
>>>(The cookie header ensures the request is passed through to the
>>>backend. Curl will respond with "Failure when receiving data from the
>>>peer".)
>>
>> How on earth did you get the Range header to be passed through to
>> the backend ? ?It should have been filtered out...

Just as a sanity check I compiled r4574 on a Fedora x64 machine with
gcc and it appears that Range requests still make it through to the
backend, but no panics:

   11 SessionOpen  c 192.168.0.169 60860 192.168.0.87:80
   11 ReqStart     c 192.168.0.169 60860 1989537926
   11 RxRequest    c GET
   11 RxURL        c /robots.txt
   11 RxProtocol   c HTTP/1.1
   11 RxHeader     c User-Agent: curl/7.19.4
(universal-apple-darwin10.0) libcurl/7.19.4 OpenSSL/0.9.8l zlib/1.2.3
   11 RxHeader     c Host: 192.168.0.87
   11 RxHeader     c Accept: */*
   11 RxHeader     c Range: bytes=0-1
   11 RxHeader     c Cookie: foo
   11 VCL_call     c recv
   11 VCL_return   c pass
   11 VCL_call     c hash
   11 VCL_return   c hash
   11 VCL_call     c pass
   11 VCL_return   c pass
   12 BackendClose - paul
   12 BackendOpen  b paul 192.168.0.83 54663 192.168.0.83 80
   11 Backend      c 12 dynamic_director paul
   12 TxRequest    b GET
   12 TxURL        b /robots.txt
   12 TxProtocol   b HTTP/1.1
   12 TxHeader     b User-Agent: curl/7.19.4
(universal-apple-darwin10.0) libcurl/7.19.4 OpenSSL/0.9.8l zlib/1.2.3
   12 TxHeader     b Host: 192.168.0.87
   12 TxHeader     b Accept: */*
   12 TxHeader     b Range: bytes=0-1
   12 TxHeader     b Cookie: foo
   12 TxHeader     b X-Forwarded-For: 192.168.0.169
   12 TxHeader     b X-Varnish: 1989537926
   12 RxProtocol   b HTTP/1.1
   12 RxStatus     b 206
   12 RxResponse   b Partial Content
   12 RxHeader     b Date: Thu, 18 Feb 2010 12:00:51 GMT
   12 RxHeader     b Server: Apache
   12 RxHeader     b Last-Modified: Mon, 14 Dec 2009 11:00:28 GMT
   12 RxHeader     b ETag: "a2ad-de-47aae2e6fcaa0"
   12 RxHeader     b Accept-Ranges: bytes
   12 RxHeader     b Content-Length: 2
   12 RxHeader     b Content-Range: bytes 0-1/222
   12 RxHeader     b Content-Type: text/plain
   12 RxHeader     b X-Pad: avoid browser bug
   11 TTL          c 1989537926 RFC 120 1266494451 0 0 0 0
   11 VCL_call     c fetch
   11 VCL_return   c pass
   11 ObjProtocol  c HTTP/1.1
   11 ObjStatus    c 206
   11 ObjResponse  c Partial Content
   11 ObjHeader    c Date: Thu, 18 Feb 2010 12:00:51 GMT
   11 ObjHeader    c Server: Apache
   11 ObjHeader    c Last-Modified: Mon, 14 Dec 2009 11:00:28 GMT
   11 ObjHeader    c ETag: "a2ad-de-47aae2e6fcaa0"
   11 ObjHeader    c Content-Type: text/plain
   11 ObjHeader    c X-Pad: avoid browser bug
   12 BackendReuse b paul
   11 Length       c 2
   11 VCL_call     c deliver
   11 VCL_return   c deliver
   11 TxProtocol   c HTTP/1.1
   11 TxStatus     c 206
   11 TxResponse   c Partial Content
   11 TxHeader     c Server: Apache
   11 TxHeader     c Last-Modified: Mon, 14 Dec 2009 11:00:28 GMT
   11 TxHeader     c ETag: "a2ad-de-47aae2e6fcaa0"
   11 TxHeader     c Content-Type: text/plain
   11 TxHeader     c X-Pad: avoid browser bug
   11 TxHeader     c Content-Length: 2
   11 TxHeader     c Date: Thu, 18 Feb 2010 12:00:51 GMT
   11 TxHeader     c X-Varnish: 1989537926
   11 TxHeader     c Age: 0
   11 TxHeader     c Via: 1.1 varnish
   11 TxHeader     c Connection: keep-alive
   11 ReqEnd       c 1989537926 1266494451.053643227
1266494451.055507183 0.000101566 0.001832485 0.000031471
   11 SessionClose c EOF
   11 ReqEnd       c 0 1266494451.055849552 1266494451.055849552
0.000342369 0.000000000 0.000000000
   11 StatSess     c 192.168.0.169 60860 0 1 1 0 1 1 306 2

Paul.


From alessandro.ronchi at soasi.com  Thu Feb 18 20:58:39 2010
From: alessandro.ronchi at soasi.com (Alessandro Ronchi)
Date: Thu, 18 Feb 2010 21:58:39 +0100
Subject: Varnish and language cookie
Message-ID: <faf26db81002181258t52e8dccoe1dc12b0fb0c8da4@mail.gmail.com>

This is my configuration file:
http://dpaste.com/161264/

This is the site I'm trying to cache:
http://www.profumeriasilvia.com:989 (989 is varnish port).

My problem is that language is set inside a cookie.

So, If I try, for example, in order:
1) http://www.profumeriasilvia.com:989/product/eau-de-rance?lang=it
(italian)
2) http://www.profumeriasilvia.com:989/?lang=en (english)
3) http://www.profumeriasilvia.com:989/product/eau-de-rance  (should be
english, but it's italian).

In 3 I've the cookie named django_language.

I want to cache pages with django_language in hash if it's set, so all users
that choice that language will get the correct translated version.

I've used
set req.hash += req.http.cookie;

but It seems to don't work.

What's wrong?

Thanks in advance, best regards.





-- 
Alessandro Ronchi

http://www.soasi.com
SOASI - Sviluppo Software e Sistemi Open Source

http://hobbygiochi.com
Hobby & Giochi, l'e-commerce del divertimento
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100218/fb6d69c6/attachment.html>

From cosimo at streppone.it  Thu Feb 18 23:08:45 2010
From: cosimo at streppone.it (Cosimo Streppone)
Date: Fri, 19 Feb 2010 00:08:45 +0100
Subject: Varnish and language cookie
In-Reply-To: <faf26db81002181258t52e8dccoe1dc12b0fb0c8da4@mail.gmail.com>
References: <faf26db81002181258t52e8dccoe1dc12b0fb0c8da4@mail.gmail.com>
Message-ID: <op.u8cikvgds5ttvb@cn01>

In data 18 febbraio 2010 alle ore 21:58:39, Alessandro Ronchi  
<alessandro.ronchi at soasi.com> ha scritto:

> This is my configuration file:
> http://dpaste.com/161264/

Ciao Alessandro,

I'm no expert, but I think your config file
explicitly defeats caching when there is a cookie.

41  if (req.http.Authorization || req.http.Cookie) {

> I've used
> set req.hash += req.http.cookie;

I would suggest explicitly matching the "django_language"
cookie, setting a custom header with its contents, and
then using that as a hash part, so:

In vcl_recv():

     set req.http.X-Cookie-Language = regsub(req.http.Cookie, "...");

In vcl_hash():

     set req.hash += req.http.X-Cookie-Language;

This is part of one config I'm using, the vcl_recv() bit:

     if (req.http.Cookie ~ "language=") {
         set req.http.X-Varnish-Language =
             regsub(req.http.Cookie, "^.*?language=([^;]*?);*.*$", "\1");
     }

The regexp above is probably overly complicated.
I tried a couple of times to simplify it, but I always broke it.
Suggestions welcome :)

-- 
Cosimo


From wrighty+varnishmisc at gmail.com  Fri Feb 19 17:45:17 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Fri, 19 Feb 2010 17:45:17 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <6331.1266432386@critter.freebsd.dk>
References: <282e72051002170852g532cd8acqb570e6db4b82974c@mail.gmail.com>
	<6331.1266432386@critter.freebsd.dk>
Message-ID: <282e72051002190945i63a94283s1718f54d79f0f2a7@mail.gmail.com>

On 17 February 2010 18:46, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <282e72051002170852g532cd8acqb570e6db4b82974c at mail.gmail.com>, Paul
> Wright writes:
>
>>(The cookie header ensures the request is passed through to the
>>backend. Curl will respond with "Failure when receiving data from the
>>peer".)
>
> How on earth did you get the Range header to be passed through to
> the backend ? ?It should have been filtered out...

I added the following to the top of vcl_recv()

	if ( req.http.Range ) {
		unset req.http.Range;
	}

Varnish ran happily until tripping over the same bug (#649) as victori
(on r4573).  A couple of examples follow.

New personal best of 1 hour, 20 minutes uptime!

Paul.

Child (26791) died signal=6
Child (26791) Panic message: Assert error in VCA_Prep(),
cache_acceptor.c line 184:
  Condition(TCP_Check(setsockopt(sp->fd, 0xffff, 0x0080, &linger,
sizeof linger))) not true.
errno = 22 (Invalid argument)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447b2b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447b2b]
  447e35: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447e35]
  41862a: /opt/sbin/varnishd'VCA_Prep+0x29a [0x41862a]
  42a466: /opt/sbin/varnishd'cnt_first+0xb6 [0x42a466]
  42cd6a: /opt/sbin/varnishd'CNT_Session+0x56a [0x42cd6a]
  44a83f: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a83f]
  449db2: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449db2]
  44a365: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a365]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
  fffffd7ff653afb0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ff653afb0]
sp = 10e8ae08 {
  fd = 73, id = 73, xid = 0,
  client = 94.196.213.123:50084,
  step = STP_FIRST,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 10e8ae78 {
    id = "sess",
    {s,f,r,e} = {10e8c400,+21,0,+65536},
  },
  http[req] = {
    ws = 10e8ae78[sess]
      "",
      "/pic/p2031b.jpg",
      "HTTP/1.1",
      "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)",
      "Accept: image/png,image/*;q=0.8,*/*;q=0.5",
      "Accept-Language: en-us,en;q=0.5",
      "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
      "Keep-Alive: 300",
      "Connection: keep-alive",
      "Referer:
http://www.affordablegiftsolutions.com/index.php?option=com_cmsshopbuilder&view=category&id=55&Itemid=5&limitstart=400",
      "host: media.firebox.com",
      "X-Forwarded-For: 67.234.17.245",
  },
  worker = fffffd7ff2c96d30 {
    ws = fffffd7ff2c96e78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff2c84c40,fffffd7ff2c84c40,0,+65536},
    },
    },
},


Child cleanup complete
child (2199) Started
Child (2199) said Closed fds: 3 4 5 9 10 12 13
Child (2199) said Child starts

Child (8098) died signal=6
Child (8098) Panic message: Assert error in VCA_Prep(),
cache_acceptor.c line 184:
  Condition(TCP_Check(setsockopt(sp->fd, 0xffff, 0x0080, &linger,
sizeof linger))) not true.
errno = 22 (Invalid argument)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  447b1b: /opt/sbin/varnishd'pan_backtrace+0x1b [0x447b1b]
  447e25: /opt/sbin/varnishd'pan_ic+0x1c5 [0x447e25]
  41862a: /opt/sbin/varnishd'VCA_Prep+0x29a [0x41862a]
  42a456: /opt/sbin/varnishd'cnt_first+0xb6 [0x42a456]
  42cd5a: /opt/sbin/varnishd'CNT_Session+0x56a [0x42cd5a]
  44a82f: /opt/sbin/varnishd'wrk_do_cnt_sess+0x1bf [0x44a82f]
  449da2: /opt/sbin/varnishd'wrk_thread_real+0x882 [0x449da2]
  44a355: /opt/sbin/varnishd'wrk_thread+0x135 [0x44a355]
  fffffd7ff653acf5: /lib/amd64/libc.so.1'_thrp_setup+0x8d [0xfffffd7ff653acf5]
  fffffd7ff653afb0: /lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7ff653afb0]
sp = ee89a8 {
  fd = 17, id = 17, xid = 0,
  client = 217.111.162.2:58987,
  step = STP_FIRST,
  handling = deliver,
  restarts = 0, esis = 0
  ws = ee8a18 {
    id = "sess",
    {s,f,r,e} = {ee9fa0,+20,0,+65536},
  },
  http[req] = {
    ws = ee8a18[sess]
      "",
      "/v/2000/2381/98x74.jpg",
      "HTTP/1.1",
      "Accept: */*",
      "Referer:
http://www.firebox.com/product/2480/LEGO-Mindstorms-NXT-2.0?via=cat",
      "Accept-Language: en-gb",
      "UA-CPU: x86",
      "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;
SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2)",
      "Host: media.firebox.com",
      "Cache-Control: max-stale=0",
      "Connection: Keep-Alive",
      "X-BlueCoat-Via: A1EDA8423E101D0C",
      "X-Forwarded-For: 89.189.78.18, 82.114.160.35",
  },
  worker = fffffd7ff83edd30 {
    ws = fffffd7ff83ede78 {
      id = "wrk",
      {s,f,r,e} = {fffffd7ff83dbc40,fffffd7ff83dbc40,0,+65536},
    },
    },
},


From lloyd at paisite.com  Fri Feb 19 17:53:29 2010
From: lloyd at paisite.com (lloyd at paisite.com)
Date: Fri, 19 Feb 2010 12:53:29 -0500 (EST)
Subject: Varnish installation
Message-ID: <1266602009.734516925@192.168.2.228>

Hello,

I'm new to varnish and perplexed.

As advised by http://varnish-cache.org/wiki/VarnishOnRedhat and http://fedoraproject.org/wiki/EPEL/FAQ#howtouse, I've loaded varnish onto my CentOS server using: 

su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'

su -c 'yum install varnish'

Seems to load OK. But, when I go to /var/lib/varnish I find an empty directory. I find various config directories, but nothing that looks like source code.

The next step is equally perplexing:

You will first need to generate the configure script:

$ ./autogen.sh

Took me awhile to find and download autogen.sh. But where do I put it? Into the empty varnish directory?

Many thanks,

LRP







From perbu at varnish-software.com  Fri Feb 19 18:28:20 2010
From: perbu at varnish-software.com (Per Buer)
Date: Fri, 19 Feb 2010 19:28:20 +0100
Subject: Varnish installation
In-Reply-To: <1266602009.734516925@192.168.2.228>
References: <1266602009.734516925@192.168.2.228>
Message-ID: <52220de01002191028k45e17f68tdb6c48107663970d@mail.gmail.com>

Hi.

On Fri, Feb 19, 2010 at 6:53 PM, <lloyd at paisite.com> wrote:

> Hello,
>
> I'm new to varnish and perplexed.
>
> As advised by http://varnish-cache.org/wiki/VarnishOnRedhat and
> http://fedoraproject.org/wiki/EPEL/FAQ#howtouse, I've loaded varnish onto
> my CentOS server using:
>
> su -c 'rpm -Uvh
> http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
> '
>
> su -c 'yum install varnish'
>
> Seems to load OK. But, when I go to /var/lib/varnish I find an empty
> directory. I find various config directories, but nothing that looks like
> source code.
>

You've installed an RPM. You don't need source code. You probably have
Varnish running fine. I guess your config is in /etc/varnish/default.vcl.
You could edit it according to your needs.




-- 
Per Andreas Buer,  CEO, Varnish Software AS
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: perbu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100219/8742489c/attachment.html>

From frank at vanlingen.name  Sun Feb 21 17:40:19 2010
From: frank at vanlingen.name (Frank van Lingen)
Date: Sun, 21 Feb 2010 18:40:19 +0100
Subject: varnishncsa memory greedy sometimes?
Message-ID: <458a97201002210940o76ca442aj6f53be675f3b4a2e@mail.gmail.com>

I noticed that sometimes the varnishncsa process starts using
excessive amounts of memory. Effectively it allocates all available
(free) memory, It happens approximately once every two weeks (but
sometimes it takes longer for it to happen).
I do not see any unusual increase in traffic when it happens, nor
anything in /var/log/messages.

Is there a known memory leak in varnishncsa or can I limit the amount
of memory varnishncsa allocates for itself?
My current fix is to restart it once it reaches a memory threshold
--------------------------------------------
Frank van Lingen
email : frank at vanlingen.name
VOIP (skype) : fvlingen
IM (yahoo,hotmail) : fvlingen
IM (AIM) : frank at vanlingen.name
URL : http://vanlingen.name
LinkedIn : fvlingen
-------------------------------------------


From wrighty+varnishmisc at gmail.com  Mon Feb 22 18:02:03 2010
From: wrighty+varnishmisc at gmail.com (Paul Wright)
Date: Mon, 22 Feb 2010 18:02:03 +0000
Subject: Child panics on OpenSolaris
In-Reply-To: <282e72051002190945i63a94283s1718f54d79f0f2a7@mail.gmail.com>
References: <282e72051002170852g532cd8acqb570e6db4b82974c@mail.gmail.com>
	<6331.1266432386@critter.freebsd.dk>
	<282e72051002190945i63a94283s1718f54d79f0f2a7@mail.gmail.com>
Message-ID: <282e72051002221002t1ac7be82q6ab8f21c60a21365@mail.gmail.com>

On 19 February 2010 17:45, Paul Wright <wrighty+varnishmisc at gmail.com> wrote:
> On 17 February 2010 18:46, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> In message <282e72051002170852g532cd8acqb570e6db4b82974c at mail.gmail.com>, Paul
>> Wright writes:
>>
>>>(The cookie header ensures the request is passed through to the
>>>backend. Curl will respond with "Failure when receiving data from the
>>>peer".)
>>
>> How on earth did you get the Range header to be passed through to
>> the backend ? ?It should have been filtered out...
>
> I added the following to the top of vcl_recv()
>
> ? ? ? ?if ( req.http.Range ) {
> ? ? ? ? ? ? ? ?unset req.http.Range;
> ? ? ? ?}
>
> Varnish ran happily until tripping over the same bug (#649) as victori
> (on r4573).

For anyone else following along I've now had varnish running for over
5 hours without issue, here are the things I found out:

* add the Range unsetting code to ensure that such requests don't make
it through to the back end
* remove the TCP_Assert() that wraps the setsockopt() call on line 184
of bin/varnishd/cache_acceptor.c
* compile with gcc, not Sun Studio (there's still some sort of
funniness with TCP_(non)blocking() )

CC=/usr/bin/gcc CFLAGS="-O3 -L/lib/amd64 -pthreads -m64
-fomit-frame-pointer" LDFLAGS="-lumem -pthreads" ./configure
--prefix=/opt

* pass the right flags through to gcc when launching vanishd

newtask -p highfile /opt/sbin/varnishd -f /opt/etc/varnish/firebox.vcl -F \
-p 'cc_command=/usr/bin/gcc -fpic -shared -m64 -o %o %s' \
-T 127.0.0.1:9001 \
-s malloc,2G \
-p sess_timeout=5s \
-p max_restarts=12 \
-p waiter=poll \
-p connect_timeout=0s \
-p sess_workspace=65536

* keep checking http://letsgetdugg.com/2009/12/04/varnish-on-solaris/
for hints and suggestions

Many thanks to Poul-Henning Kamp and Victor Igumnov for getting us to
this point.

Cheers,

Paul.


From tami.lee at gmail.com  Wed Feb 24 00:59:21 2010
From: tami.lee at gmail.com (Tami Lee)
Date: Tue, 23 Feb 2010 16:59:21 -0800
Subject: locking SHMFILE in core failed: Cannot allocate memory
Message-ID: <3e3a0c981002231659h2181697bpd8b1ebf97707aa94@mail.gmail.com>

When I start Varnishd, I got the error below. Varnish still seems to work,
but what does the error message mean? More importantly, what may not be
working?

$ /usr/sbin/varnishd -a :4080 -T 127.0.0.1:4082 -f /tmp/varnish/test.vcl -s
file,/tmp/varnish/cache/varnish.cache,128M -n /tmp/varnish/working -P
/tmp/varnish/working/pid

storage_file: filename: /tmp/varnish/cache/varnish.cache size 128 MB.
Using old SHMFILE
Notice: locking SHMFILE in core failed: Cannot allocate memory

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100223/88ebd6a4/attachment.html>

From phk at phk.freebsd.dk  Wed Feb 24 17:10:42 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 24 Feb 2010 17:10:42 +0000
Subject: locking SHMFILE in core failed: Cannot allocate memory 
In-Reply-To: Your message of "Tue, 23 Feb 2010 16:59:21 PST."
	<3e3a0c981002231659h2181697bpd8b1ebf97707aa94@mail.gmail.com> 
Message-ID: <91959.1267031442@critter.freebsd.dk>

In message <3e3a0c981002231659h2181697bpd8b1ebf97707aa94 at mail.gmail.com>, Tami 
Lee writes:

>When I start Varnishd, I got the error below. Varnish still seems to work,
>but what does the error message mean? More importantly, what may not be
>working?

>Notice: locking SHMFILE in core failed: Cannot allocate memory

Don't worry about it, it's just noise.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From phk at phk.freebsd.dk  Wed Feb 24 18:37:45 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 24 Feb 2010 18:37:45 +0000
Subject: Varnish CLI user feedback, please.
Message-ID: <15046.1267036665@critter.freebsd.dk>


I'm looking at the CLI/varnishadm stuff right now, and would like some
feedback from you guys...

Right now (in -trunk) we have these possible CLI configurations:

	A)  no CLI at all.

	B)  CLI on stdin (-d)

	C)  CLI on TELNET (-T)

	D)  CLI on "call-back" (-M)

If the -S option is given, -T/-M CLI connections will require
challenge/response authentication.

(Before 2.1, I plan to add -S support to varnishadm, and maybe some
API functions to access the CLI in libvarnishapi.)

Which of these modes do you actually use ?

Are more modes needed ?

Any other insights on the CLI interface ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


From john at 7fff.com  Wed Feb 24 19:37:17 2010
From: john at 7fff.com (John Norman)
Date: Wed, 24 Feb 2010 14:37:17 -0500
Subject: health check path doesn't change after VCL reload (2.0.6)
Message-ID: <b6b8b6b71002241137j71ae210r35487c328e8f69d1@mail.gmail.com>

Hi.

We notice that after VCL is reloaded, our old health check path is still
getting checked.

The only thing that seems to fix it is a varnish restart.

Seems like I should log this as a bug . . . ?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100224/480f9aa6/attachment.html>

From phk at phk.freebsd.dk  Wed Feb 24 20:24:31 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 24 Feb 2010 20:24:31 +0000
Subject: health check path doesn't change after VCL reload (2.0.6) 
In-Reply-To: Your message of "Wed, 24 Feb 2010 14:37:17 EST."
	<b6b8b6b71002241137j71ae210r35487c328e8f69d1@mail.gmail.com> 
Message-ID: <15457.1267043071@critter.freebsd.dk>

In message <b6b8b6b71002241137j71ae210r35487c328e8f69d1 at mail.gmail.com>, John N
orman writes:

>We notice that after VCL is reloaded, our old health check path is still
>getting checked.
>
>The only thing that seems to fix it is a varnish restart.

No, unloading the old VCL code should also do it.

We keep polling the backends of all loaded VCL, so they are all
ready to roll the moment you do "vcl.use mumble".


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From jhayter at manta.com  Wed Feb 24 20:25:58 2010
From: jhayter at manta.com (Jim Hayter)
Date: Wed, 24 Feb 2010 15:25:58 -0500
Subject: health check path doesn't change after VCL reload (2.0.6)
In-Reply-To: <b6b8b6b71002241137j71ae210r35487c328e8f69d1@mail.gmail.com>
References: <b6b8b6b71002241137j71ae210r35487c328e8f69d1@mail.gmail.com>
Message-ID: <D26F7E3F42600549A27A4433EB952E8404230973@sbs03.ecnext03.local>

I remember seeing a post recently that mentioned that the old health
checks are still performed as long as the old VCL is loaded.  This is
done to allow a quick switch back to the previous VCL.  This seems
likely from behavior I have seen.

Jim

-----Original Message-----
From: varnish-misc-bounces at projects.linpro.no
[mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of John
Norman
Sent: Wednesday, February 24, 2010 2:37 PM
Cc: varnish-misc at projects.linpro.no
Subject: health check path doesn't change after VCL reload (2.0.6)

Hi.

We notice that after VCL is reloaded, our old health check path is still
getting checked.

The only thing that seems to fix it is a varnish restart.

Seems like I should log this as a bug . . . ?

John




From john at 7fff.com  Wed Feb 24 21:15:39 2010
From: john at 7fff.com (John Norman)
Date: Wed, 24 Feb 2010 16:15:39 -0500
Subject: health check path doesn't change after VCL reload (2.0.6)
In-Reply-To: <15457.1267043071@critter.freebsd.dk>
References: <b6b8b6b71002241137j71ae210r35487c328e8f69d1@mail.gmail.com>
	<15457.1267043071@critter.freebsd.dk>
Message-ID: <b6b8b6b71002241315w1c62022t1bf941d6f2cac0c7@mail.gmail.com>

That's great.

Still, the VCL indicated as "active" had a different path for the health
check.

On Wed, Feb 24, 2010 at 3:24 PM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <b6b8b6b71002241137j71ae210r35487c328e8f69d1 at mail.gmail.com>,
> John N
> orman writes:
>
> >We notice that after VCL is reloaded, our old health check path is still
> >getting checked.
> >
> >The only thing that seems to fix it is a varnish restart.
>
> No, unloading the old VCL code should also do it.
>
> We keep polling the backends of all loaded VCL, so they are all
> ready to roll the moment you do "vcl.use mumble".
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100224/e10fed62/attachment.html>

From phk at phk.freebsd.dk  Wed Feb 24 21:18:07 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 24 Feb 2010 21:18:07 +0000
Subject: health check path doesn't change after VCL reload (2.0.6) 
In-Reply-To: Your message of "Wed, 24 Feb 2010 16:15:39 EST."
	<b6b8b6b71002241315w1c62022t1bf941d6f2cac0c7@mail.gmail.com> 
Message-ID: <15628.1267046287@critter.freebsd.dk>

In message <b6b8b6b71002241315w1c62022t1bf941d6f2cac0c7 at mail.gmail.com>, John N
orman writes:

>Still, the VCL indicated as "active" had a different path for the health
>check.

Hopefully both got probed ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From john at 7fff.com  Wed Feb 24 21:21:19 2010
From: john at 7fff.com (John Norman)
Date: Wed, 24 Feb 2010 16:21:19 -0500
Subject: host header altered by Varnish?
Message-ID: <b6b8b6b71002241321x4d1ed463w3f066a16b3e8ca8a@mail.gmail.com>

Sorry about all the questions . . .

On my backend I want to redirect domain.com to www.domain.com

I see Host: domain.com in both the RX and TX sections of the log . . . but
the redirect isn't getting triggered.

The backend is Apache, and the redirect directives are routine.

  RewriteCond %{HTTP_HOST} ^domain.com$ [NC]
  RewriteRule ^(.*)$ http://www.domain.com$1 [R=301,L]

Am I missing something?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100224/16c863cc/attachment.html>

From john at 7fff.com  Wed Feb 24 21:25:41 2010
From: john at 7fff.com (John Norman)
Date: Wed, 24 Feb 2010 16:25:41 -0500
Subject: health check path doesn't change after VCL reload (2.0.6)
In-Reply-To: <15628.1267046287@critter.freebsd.dk>
References: <b6b8b6b71002241315w1c62022t1bf941d6f2cac0c7@mail.gmail.com>
	<15628.1267046287@critter.freebsd.dk>
Message-ID: <b6b8b6b71002241325s21a939f3t1cdb88c675317580@mail.gmail.com>

No, only the former / old path.

I'm not super-troubled right now because a Varnish restart did pick up the
new path (but at the cost of my cache) -- but I'm a bit worried about the
next time I have to change it.

I will be changing the probe interval soon, so that will give me a chance to
reproduce the problem, if it even exists.

As a bit of background:

I automate the VCL update to multiple servers, when/if the VCL file has
changed.

Before the update, I also remove all of the inactive/old VCL's that are
sitting there.

Then I add the new one and "use" it.

When I observed in my backend logs the probes going to the old URLs, I did
check the "active" VCL on all systems, and they all showed the new path.

In any case, I will try to reproduce and will send the results.

One last thing: During the restart on one system, I observed the issue
reported here:
http://zarathustrashallspeak.com/2009/11/28/varnish-startup-issue/

John

On Wed, Feb 24, 2010 at 4:18 PM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <b6b8b6b71002241315w1c62022t1bf941d6f2cac0c7 at mail.gmail.com>,
> John N
> orman writes:
>
> >Still, the VCL indicated as "active" had a different path for the health
> >check.
>
> Hopefully both got probed ?
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100224/cb7b65ca/attachment.html>

From perbu at varnish-software.com  Wed Feb 24 21:36:32 2010
From: perbu at varnish-software.com (Per Buer)
Date: Wed, 24 Feb 2010 22:36:32 +0100
Subject: Varnish CLI user feedback, please.
In-Reply-To: <15046.1267036665@critter.freebsd.dk>
References: <15046.1267036665@critter.freebsd.dk>
Message-ID: <52220de01002241336u35fdc0fdo6c309aa5a678d695@mail.gmail.com>

On Wed, Feb 24, 2010 at 7:37 PM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

>
> I'm looking at the CLI/varnishadm stuff right now, and would like some
> feedback from you guys...
>
> Right now (in -trunk) we have these possible CLI configurations:
>
>        A)  no CLI at all.
>

Probably useful for a lot of simple uses. Some CMS might ship Varnish as
part of it and there won't a need for CLI.


>        B)  CLI on stdin (-d)
>
>        C)  CLI on TELNET (-T)
>
>        D)  CLI on "call-back" (-M)
>

I really like this one. If we could have an option to let Varnish start
without the cache running (like -d) one could picture some sort of service
accepting connections from newly started varnishd servers. The service would
then configure the caches, provision them with VCL and start them up. The
need for messing around with having shell and config files on the
caches disappears.



-- 
Per Andreas Buer,  CEO, Varnish Software AS
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100224/3e41e5be/attachment.html>

From bert-jan at bugbyte.nl  Wed Feb 24 22:33:34 2010
From: bert-jan at bugbyte.nl (Bert-Jan de Lange)
Date: Wed, 24 Feb 2010 23:33:34 +0100
Subject: host header altered by Varnish?
In-Reply-To: <b6b8b6b71002241321x4d1ed463w3f066a16b3e8ca8a@mail.gmail.com>
References: <b6b8b6b71002241321x4d1ed463w3f066a16b3e8ca8a@mail.gmail.com>
Message-ID: <4B85A93E.3020509@bugbyte.nl>

I have the same stuff on my backends and what you have here should work.
The only thing I can think of from your example is a missing 
'RewriteEngine on' on top. If I don't have that the rewriting is 
silently ignored by apache.


On 24-Feb-2010 22:21, John Norman wrote:
> Sorry about all the questions . . .
>
> On my backend I want to redirect domain.com <http://domain.com> to 
> www.domain.com <http://www.domain.com>
>
> I see Host: domain.com <http://domain.com> in both the RX and TX 
> sections of the log . . . but the redirect isn't getting triggered.
>
> The backend is Apache, and the redirect directives are routine.
>
>   RewriteCond %{HTTP_HOST} ^domain.com <http://domain.com>$ [NC]
>   RewriteRule ^(.*)$ http://www.domain.com$1 [R=301,L]
>
> Am I missing something?
>
> John
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100224/44054dde/attachment.html>

From barry at automattic.com  Thu Feb 25 04:15:17 2010
From: barry at automattic.com (Barry Abrahamson)
Date: Wed, 24 Feb 2010 22:15:17 -0600
Subject: Varnish 2.0.6 nuking all my objects?
Message-ID: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com>

Howdy,

We are finally getting around to upgrading to the latest version of varnish and are running into quite a weird problem.  Everything works fine for a bit (1+day) , then all of a sudden Varnish starts nuking all of the objects from the cache:

About 4 hours ago there were 1 million objects in the cache, now there are just about 172k.  This looks a bit weird to me:

sms_nbytes       18446744073709548694          .   SMS outstanding bytes

Here are the options I am passing to varnishd:

/usr/local/sbin/varnishd -a 0.0.0.0:8888 -f /etc/varnish/varnish.vcl -P /var/run/varnishd.pid -T 0.0.0.0:47200 -t 600 -w 1,200,300 -p thread_pools 4 -p thread_pool_add_delay 2 -p lru_interval 60 -h classic,500009 -p obj_workspace 4096 -s file,/varnish/cache,150G

/varnish is 2 x 80GB Intel X-25M SSDs in a software RAID 0 array.  OS is Debian Lenny 64-bit.  There is plenty of space:

/dev/md0              149G   52G   98G  35% /varnish

Here is the output of varnishstat -1

uptime                 134971          .   Child uptime
client_conn          12051037        89.29 Client connections accepted
client_drop                 0         0.00 Connection dropped, no sess
client_req           12048672        89.27 Client requests received
cache_hit            10161272        75.28 Cache hits
cache_hitpass          133244         0.99 Cache hits for pass
cache_miss            1750857        12.97 Cache misses
backend_conn          1824594        13.52 Backend conn. success
backend_unhealthy            0         0.00 Backend conn. not attempted
backend_busy                0         0.00 Backend conn. too many
backend_fail             3644         0.03 Backend conn. failures
backend_reuse               0         0.00 Backend conn. reuses
backend_toolate             0         0.00 Backend conn. was closed
backend_recycle             0         0.00 Backend conn. recycles
backend_unused              0         0.00 Backend conn. unused
fetch_head               5309         0.04 Fetch head
fetch_length          1816422        13.46 Fetch with Length
fetch_chunked               0         0.00 Fetch chunked
fetch_eof                   0         0.00 Fetch EOF
fetch_bad                   0         0.00 Fetch had bad headers
fetch_close                 0         0.00 Fetch wanted close
fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
fetch_zero                  0         0.00 Fetch zero len
fetch_failed               16         0.00 Fetch failed
n_srcaddr                   0          .   N struct srcaddr
n_srcaddr_act               0          .   N active struct srcaddr
n_sess_mem                578          .   N struct sess_mem
n_sess                    414          .   N struct sess
n_object               172697          .   N struct object
n_objecthead           173170          .   N struct objecthead
n_smf                  471310          .   N struct smf
n_smf_frag              62172          .   N small free smf
n_smf_large             67978          .   N large free smf
n_vbe_conn       18446744073709551611          .   N struct vbe_conn
n_bereq                   315          .   N struct bereq
n_wrk                      76          .   N worker threads
n_wrk_create             3039         0.02 N worker threads created
n_wrk_failed                0         0.00 N worker threads not created
n_wrk_max                   0         0.00 N worker threads limited
n_wrk_queue                 0         0.00 N queued work requests
n_wrk_overflow          25136         0.19 N overflowed work requests
n_wrk_drop                  0         0.00 N dropped work requests
n_backend                   4          .   N backends
n_expired              771687          .   N expired objects
n_lru_nuked            744693          .   N LRU nuked objects
n_lru_saved                 0          .   N LRU saved objects
n_lru_moved           8675178          .   N LRU moved objects
n_deathrow                  0          .   N objects on deathrow
losthdr                    25         0.00 HTTP header overflows
n_objsendfile               0         0.00 Objects sent with sendfile
n_objwrite           11749415        87.05 Objects sent with write
n_objoverflow               0         0.00 Objects overflowing workspace
s_sess               12051007        89.29 Total Sessions
s_req                12050184        89.28 Total Requests
s_pipe                   2661         0.02 Total pipe
s_pass                 134858         1.00 Total pass
s_fetch               1821721        13.50 Total fetch
s_hdrbytes         3932274894     29134.22 Total header bytes
s_bodybytes      894452020319   6626994.10 Total body bytes
sess_closed          12050925        89.29 Session Closed
sess_pipeline               0         0.00 Session Pipeline
sess_readahead              0         0.00 Session Read Ahead
sess_linger                 0         0.00 Session Linger
sess_herd                 160         0.00 Session herd
shm_records         610011852      4519.58 SHM records
shm_writes           50380066       373.27 SHM writes
shm_flushes              9387         0.07 SHM flushes due to overflow
shm_cont                47763         0.35 SHM MTX contention
shm_cycles                226         0.00 SHM cycles through buffer
sm_nreq               4449213        32.96 allocator requests
sm_nobj                341160          .   outstanding allocations
sm_balloc         11373072384          .   bytes allocated
sm_bfree         116602589184          .   bytes free
sma_nreq                    0         0.00 SMA allocator requests
sma_nobj                    0          .   SMA outstanding allocations
sma_nbytes                  0          .   SMA outstanding bytes
sma_balloc                  0          .   SMA bytes allocated
sma_bfree                   0          .   SMA bytes free
sms_nreq                63997         0.47 SMS allocator requests
sms_nobj                    0          .   SMS outstanding allocations
sms_nbytes       18446744073709548694          .   SMS outstanding bytes
sms_balloc           31161028          .   SMS bytes allocated
sms_bfree            31162489          .   SMS bytes freed
backend_req           1821961        13.50 Backend requests made
n_vcl                       1         0.00 N vcl total
n_vcl_avail                 1         0.00 N vcl available
n_vcl_discard               0         0.00 N vcl discarded
n_purge                     1          .   N total active purges
n_purge_add                 1         0.00 N new purges added
n_purge_retire              0         0.00 N old purges deleted
n_purge_obj_test            0         0.00 N objects tested
n_purge_re_test             0         0.00 N regexps tested against
n_purge_dups                0         0.00 N duplicate purges removed
hcb_nolock                  0         0.00 HCB Lookups without lock
hcb_lock                    0         0.00 HCB Lookups with lock
hcb_insert                  0         0.00 HCB Inserts
esi_parse                   0         0.00 Objects ESI parsed (unlock)
esi_errors                  0         0.00 ESI parse errors (unlock)

Obviously, this isn't good for my cache hit rate :)  It is also using a lot of CPU.  Has anyone seen this happen before?

--
Barry Abrahamson | Systems Wrangler | Automattic
Blog: http://barry.wordpress.com





From david.birdsong at gmail.com  Thu Feb 25 08:26:12 2010
From: david.birdsong at gmail.com (David Birdsong)
Date: Thu, 25 Feb 2010 00:26:12 -0800
Subject: Varnish 2.0.6 nuking all my objects?
In-Reply-To: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com>
References: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com>
Message-ID: <dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com>

I have seen this happen.

I have a similar hardware setup, though I changed the multi-ssd raid
into 3 separate cache file arguments.

We had roughly 240GB storage space total, after about 2-3 weeks and
sm_bfree reached ~20GB. lru_nuked started incrementing, sm_bfree
climbed to ~60GB, but lru_nuking never stopped.

On Wed, Feb 24, 2010 at 8:15 PM, Barry Abrahamson <barry at automattic.com> wrote:
> Howdy,
>
> We are finally getting around to upgrading to the latest version of varnish and are running into quite a weird problem. ?Everything works fine for a bit (1+day) , then all of a sudden Varnish starts nuking all of the objects from the cache:
>
> About 4 hours ago there were 1 million objects in the cache, now there are just about 172k. ?This looks a bit weird to me:
>
> sms_nbytes ? ? ? 18446744073709548694 ? ? ? ? ?. ? SMS outstanding bytes
>
> Here are the options I am passing to varnishd:
>
> /usr/local/sbin/varnishd -a 0.0.0.0:8888 -f /etc/varnish/varnish.vcl -P /var/run/varnishd.pid -T 0.0.0.0:47200 -t 600 -w 1,200,300 -p thread_pools 4 -p thread_pool_add_delay 2 -p lru_interval 60 -h classic,500009 -p obj_workspace 4096 -s file,/varnish/cache,150G
>
> /varnish is 2 x 80GB Intel X-25M SSDs in a software RAID 0 array. ?OS is Debian Lenny 64-bit. ?There is plenty of space:
>
> /dev/md0 ? ? ? ? ? ? ?149G ? 52G ? 98G ?35% /varnish
>
> Here is the output of varnishstat -1
>
> uptime ? ? ? ? ? ? ? ? 134971 ? ? ? ? ?. ? Child uptime
> client_conn ? ? ? ? ?12051037 ? ? ? ?89.29 Client connections accepted
> client_drop ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Connection dropped, no sess
> client_req ? ? ? ? ? 12048672 ? ? ? ?89.27 Client requests received
> cache_hit ? ? ? ? ? ?10161272 ? ? ? ?75.28 Cache hits
> cache_hitpass ? ? ? ? ?133244 ? ? ? ? 0.99 Cache hits for pass
> cache_miss ? ? ? ? ? ?1750857 ? ? ? ?12.97 Cache misses
> backend_conn ? ? ? ? ?1824594 ? ? ? ?13.52 Backend conn. success
> backend_unhealthy ? ? ? ? ? ?0 ? ? ? ? 0.00 Backend conn. not attempted
> backend_busy ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 Backend conn. too many
> backend_fail ? ? ? ? ? ? 3644 ? ? ? ? 0.03 Backend conn. failures
> backend_reuse ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Backend conn. reuses
> backend_toolate ? ? ? ? ? ? 0 ? ? ? ? 0.00 Backend conn. was closed
> backend_recycle ? ? ? ? ? ? 0 ? ? ? ? 0.00 Backend conn. recycles
> backend_unused ? ? ? ? ? ? ?0 ? ? ? ? 0.00 Backend conn. unused
> fetch_head ? ? ? ? ? ? ? 5309 ? ? ? ? 0.04 Fetch head
> fetch_length ? ? ? ? ?1816422 ? ? ? ?13.46 Fetch with Length
> fetch_chunked ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Fetch chunked
> fetch_eof ? ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Fetch EOF
> fetch_bad ? ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Fetch had bad headers
> fetch_close ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Fetch wanted close
> fetch_oldhttp ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Fetch pre HTTP/1.1 closed
> fetch_zero ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 Fetch zero len
> fetch_failed ? ? ? ? ? ? ? 16 ? ? ? ? 0.00 Fetch failed
> n_srcaddr ? ? ? ? ? ? ? ? ? 0 ? ? ? ? ?. ? N struct srcaddr
> n_srcaddr_act ? ? ? ? ? ? ? 0 ? ? ? ? ?. ? N active struct srcaddr
> n_sess_mem ? ? ? ? ? ? ? ?578 ? ? ? ? ?. ? N struct sess_mem
> n_sess ? ? ? ? ? ? ? ? ? ?414 ? ? ? ? ?. ? N struct sess
> n_object ? ? ? ? ? ? ? 172697 ? ? ? ? ?. ? N struct object
> n_objecthead ? ? ? ? ? 173170 ? ? ? ? ?. ? N struct objecthead
> n_smf ? ? ? ? ? ? ? ? ?471310 ? ? ? ? ?. ? N struct smf
> n_smf_frag ? ? ? ? ? ? ?62172 ? ? ? ? ?. ? N small free smf
> n_smf_large ? ? ? ? ? ? 67978 ? ? ? ? ?. ? N large free smf
> n_vbe_conn ? ? ? 18446744073709551611 ? ? ? ? ?. ? N struct vbe_conn
> n_bereq ? ? ? ? ? ? ? ? ? 315 ? ? ? ? ?. ? N struct bereq
> n_wrk ? ? ? ? ? ? ? ? ? ? ?76 ? ? ? ? ?. ? N worker threads
> n_wrk_create ? ? ? ? ? ? 3039 ? ? ? ? 0.02 N worker threads created
> n_wrk_failed ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 N worker threads not created
> n_wrk_max ? ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 N worker threads limited
> n_wrk_queue ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 N queued work requests
> n_wrk_overflow ? ? ? ? ?25136 ? ? ? ? 0.19 N overflowed work requests
> n_wrk_drop ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 N dropped work requests
> n_backend ? ? ? ? ? ? ? ? ? 4 ? ? ? ? ?. ? N backends
> n_expired ? ? ? ? ? ? ?771687 ? ? ? ? ?. ? N expired objects
> n_lru_nuked ? ? ? ? ? ?744693 ? ? ? ? ?. ? N LRU nuked objects
> n_lru_saved ? ? ? ? ? ? ? ? 0 ? ? ? ? ?. ? N LRU saved objects
> n_lru_moved ? ? ? ? ? 8675178 ? ? ? ? ?. ? N LRU moved objects
> n_deathrow ? ? ? ? ? ? ? ? ?0 ? ? ? ? ?. ? N objects on deathrow
> losthdr ? ? ? ? ? ? ? ? ? ?25 ? ? ? ? 0.00 HTTP header overflows
> n_objsendfile ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Objects sent with sendfile
> n_objwrite ? ? ? ? ? 11749415 ? ? ? ?87.05 Objects sent with write
> n_objoverflow ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Objects overflowing workspace
> s_sess ? ? ? ? ? ? ? 12051007 ? ? ? ?89.29 Total Sessions
> s_req ? ? ? ? ? ? ? ?12050184 ? ? ? ?89.28 Total Requests
> s_pipe ? ? ? ? ? ? ? ? ? 2661 ? ? ? ? 0.02 Total pipe
> s_pass ? ? ? ? ? ? ? ? 134858 ? ? ? ? 1.00 Total pass
> s_fetch ? ? ? ? ? ? ? 1821721 ? ? ? ?13.50 Total fetch
> s_hdrbytes ? ? ? ? 3932274894 ? ? 29134.22 Total header bytes
> s_bodybytes ? ? ?894452020319 ? 6626994.10 Total body bytes
> sess_closed ? ? ? ? ?12050925 ? ? ? ?89.29 Session Closed
> sess_pipeline ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Session Pipeline
> sess_readahead ? ? ? ? ? ? ?0 ? ? ? ? 0.00 Session Read Ahead
> sess_linger ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Session Linger
> sess_herd ? ? ? ? ? ? ? ? 160 ? ? ? ? 0.00 Session herd
> shm_records ? ? ? ? 610011852 ? ? ?4519.58 SHM records
> shm_writes ? ? ? ? ? 50380066 ? ? ? 373.27 SHM writes
> shm_flushes ? ? ? ? ? ? ?9387 ? ? ? ? 0.07 SHM flushes due to overflow
> shm_cont ? ? ? ? ? ? ? ?47763 ? ? ? ? 0.35 SHM MTX contention
> shm_cycles ? ? ? ? ? ? ? ?226 ? ? ? ? 0.00 SHM cycles through buffer
> sm_nreq ? ? ? ? ? ? ? 4449213 ? ? ? ?32.96 allocator requests
> sm_nobj ? ? ? ? ? ? ? ?341160 ? ? ? ? ?. ? outstanding allocations
> sm_balloc ? ? ? ? 11373072384 ? ? ? ? ?. ? bytes allocated
> sm_bfree ? ? ? ? 116602589184 ? ? ? ? ?. ? bytes free
> sma_nreq ? ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 SMA allocator requests
> sma_nobj ? ? ? ? ? ? ? ? ? ?0 ? ? ? ? ?. ? SMA outstanding allocations
> sma_nbytes ? ? ? ? ? ? ? ? ?0 ? ? ? ? ?. ? SMA outstanding bytes
> sma_balloc ? ? ? ? ? ? ? ? ?0 ? ? ? ? ?. ? SMA bytes allocated
> sma_bfree ? ? ? ? ? ? ? ? ? 0 ? ? ? ? ?. ? SMA bytes free
> sms_nreq ? ? ? ? ? ? ? ?63997 ? ? ? ? 0.47 SMS allocator requests
> sms_nobj ? ? ? ? ? ? ? ? ? ?0 ? ? ? ? ?. ? SMS outstanding allocations
> sms_nbytes ? ? ? 18446744073709548694 ? ? ? ? ?. ? SMS outstanding bytes
> sms_balloc ? ? ? ? ? 31161028 ? ? ? ? ?. ? SMS bytes allocated
> sms_bfree ? ? ? ? ? ?31162489 ? ? ? ? ?. ? SMS bytes freed
> backend_req ? ? ? ? ? 1821961 ? ? ? ?13.50 Backend requests made
> n_vcl ? ? ? ? ? ? ? ? ? ? ? 1 ? ? ? ? 0.00 N vcl total
> n_vcl_avail ? ? ? ? ? ? ? ? 1 ? ? ? ? 0.00 N vcl available
> n_vcl_discard ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 N vcl discarded
> n_purge ? ? ? ? ? ? ? ? ? ? 1 ? ? ? ? ?. ? N total active purges
> n_purge_add ? ? ? ? ? ? ? ? 1 ? ? ? ? 0.00 N new purges added
> n_purge_retire ? ? ? ? ? ? ?0 ? ? ? ? 0.00 N old purges deleted
> n_purge_obj_test ? ? ? ? ? ?0 ? ? ? ? 0.00 N objects tested
> n_purge_re_test ? ? ? ? ? ? 0 ? ? ? ? 0.00 N regexps tested against
> n_purge_dups ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 N duplicate purges removed
> hcb_nolock ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 HCB Lookups without lock
> hcb_lock ? ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 HCB Lookups with lock
> hcb_insert ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 HCB Inserts
> esi_parse ? ? ? ? ? ? ? ? ? 0 ? ? ? ? 0.00 Objects ESI parsed (unlock)
> esi_errors ? ? ? ? ? ? ? ? ?0 ? ? ? ? 0.00 ESI parse errors (unlock)
>
> Obviously, this isn't good for my cache hit rate :) ?It is also using a lot of CPU. ?Has anyone seen this happen before?
>
> --
> Barry Abrahamson | Systems Wrangler | Automattic
> Blog: http://barry.wordpress.com
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From phk at phk.freebsd.dk  Thu Feb 25 09:54:47 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 25 Feb 2010 09:54:47 +0000
Subject: Varnish 2.0.6 nuking all my objects? 
In-Reply-To: Your message of "Thu, 25 Feb 2010 00:26:12 PST."
	<dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com> 
Message-ID: <30598.1267091687@critter.freebsd.dk>

In message <dcccdf791002250026t20b8e787x98fa3535267b3129 at mail.gmail.com>, David
 Birdsong writes:

>We had roughly 240GB storage space total, after about 2-3 weeks and
>sm_bfree reached ~20GB. lru_nuked started incrementing, sm_bfree
>climbed to ~60GB, but lru_nuking never stopped.

We had a bug where we would nuke from one stevedore, but try to allocate
from another.  Not sure if the fix made it into any of the 2.0 releases,
it will be in 2.1

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From perbu at varnish-software.com  Thu Feb 25 13:54:40 2010
From: perbu at varnish-software.com (Per Buer)
Date: Thu, 25 Feb 2010 14:54:40 +0100
Subject: varnish-cache.org is moving
Message-ID: <52220de01002250554s434042cdw427c7085b9d5c4a6@mail.gmail.com>

Hi.

We'll be moving varnish-cache.org on monday march the first around 11:00
CET.  The site will be unavailable for about 5 minutes while we move it.

We'll be getting a newer trac version but other than that there should be no
user-noticable changes. At some point we will also move the mailing lists
away from projects.linpro.no and onto varnish-cache.org. More on this when
we have a date.

Please let me know if you experience any problems.


-- 
Per Andreas Buer,  CEO, Varnish Software AS
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100225/b5be9352/attachment.html>

From barry at automattic.com  Thu Feb 25 16:41:58 2010
From: barry at automattic.com (Barry Abrahamson)
Date: Thu, 25 Feb 2010 10:41:58 -0600
Subject: Varnish 2.0.6 nuking all my objects?
In-Reply-To: <dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com>
References: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com>
	<dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com>
Message-ID: <78868A1D-99A9-4484-8E0E-4084DF9AD5F3@automattic.com>


On Feb 25, 2010, at 2:26 AM, David Birdsong wrote:

> I have seen this happen.
> 
> I have a similar hardware setup, though I changed the multi-ssd raid
> into 3 separate cache file arguments.

Did you try RAID and switch to the separate cache files because performance was better?

> We had roughly 240GB storage space total, after about 2-3 weeks and
> sm_bfree reached ~20GB. lru_nuked started incrementing, sm_bfree
> climbed to ~60GB, but lru_nuking never stopped.

How did you fix it?


--
Barry Abrahamson | Systems Wrangler | Automattic
Blog: http://barry.wordpress.com





From barry at automattic.com  Thu Feb 25 16:42:49 2010
From: barry at automattic.com (Barry Abrahamson)
Date: Thu, 25 Feb 2010 10:42:49 -0600
Subject: Varnish 2.0.6 nuking all my objects? 
In-Reply-To: <30598.1267091687@critter.freebsd.dk>
References: <30598.1267091687@critter.freebsd.dk>
Message-ID: <321D60D0-50EF-4B28-A633-1D02E478E150@automattic.com>


On Feb 25, 2010, at 3:54 AM, Poul-Henning Kamp wrote:

> In message <dcccdf791002250026t20b8e787x98fa3535267b3129 at mail.gmail.com>, David
> Birdsong writes:
> 
>> We had roughly 240GB storage space total, after about 2-3 weeks and
>> sm_bfree reached ~20GB. lru_nuked started incrementing, sm_bfree
>> climbed to ~60GB, but lru_nuking never stopped.
> 
> We had a bug where we would nuke from one stevedore, but try to allocate
> from another.  Not sure if the fix made it into any of the 2.0 releases,
> it will be in 2.1

Thanks for the info - are the fixes in -trunk now?

--
Barry Abrahamson | Systems Wrangler | Automattic
Blog: http://barry.wordpress.com





From david.birdsong at gmail.com  Thu Feb 25 18:47:30 2010
From: david.birdsong at gmail.com (David Birdsong)
Date: Thu, 25 Feb 2010 10:47:30 -0800
Subject: Varnish 2.0.6 nuking all my objects?
In-Reply-To: <78868A1D-99A9-4484-8E0E-4084DF9AD5F3@automattic.com>
References: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com> 
	<dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com> 
	<78868A1D-99A9-4484-8E0E-4084DF9AD5F3@automattic.com>
Message-ID: <dcccdf791002251047g3e3e3b4dkc69672483cb86022@mail.gmail.com>

On Thu, Feb 25, 2010 at 8:41 AM, Barry Abrahamson <barry at automattic.com> wrote:
>
> On Feb 25, 2010, at 2:26 AM, David Birdsong wrote:
>
>> I have seen this happen.
>>
>> I have a similar hardware setup, though I changed the multi-ssd raid
>> into 3 separate cache file arguments.
>
> Did you try RAID and switch to the separate cache files because performance was better?
seemingly so.

for some reason enabling block_dump showed that kswapd was always
writing to those devices despite their not being any swap space on
them.

i searched around fruitlessly to try to understand the overhead of
software raid to explain this, but once i discovered varnish could
take on multiple cache files, i saw no reason for the software raid
and just abandoned it.

>
>> We had roughly 240GB storage space total, after about 2-3 weeks and
>> sm_bfree reached ~20GB. lru_nuked started incrementing, sm_bfree
>> climbed to ~60GB, but lru_nuking never stopped.
>
> How did you fix it?
i haven't yet.

i'm changing up how i cache content, such that lru_nuking can be
better tolerated.

>
>
> --
> Barry Abrahamson | Systems Wrangler | Automattic
> Blog: http://barry.wordpress.com
>
>
>
>


From barry at automattic.com  Thu Feb 25 20:56:50 2010
From: barry at automattic.com (Barry Abrahamson)
Date: Thu, 25 Feb 2010 14:56:50 -0600
Subject: Varnish 2.0.6 nuking all my objects?
In-Reply-To: <dcccdf791002251047g3e3e3b4dkc69672483cb86022@mail.gmail.com>
References: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com>
	<dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com>
	<78868A1D-99A9-4484-8E0E-4084DF9AD5F3@automattic.com>
	<dcccdf791002251047g3e3e3b4dkc69672483cb86022@mail.gmail.com>
Message-ID: <20F50669-F9A5-4782-BCF2-6CF7F4D8F92E@automattic.com>


On Feb 25, 2010, at 12:47 PM, David Birdsong wrote:

> On Thu, Feb 25, 2010 at 8:41 AM, Barry Abrahamson <barry at automattic.com> wrote:
>> 
>> On Feb 25, 2010, at 2:26 AM, David Birdsong wrote:
>> 
>>> I have seen this happen.
>>> 
>>> I have a similar hardware setup, though I changed the multi-ssd raid
>>> into 3 separate cache file arguments.
>> 
>> Did you try RAID and switch to the separate cache files because performance was better?
> seemingly so.
> 
> for some reason enabling block_dump showed that kswapd was always
> writing to those devices despite their not being any swap space on
> them.
> 
> i searched around fruitlessly to try to understand the overhead of
> software raid to explain this, but once i discovered varnish could
> take on multiple cache files, i saw no reason for the software raid
> and just abandoned it.

Interesting - I will try it out!  Thanks for the info.


>>> We had roughly 240GB storage space total, after about 2-3 weeks and
>>> sm_bfree reached ~20GB. lru_nuked started incrementing, sm_bfree
>>> climbed to ~60GB, but lru_nuking never stopped.
>> 
>> How did you fix it?
> i haven't yet.
> 
> i'm changing up how i cache content, such that lru_nuking can be
> better tolerated.

In my case, Varnish took a cache of 1 million objects, purged 920k of them.  When there were 80k objects left the child restarted, thus dumping the remaining 80k :)  


--
Barry Abrahamson | Systems Wrangler | Automattic
Blog: http://barry.wordpress.com





From barry at automattic.com  Fri Feb 26 03:58:21 2010
From: barry at automattic.com (Barry Abrahamson)
Date: Thu, 25 Feb 2010 21:58:21 -0600
Subject: Varnish 2.0.6 nuking all my objects?
In-Reply-To: <20F50669-F9A5-4782-BCF2-6CF7F4D8F92E@automattic.com>
References: <DBDED89E-9677-40D7-9026-92E90B17862A@automattic.com>
	<dcccdf791002250026t20b8e787x98fa3535267b3129@mail.gmail.com>
	<78868A1D-99A9-4484-8E0E-4084DF9AD5F3@automattic.com>
	<dcccdf791002251047g3e3e3b4dkc69672483cb86022@mail.gmail.com>
	<20F50669-F9A5-4782-BCF2-6CF7F4D8F92E@automattic.com>
Message-ID: <ACFC1676-9F5D-457F-A41B-1CC3F0B2DF5B@automattic.com>


On Feb 25, 2010, at 2:56 PM, Barry Abrahamson wrote:

> In my case, Varnish took a cache of 1 million objects, purged 920k of them.  When there were 80k objects left the child restarted, thus dumping the remaining 80k :)  

Happened again - here is the backtrace info:

AdvChild (7222) died signal=6
Child (7222) Panic message: Assert error in STV_alloc(), stevedore.c line 71:
  Condition((st) != NULL) not true.
thread = (cache-worker)
Backtrace:
  0x41d655: pan_ic+85
  0x433815: STV_alloc+a5
  0x416ca4: Fetch+684
  0x41131f: cnt_fetch+cf
  0x4125a5: CNT_Session+3a5
  0x41f616: wrk_do_cnt_sess+86
  0x41eb90: wrk_thread+1b0
  0x7f79f61e0fc7: _end+7f79f5b7a147
  0x7f79f5abb59d: _end+7f79f545471d
sp = 0x7f542e45a008 {
  fd = 9, id = 9, xid = 1122226896,
  client = 10.2.255.5:22276,
  step = STP_FETCH,
  handling = discard,
  restarts = 0, esis = 0
  ws = 0x7f542e45a080 {
    id = "sess",
    {s,f,r,e} = {0x7f542e45a820,+347,(nil),+16384},
  },

The request information shows that it was apparently fetching a 1GB file from the backend and trying to insert it into the cache.
--
Barry Abrahamson | Systems Wrangler | Automattic
Blog: http://barry.wordpress.com





From yann.malet at gmail.com  Tue Feb 23 15:47:51 2010
From: yann.malet at gmail.com (Yann Malet)
Date: Tue, 23 Feb 2010 11:47:51 -0400
Subject: Varnish and language cookie
Message-ID: <c19a16121002230747kedbc9f6y948602ded1084adc@mail.gmail.com>

Hello,

I am having hard time to to cache a multilingual web site. Vanish listen on
port 80 and proxy the request to a multilingual django cms what I would like
to do is to cache the pages per language and serve them from the
cache. Unfortunately so far I have not been able to get this working and
varnish keep on fetching th pages from the cms.

I am going to add below all the information I think useful do not hesitate
to let me know if you need more info ?

Here it is my configuration :
sub vcl_recv {
    # clean out requests sent via curls -X mode and LWP
    # http://varnish.projects.linpro.no/wiki/VCLExampleNormalizingReqUrl
    if (req.url ~ "^http://") {
        set req.url = regsub(req.url, "http://[^/]*", "");
    }
    # Set the backend based on the subdomain name
    if (req.http.host == "static.gwadeloop.com") {
        set req.backend = static;
    }
    if (req.http.host == "dev.gwadeloop.com") {
        set req.backend = django;
        # Add a trailing slash if missing
        if ((req.url ~ "[^\]$") && (! (req.url ~ "^/media/"))) {
            set req.url = req.url "/";
        }
    }
    if (req.http.Cookie) {
        # removes all cookies named __utm? (utma, utmb...)  -- Google
Analytics
        set req.http.Cookie = regsuball(req.http.Cookie, "(^|; )
*__utm.=[^;]+;? *", "\1");
        if (req.http.Cookie == "") {
            remove req.http.Cookie;
        }
   }
     if (req.http.Cookie ~ "django_language=") {
         set req.http.X-Varnish-Language =
             regsub(req.http.Cookie, "django_language=([a-z]{2})", "\1");
     }
}
-------------------------
sub vcl_hash {
    set req.hash += req.url;
    if (req.http.host) {
        set req.hash += req.http.host;
    } else {
        set req.hash += server.ip;
    }
    set req.hash += req.http.X-Varnish-Language;
    return (hash);
}

 -------------------------

here it is the information outputed by varnishlog when I try to access the
same page twice:
http://dpaste.com/163624/

I would be glad if someone could point me what I am doing wrong here.
Regards,
--yml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100223/ee437721/attachment.html>

From tfheen at varnish-software.com  Mon Feb 22 13:01:45 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Mon, 22 Feb 2010 14:01:45 +0100
Subject: Not seeing a successful purge
In-Reply-To: <b6b8b6b71002160636l4223720el97e612dec2edf9f@mail.gmail.com>
	(John Norman's message of "Tue, 16 Feb 2010 09:36:08 -0500")
References: <b6b8b6b71002111425w105b79aar1889c9c4f295f660@mail.gmail.com>
	<e95443d91002120249q65358b48m42609b236eb08eff@mail.gmail.com>
	<b6b8b6b71002120750o6d6d5fe9m9aa6a7d895dc26d7@mail.gmail.com>
	<b6b8b6b71002120854i340bbabam6b6ebd997c7deead@mail.gmail.com>
	<b6b8b6b71002121044h7a636d72hf06168558ad7193@mail.gmail.com>
	<87sk92nbp5.fsf@qurzaw.linpro.no>
	<b6b8b6b71002160636l4223720el97e612dec2edf9f@mail.gmail.com>
Message-ID: <87pr3x2zly.fsf@qurzaw.linpro.no>

]] John Norman 

| While my backend does say: "Vary: User-Agent" I do also have this in vcl_recv:
| 
|       unset req.http.user-agent;

Ok, I didn't notice.

| Isn't that enough (i.e., if I unset req.http.user-agent in my VCL, can
| I leave Vary: User-Agent on the backend)? I ask because it may be
| problematic to fix the backend in this case.

Yes, that should be enough.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From l at lrowe.co.uk  Fri Feb 26 15:51:30 2010
From: l at lrowe.co.uk (Laurence Rowe)
Date: Fri, 26 Feb 2010 15:51:30 +0000
Subject: Varnish and language cookie
In-Reply-To: <c19a16121002230747kedbc9f6y948602ded1084adc@mail.gmail.com>
References: <c19a16121002230747kedbc9f6y948602ded1084adc@mail.gmail.com>
Message-ID: <e95443d91002260751n113cfdfdhfc2253c49e9b3fb3@mail.gmail.com>

I think this is your problem:

   11 TxHeader     b Cookie:
sessionid=fd0523a529b0a09861a235d1c2fdd7de; changed=true; open_tab=1;
rule_path=/general; django_language=fr;
   11 RxHeader     b Vary: Accept-Encoding
   11 RxHeader     b Vary: Accept-Language, Cookie

If your pages are the same for all users then you should remove Cookie
from the Vary.

I would also remove the custom vcl_hash and just set
req.http.Accept-Language to the value from the cookie, that way you
avoid caching multiple copies of any images etc.

Laurence

On 23 February 2010 15:47, Yann Malet <yann.malet at gmail.com> wrote:
> Hello,
> I am having hard time to to cache a multilingual web site. Vanish listen on
> port 80 and proxy the request to a multilingual django cms what I would like
> to do is to cache the pages per language and serve them from the
> cache.?Unfortunately?so far I have not been able to get this working and
> varnish keep on fetching th pages from the cms.
> I am going to add below all the information I think useful do not hesitate
> to let me know if you need more info ?
> Here it is my configuration :
> sub vcl_recv {
> ?? ?# clean out requests sent via curls -X mode and LWP
> ?? ?# http://varnish.projects.linpro.no/wiki/VCLExampleNormalizingReqUrl
> ?? ?if (req.url ~ "^http://") {
> ?? ? ? ?set req.url = regsub(req.url, "http://[^/]*", "");
> ?? ?}
> ?? ?# Set the backend based on the subdomain name
> ?? ?if (req.http.host == "static.gwadeloop.com") {
> ?? ? ? ?set req.backend = static;
> ?? ?}
> ?? ?if (req.http.host == "dev.gwadeloop.com") {
> ?? ? ? ?set req.backend = django;
> ?? ? ? ?# Add a trailing slash if missing
> ?? ? ? ?if ((req.url ~ "[^\]$") && (! (req.url ~ "^/media/"))) {
> ?? ? ? ? ? ?set req.url = req.url "/";
> ?? ? ? ?}
> ?? ?}
> ?? ?if (req.http.Cookie) {
> ?? ? ? ?# removes all cookies named __utm? (utma, utmb...) ?-- Google
> Analytics
> ?? ? ? ?set req.http.Cookie = regsuball(req.http.Cookie, "(^|; )
> *__utm.=[^;]+;? *", "\1");
> ?? ? ? ?if (req.http.Cookie == "") {
> ?? ? ? ? ? ?remove req.http.Cookie;
> ?? ? ? ?}
> ?? }
> ?? ? if (req.http.Cookie ~ "django_language=") {
> ?? ? ? ? set req.http.X-Varnish-Language =
> ?? ? ? ? ? ? regsub(req.http.Cookie, "django_language=([a-z]{2})", "\1");
> ?? ? }
> }
> -------------------------
> sub vcl_hash {
> ?? ?set req.hash += req.url;
> ?? ?if (req.http.host) {
> ?? ? ? ?set req.hash += req.http.host;
> ?? ?} else {
> ?? ? ? ?set req.hash += server.ip;
> ?? ?}
> ?? ?set req.hash += req.http.X-Varnish-Language;
> ?? ?return (hash);
> }
> ?-------------------------
> here it is the information outputed by varnishlog when I try to access the
> same page twice:
> http://dpaste.com/163624/
> I would be glad if someone could point me what I am doing wrong here.
> Regards,
> --yml
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
>


From colin.nicholson at netintelligence.com  Fri Feb 26 17:24:53 2010
From: colin.nicholson at netintelligence.com (Colin Nicholson)
Date: Fri, 26 Feb 2010 17:24:53 +0000
Subject: regex matches on url escape chars
Message-ID: <4B8803E5.5000301@netintelligence.com>

Hi,

I have a web service which checks URLs sent to it by our software and
looks up a categorisation for that url (product is a web filter).

The request is of the form

/checkurl/http%3A%2F%2Fwww%2Efacebook%2Ecom%3A80%2Fx%2F2613988206%2Ffalse%2Fp%5F1327924941%3D2

which is checking
http://www.facebook.com:80/x/2613988206/false/p_1327924941=2.


I would like to rewrite the request, in this case, to be just
/checkurl/facebook%2Ecom, but I can't get the % escape codes to match
anything.

If the escape codes weren't in use, the following code works fine:

if (req.url ~ "facebook\.com") {
        set req.url = "/checkurl/facebook.com";
}

but

if (req.url ~ "facebook\%2Ecom") {
        set req.url = "/checkurl/facebook%2Ecom";
}

does not work. I've tried escaping the %2E with a backslash, but still
nothing. It isn't practical to change our software to not use the escape
codes unfortunately.


Does anyone have any ideas?


Thanks,
Colin




From colin.nicholson at netintelligence.com  Fri Feb 26 21:41:14 2010
From: colin.nicholson at netintelligence.com (Colin Nicholson)
Date: Fri, 26 Feb 2010 21:41:14 +0000
Subject: regex matches on url escape chars
In-Reply-To: <4B8803E5.5000301@netintelligence.com>
References: <4B8803E5.5000301@netintelligence.com>
Message-ID: <4B883FFA.4030004@netintelligence.com>

Hi,

Found the answer - the % sign was being treated as the start of a hex
sequence, so putting the hex code for the % sign (%25) did the trick.


The working snippet is now:

if (req.url ~ "facebook%252Ecom") {
       set req.url = "/checkurl/facebook.com";
}




Colin


On 26/02/2010 17:24, Colin Nicholson wrote:
> Hi,
> 
> I have a web service which checks URLs sent to it by our software and
> looks up a categorisation for that url (product is a web filter).
> 
> The request is of the form
> 
> /checkurl/http%3A%2F%2Fwww%2Efacebook%2Ecom%3A80%2Fx%2F2613988206%2Ffalse%2Fp%5F1327924941%3D2
> 
> which is checking
> http://www.facebook.com:80/x/2613988206/false/p_1327924941=2.
> 
> 
> I would like to rewrite the request, in this case, to be just
> /checkurl/facebook%2Ecom, but I can't get the % escape codes to match
> anything.
> 
> If the escape codes weren't in use, the following code works fine:
> 
> if (req.url ~ "facebook\.com") {
>         set req.url = "/checkurl/facebook.com";
> }
> 
> but
> 
> if (req.url ~ "facebook\%2Ecom") {
>         set req.url = "/checkurl/facebook%2Ecom";
> }
> 
> does not work. I've tried escaping the %2E with a backslash, but still
> nothing. It isn't practical to change our software to not use the escape
> codes unfortunately.
> 
> 
> Does anyone have any ideas?
> 
> 
> Thanks,
> Colin


From cosimo at streppone.it  Sat Feb 27 15:32:15 2010
From: cosimo at streppone.it (Cosimo Streppone)
Date: Sat, 27 Feb 2010 16:32:15 +0100
Subject: Varnish and language cookie
In-Reply-To: <faf26db81002270712x5f8a3006qb5e803f71868629e@mail.gmail.com>
References: <faf26db81002181258t52e8dccoe1dc12b0fb0c8da4@mail.gmail.com>
	<op.u8cikvgds5ttvb@cn01>
	<faf26db81002270712x5f8a3006qb5e803f71868629e@mail.gmail.com>
Message-ID: <op.u8slf1f9s5ttvb@cn01>

In data 27 febbraio 2010 alle ore 16:12:55, Alessandro Ronchi  
<alessandro.ronchi at soasi.com> ha scritto:

> 2010/2/19 Cosimo Streppone <cosimo at streppone.it>:
>
>> I'm no expert, but I think your config file
>> explicitly defeats caching when there is a cookie.
>>
>> 41  if (req.http.Authorization || req.http.Cookie) {
>
> You are right.
> I have a big problem:
>
> [...]

> - cookie is removed from the browser.

??? This shouldn't happen at all.

Maybe you're sending "Set-Cookie" headers from the django app
and they are being stored with the cached objects?

If so, when you know you're serving a cache hit, then
you can unset obj.http.Set-Cookie. IINM, that should
happen in vcl_deliver().

> Is it possible to save to a temp var the entire cookie, replacing in
> it the not important cookies and if that var is emtpy return cached
> version ignoring req.http.Cookie and leave that untoucked?
> I've tried but it but without success.

Cc'd varnish-misc, maybe there's someone facing the same exact problem,

-- 
Cosimo


From tom+varnish at ankh.fr.eu.org  Sat Feb 27 15:51:13 2010
From: tom+varnish at ankh.fr.eu.org (Thomas Parmelan)
Date: Sat, 27 Feb 2010 16:51:13 +0100
Subject: Weird situation with unexpected 206 from the backend, hit-for-pass
	and default_ttl
Message-ID: <20100227155113.GA27913@pern.ankh.fr.EU.org>

Hi,

I'm having quite a hard time trying to figure out what is going on
exactly here, sorry for the length but I prefer to give as much detail
as possible.

I'm using varnish on several varnish servers with the same VCL
configuration. I have varnish 2.0.4 and 2.0.6, Debian GNU/Linux on amd64
hardware (etch and lenny). All servers happen to have the same weird
behaviour regardless of those differences :

All is going well, great performances and cache hit ratio, everyone is
happy, unless some servers randomly start to make too many backend
connexions. After eliminating the usual suspects (cookies,
accept-encoding), I started investigating what kind of requests were
there, and I realized that somehow most of the requests where hitpass
for objects that were previously successfully cached on the same varnish
server. But the objects impacted are not necessarily the same on every
varnish server, and are not always the same, nor at the same time.

After some help from the irc channel (thanks everybody), I started to
track some "culprits" with "varnishtop -b -i TxURL", then searching the
last "varnishlog -c -o" entry for this object, and finally searching the
request id referenced in its HitPass entry.

On every case I tracked like this, the scenario was the same, and if I
understand things correctly (I'll give commented varnishlog just after),
it is like this:

  - a request comes from the object, it's a miss so we ask the backend
    for it. It is a pretty simple GET request, WITHOUT "Range" header

  - the backend, I don't know why, sometimes (and sometimes only)
    answers with 206 Partial Content, wich I believe is totally wrong
    and will be tracked down by them, but let's keep this to the varnish
    side

  - so because of that 206 answer, a hit for pass cache entry is
    created, with a certain TTL which in my case seems to be way too
    long

  - later on, for each simple (no Range header) request for this object,
    we hit the hitpass entry and pass to the backend

I think I have different problems here, one on the backend obviously,
but the others with varnish :

  - seeing as wrong as this backend answer is, I think it shouldn't be
    dealt with "normally" by varnish, it would me more interesting to
    let the next request have its chance to populate the cache with a
    valid (200) answer, in order to keep the following requests being
    able to be served from the cache. Is this something that should be
    changed in varnish, or in the vcl (and how) ?

  - the TTL used for the HitPass object seems to be the default_ttl (-t
    86400 in my setup); I tried to keep it low (0s or 10s) from the vcl
    config, like this :

    sub vcl_fetch {
        if (!obj.cacheable) {
                set obj.ttl = 0s;
                return (pass);
        }
	/* ... */
    }

    but I doesn't seem to work. I have the feeling that the HitPass TTL
    is somehow forced to the default_ttl value (which I think is not
    what the documentation implied). What is going on exactly here and
    how can this be changed from the vcl ?

  - I also tried to purge the hit-for-pass culprit with the CLI (purge
    req.host == the.host && req.url == /the/url), but it didn't work
    (the object was still there after). Any idea how to purge such
    objects ? Is this a bug ? 


Here are the varnishlog outputs. Firt, here is a pass because of the
HitPass object, with a correct (200) answer :

   18 ReqStart     c 89.80.252.34 1069 1643273915
   18 RxRequest    c GET
   18 RxURL        c /elements/css/v7/styles_services.css
   18 RxProtocol   c HTTP/1.1
   18 RxHeader     c Accept: */*
   18 RxHeader     c Referer: http://www.sfr.fr/fr/adsl.jsp?version=6004&contener=2
   18 RxHeader     c Accept-Language: fr
   18 RxHeader     c Accept-Encoding: gzip, deflate
   18 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
   18 RxHeader     c Host: img.s-sfr.fr
   18 RxHeader     c Connection: Keep-Alive
   18 VCL_call     c recv lookup
   18 VCL_call     c hash hash
   18 HitPass      c 1641180098
   18 VCL_call     c pass pass
   18 Backend      c 30 s_sfr s_sfr
   18 ObjProtocol  c HTTP/1.1
   18 ObjStatus    c 200
   18 ObjResponse  c OK
   18 ObjHeader    c Date: Sat, 27 Feb 2010 14:27:59 GMT
   18 ObjHeader    c Server: Apache/2.2.13 (Fedora)
   18 ObjHeader    c Last-Modified: Tue, 09 Feb 2010 09:59:57 GMT
   18 ObjHeader    c Via: http2
   18 ObjHeader    c Cache-Control: public
   18 ObjHeader    c Expires: Sat, 27 Feb 2010 16:20:53 GMT
   18 ObjHeader    c Vary: Accept-Encoding
   18 ObjHeader    c Content-Type: text/css;charset=ISO-8859-15
   18 TTL          c 1643273915 RFC 6773 1267280879 1267280879 1267287653 0 0
   18 VCL_call     c fetch deliver
   18 Length       c 3284
   18 VCL_call     c deliver deliver
   18 TxProtocol   c HTTP/1.1
   18 TxStatus     c 200
   18 TxResponse   c OK
   18 TxHeader     c Server: Apache/2.2.13 (Fedora)
   18 TxHeader     c Last-Modified: Tue, 09 Feb 2010 09:59:57 GMT
   18 TxHeader     c Via: http2
   18 TxHeader     c Cache-Control: public
   18 TxHeader     c Expires: Sat, 27 Feb 2010 16:20:53 GMT
   18 TxHeader     c Vary: Accept-Encoding
   18 TxHeader     c Content-Type: text/css;charset=ISO-8859-15
   18 TxHeader     c Content-Length: 3284
   18 TxHeader     c Date: Sat, 27 Feb 2010 14:27:59 GMT
   18 TxHeader     c X-Varnish: 1643273915
   18 TxHeader     c Age: 0
   18 TxHeader     c Via: 1.1 varnish
   18 TxHeader     c Connection: keep-alive
   18 ReqEnd       c 1643273915 1267280879.342154026 1267280879.351441145 0.075042009 0.009259224 0.000027895

=> so, the HitPass was created by request id 1641180098. Let's see that
request :

   59 ReqStart     c 77.205.33.140 52401 1641180098
   59 RxRequest    c GET
   59 RxURL        c /elements/css/v7/styles_services.css
   59 RxProtocol   c HTTP/1.1
   59 RxHeader     c Accept: */*
   59 RxHeader     c Referer: http://www.sfr.fr/fr/adsl.jsp
   59 RxHeader     c Accept-Language: fr
   59 RxHeader     c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; GTB6.4; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
   59 RxHeader     c Accept-Encoding: gzip, deflate
   59 RxHeader     c Host: img.s-sfr.fr
   59 RxHeader     c Connection: Keep-Alive
   59 VCL_call     c recv lookup
   59 VCL_call     c hash hash
   59 VCL_call     c miss fetch
   59 Backend      c 21 s_sfr s_sfr
   59 ObjProtocol  c HTTP/1.1
   59 ObjStatus    c 206
   59 ObjResponse  c Partial Content
   59 ObjHeader    c Date: Fri, 26 Feb 2010 22:01:08 GMT
   59 ObjHeader    c Server: Apache/2.2.13 (Fedora)
   59 ObjHeader    c Last-Modified: Tue, 09 Feb 2010 09:59:57 GMT
   59 ObjHeader    c Via: http4
   59 ObjHeader    c Cache-Control: public
   59 ObjHeader    c Expires: Fri, 26 Feb 2010 23:08:27 GMT
   59 ObjHeader    c Content-Type: text/css;charset=ISO-8859-15
   59 TTL          c 1641180098 RFC 4038 1267221668 1267221668 1267225707 0 0
   59 VCL_call     c fetch
   59 TTL          c 1641180098 VCL 0 1267221668
   59 VCL_return   c pass
   59 Length       c 2211
   59 VCL_call     c deliver deliver
   59 TxProtocol   c HTTP/1.1
   59 TxStatus     c 206
   59 TxResponse   c Partial Content
   59 TxHeader     c Server: Apache/2.2.13 (Fedora)
   59 TxHeader     c Last-Modified: Tue, 09 Feb 2010 09:59:57 GMT
   59 TxHeader     c Via: http4
   59 TxHeader     c Cache-Control: public
   59 TxHeader     c Expires: Fri, 26 Feb 2010 23:08:27 GMT
   59 TxHeader     c Content-Type: text/css;charset=ISO-8859-15
   59 TxHeader     c Content-Length: 2211
   59 TxHeader     c Date: Fri, 26 Feb 2010 22:01:08 GMT
   59 TxHeader     c X-Varnish: 1641180098
   59 TxHeader     c Age: 0
   59 TxHeader     c Via: 1.1 varnish
   59 TxHeader     c Connection: keep-alive
   59 ReqEnd       c 1641180098 1267221668.117854595 1267221668.127019882 2.395729065 0.009134293 0.000030994

=> Here is the "wrong" 206 answer. No Range header was in the request so
200 and the full content was expected. Also no Content-Range in the
backend answer, that's also very strange. Anyway, its TTL would be 4038
calculated from the HTTP headers (RFC 4038), then it is forced to 0 from
VCL (VCL 0), then we go to pass.

Now pay attention to the Date: headers from the backend answers (yes,
the backend time is correct ;)). The HitPass object was created "Fri, 26
Feb 2010 22:01:08 GMT" with a calculated TTL of 4038 (forced to 0 from
VCL but it doesn't work), so it should be purged about 4038s later, but
it is still there for a request made "Sat, 27 Feb 2010 14:27:59 GMT",
thats much, much more !!

That should not be possible, unless default_ttl (-t 86400 in my setup)
is used instead of the computed TTL...

Many thanks in advance for any explanation or advice on this situation !

Best regards,
Tom

-- 
Thomas Parmelan  -+-  Thomas.Parmelan at free.fr  -+-  tom at ankh.fr.EU.org


From alessandro.ronchi at soasi.com  Sat Feb 27 16:35:53 2010
From: alessandro.ronchi at soasi.com (Alessandro Ronchi)
Date: Sat, 27 Feb 2010 17:35:53 +0100
Subject: Varnish and language cookie
In-Reply-To: <op.u8slf1f9s5ttvb@cn01>
References: <faf26db81002181258t52e8dccoe1dc12b0fb0c8da4@mail.gmail.com> 
	<op.u8cikvgds5ttvb@cn01>
	<faf26db81002270712x5f8a3006qb5e803f71868629e@mail.gmail.com> 
	<op.u8slf1f9s5ttvb@cn01>
Message-ID: <faf26db81002270835o6e34a68crfb673b6ffbf04061@mail.gmail.com>

2010/2/27 Cosimo Streppone <cosimo at streppone.it>:

>> - cookie is removed from the browser.
>
> ??? This shouldn't happen at all.

I'm unable to cache content with django-language=xx cookie and return
the cached page.

I've tried all the day, but without any success.
http://dpaste.com/165609/

If I unset that cookie, the backend doesn't know that language the
output is and it returns the default language.

If I leave the cookie, it doesn't cache it.

The best thing I've done is to have cached the requests without the
cookie (and language), and get the other passed.

But I think I can do that, it's a quite simple example:


- all pages are cachable and varies only with language.
- language is set in a cookie (that has to be sent to the backend if
the page is not present in cache) or with a get url (&lang=en).
- with the get url the backend sets the cookie language. so after that
other pages will be translated also without the &lang=en suffix.

- other cookies, except for google's, must send the page to pass.



-- 
Alessandro Ronchi

http://www.soasi.com
SOASI - Sviluppo Software e Sistemi Open Source

http://hobbygiochi.com
Hobby & Giochi, l'e-commerce del divertimento


From yann.malet at gmail.com  Fri Feb 26 13:38:28 2010
From: yann.malet at gmail.com (Yann Malet)
Date: Fri, 26 Feb 2010 09:38:28 -0400
Subject: Varnish and language cookie
In-Reply-To: <c19a16121002260536idd5121ci64bbc3e4286249c4@mail.gmail.com>
References: <c19a16121002230747kedbc9f6y948602ded1084adc@mail.gmail.com>
	<744355347-1267175044-cardhu_decombobulator_blackberry.rim.net-272404610-@bda196.bisx.produk.on.blackberry>
	<c19a16121002260536idd5121ci64bbc3e4286249c4@mail.gmail.com>
Message-ID: <c19a16121002260538l238d21a1n94f8d7dc2cb4f0cc@mail.gmail.com>

>
> hello,
> This confusing behavior was due to a some of different factor a bug in
> django cache middleware for i18n pages, the same pages in french, german,
> english, .... and my relative inexperince with varnish. I think that now I
> have this issue solved witht the following configuration:
> http://dpaste.com/165182/
>
> The interesting parts are in vcl_recv :
> # This is the only important part of the cookie because
>
>     # an annonymous user could get a page that was generated and
>     # cached for another user.
>     if (req.http.Cookie ~ "django_language=") {
>         set req.http.X-Varnish-Language =
>             regsub(req.http.Cookie, "django_language=([a-z]{2})", "\1");
>
> }
>
> in vcl_hach where I add the language to the hash :
>
> sub vcl_hash {
>     set req.hash += req.url;
>     if (req.http.host) {
>         set req.hash += req.http.host;
>     } else {
>         set req.hash += server.ip;
>     }
>     set req.hash += req.http.X-Varnish-Language;
>     return (hash);
> }
>
> and in vcl_fetch where I have commented out the block that make varnish
> "pass" if there is a cookie :
>
> sub vcl_fetch {
>    if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)") {
>    # varnish by default ignores Pragma and Cache-Control headers. It
>    # only looks at the "max-age=" value in the Cache-Control header to
>    # determine the TTL. So we need this rule so that the cache respects
>    # the wishes of the backend application.
>         pass;
>     }
>     if (!obj.cacheable) {
>         return (pass);
>     }
>     # don't allow caching pages that are protected by basic authentication
>     # unless when they explicitly set the cache-control to public.
>     if (req.http.Authorization && !obj.http.Cache-Control ~ "public") {
>         pass;
>     }
> # Varnish by default does not serve from cache if there is a cookie
> #    if (obj.http.Set-Cookie) {
> #        return (pass);
> #    }
>     set obj.prefetch =  -30s;
>     return (deliver);
> }
>
> thank you
> Regards,
> --yml
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20100226/639adfda/attachment.html>