From ruben at varnish-software.com  Thu Apr 10 06:06:53 2014
From: ruben at varnish-software.com (=?UTF-8?Q?Rub=C3=A9n_Romero?=)
Date: Thu, 10 Apr 2014 08:06:53 +0200
Subject: Varnish Cache 4.0 Release Parties on April 29th, 2014
Message-ID: <CAEfnkDZNUbLpJuH0uWa0TryB5QbyoPR+jAKFe4WxRBV49ezZ3Q@mail.gmail.com>

Hello everyone,

Every few years we have a major Varnish Cache release and that needs to be
celebrated properly. So let's again gather locally to learn about the
goodness the 4.0.0 release brings in the good company of fellow Varnishers.

As the release is now imminent we have set the date to April 29th, 2014 for
the Varnish 4.0 Release Parties. Our site is now up and you can organize or
join a party already now:

* Party Site with Map and General info > http://v4party.varnish-cache.org/
* Your own party + party pack? > http://v4party.varnish-cache.org/help-us

As usual, make sure to tag your blogs, tweets, pictures and videos with the
#vr4p hashtag so that we can all be part of the fun both during and after
the parties.

If you are busy on work rotation that day or have no party nearby, no
worries, you can join us online on the Varnish Cache 4.0 Release Party -
Live Stream (Hangout on Air) from Copenhagen, Oslo and London. You can RSVP
already now > https://plus.google.com/events/cvuqnm8cof58paogkc2uj0giru0

If you have any questions related to the Release party (i.e. want to set up
your own party and don't know where to start or want to broadcast from your
local party) feel free to reply to this email or reach out to me on Skype,
Twitter or IRC and I will do what i can to give you a hand.

Hope you all can join us!

In behalf of the Varnish Cache team,
-- 
<http://www.varnish-software.com/>*Rub?n Romero*
Community & Sales | Varnish Software AS
Cell: +47 95964088 / Office: +47 21989260
Skype, Twitter & IRC: ruben_varnish
We Make Websites Fly!Winner of the 2013 Red Herring Top 100 Global Awards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140410/de4049dd/attachment.html>

From dridi.boukelmoune at zenika.com  Fri Apr 11 07:11:14 2014
From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune)
Date: Fri, 11 Apr 2014 09:11:14 +0200
Subject: Varnish Cache 4.0 Release Parties on April 29th, 2014
In-Reply-To: <1474196505.47951096.1397197600704.JavaMail.root@sfu.ca>
References: <CAEfnkDZNUbLpJuH0uWa0TryB5QbyoPR+jAKFe4WxRBV49ezZ3Q@mail.gmail.com>
 <1474196505.47951096.1397197600704.JavaMail.root@sfu.ca>
Message-ID: <CABtDKm7ntK1Nyv7td30ejFn+nhd+W9SEx1kAxEX1Exp2FuEtFQ@mail.gmail.com>

On Fri, Apr 11, 2014 at 8:26 AM, James A. Peltier <jpeltier at sfu.ca> wrote:
> ________________________________
>
> Hello everyone,
>
> Every few years we have a major Varnish Cache release and that needs to be
> celebrated properly. So let's again gather locally to learn about the
> goodness the 4.0.0 release brings in the good company of fellow Varnishers.
>
> As the release is now imminent we have set the date to April 29th, 2014 for
> the Varnish 4.0 Release Parties. Our site is now up and you can organize or
> join a party already now:
>
> * Party Site with Map and General info > http://v4party.varnish-cache.org/
> * Your own party + party pack? > http://v4party.varnish-cache.org/help-us
>
> As usual, make sure to tag your blogs, tweets, pictures and videos with the
> #vr4p hashtag so that we can all be part of the fun both during and after
> the parties.
>
> If you are busy on work rotation that day or have no party nearby, no
> worries, you can join us online on the Varnish Cache 4.0 Release Party -
> Live Stream (Hangout on Air) from Copenhagen, Oslo and London. You can RSVP
> already now > https://plus.google.com/events/cvuqnm8cof58paogkc2uj0giru0
>
> If you have any questions related to the Release party (i.e. want to set up
> your own party and don't know where to start or want to broadcast from your
> local party) feel free to reply to this email or reach out to me on Skype,
> Twitter or IRC and I will do what i can to give you a hand.
>
> Hope you all can join us!
>
> In behalf of the Varnish Cache team,
>
>
> It would seem that Varnish 4 RHEL 6 repos have a requirement for jemalloc,
> however there are no instructions of where to get it and it is not provided
> as part of the repository.  Is it an error that it is not listed as a
> dependancy to the RHEL/CentOS 6 build requirements or is the RPM wrong?

Hi James,

jemalloc is availlable through the EPEL repo for RHEL and its rebuilds
like CentOS.

Cheers,
Dridi

> --
> James A. Peltier
> Manager, IT Services - Research Computing Group
> Simon Fraser University - Burnaby Campus
> Phone   : 778-782-6573
> Fax     : 778-782-3045
> E-Mail  : jpeltier at sfu.ca
> Website : http://www.sfu.ca/itservices
>
> "Around here, however, we don?t look backwards for very long.  We KEEP
> MOVING FORWARD, opening up new doors and doing things because we?re curious
> and curiosity keeps leading us down new paths." - Walt Disney
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc



From dridi.boukelmoune at zenika.com  Fri Apr 11 08:23:12 2014
From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune)
Date: Fri, 11 Apr 2014 10:23:12 +0200
Subject: Varnish Cache 4.0 Release Parties on April 29th, 2014
In-Reply-To: <459011850.47972477.1397202709993.JavaMail.root@sfu.ca>
References: <CABtDKm7ntK1Nyv7td30ejFn+nhd+W9SEx1kAxEX1Exp2FuEtFQ@mail.gmail.com>
 <459011850.47972477.1397202709993.JavaMail.root@sfu.ca>
Message-ID: <CABtDKm6nMbB+18unSvGu1dMCNaaKf=iZ6E_ouiP0cUz2EWmgyQ@mail.gmail.com>

On Fri, Apr 11, 2014 at 9:51 AM, James A. Peltier <jpeltier at sfu.ca> wrote:
> ----- Original Message -----
> | On Fri, Apr 11, 2014 at 8:26 AM, James A. Peltier <jpeltier at sfu.ca>
> | wrote:
> | > ________________________________
> | >
> | > Hello everyone,
> | >
> | > Every few years we have a major Varnish Cache release and that
> | > needs to be
> | > celebrated properly. So let's again gather locally to learn about
> | > the
> | > goodness the 4.0.0 release brings in the good company of fellow
> | > Varnishers.
> | >
> | > As the release is now imminent we have set the date to April 29th,
> | > 2014 for
> | > the Varnish 4.0 Release Parties. Our site is now up and you can
> | > organize or
> | > join a party already now:
> | >
> | > * Party Site with Map and General info >
> | > http://v4party.varnish-cache.org/
> | > * Your own party + party pack? >
> | > http://v4party.varnish-cache.org/help-us
> | >
> | > As usual, make sure to tag your blogs, tweets, pictures and videos
> | > with the
> | > #vr4p hashtag so that we can all be part of the fun both during and
> | > after
> | > the parties.
> | >
> | > If you are busy on work rotation that day or have no party nearby,
> | > no
> | > worries, you can join us online on the Varnish Cache 4.0 Release
> | > Party -
> | > Live Stream (Hangout on Air) from Copenhagen, Oslo and London. You
> | > can RSVP
> | > already now >
> | > https://plus.google.com/events/cvuqnm8cof58paogkc2uj0giru0
> | >
> | > If you have any questions related to the Release party (i.e. want
> | > to set up
> | > your own party and don't know where to start or want to broadcast
> | > from your
> | > local party) feel free to reply to this email or reach out to me on
> | > Skype,
> | > Twitter or IRC and I will do what i can to give you a hand.
> | >
> | > Hope you all can join us!
> | >
> | > In behalf of the Varnish Cache team,
> | >
> | >
> | > It would seem that Varnish 4 RHEL 6 repos have a requirement for
> | > jemalloc,
> | > however there are no instructions of where to get it and it is not
> | > provided
> | > as part of the repository.  Is it an error that it is not listed as
> | > a
> | > dependancy to the RHEL/CentOS 6 build requirements or is the RPM
> | > wrong?
> |
> | Hi James,
> |
> | jemalloc is availlable through the EPEL repo for RHEL and its
> | rebuilds
> | like CentOS.
> |
> | Cheers,
> | Dridi
>
> Yes, that I understand, more the documentation for compilation and for installation of the RPM do not state that EPEL is a requirement for Varnish 4.
>
> https://www.varnish-cache.org/installation/redhat
>
> Does not include Varnish 4 documentation (yet), but is linked to from Varnish 4 document
>
> https://www.varnish-cache.org/docs/4.0/installation/install.html#red-hat-centos
>
> nor is it listed as a dependancy for compiling.  I assume this is a "bug" and I'm reporting it.

Good catch,

If my memory serves well Varnish used to embed its own copy of
jemalloc, someone forgot to update the documentation. It still
mentions el5 too which is not supported for Varnish 4.

Dridi

> --
> James A. Peltier
> Manager, IT Services - Research Computing Group
> Simon Fraser University - Burnaby Campus
> Phone   : 778-782-6573
> Fax     : 778-782-3045
> E-Mail  : jpeltier at sfu.ca
> Website : http://www.sfu.ca/itservices
>
> "Around here, however, we don?t look backwards for very long.  We KEEP MOVING FORWARD, opening up new doors and doing things because we?re curious and curiosity keeps leading us down new paths." - Walt Disney



From dridi.boukelmoune at zenika.com  Fri Apr 18 09:49:19 2014
From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune)
Date: Fri, 18 Apr 2014 11:49:19 +0200
Subject: Semantic patches with spatch(1) from Coccinelle
Message-ID: <CABtDKm68YagMak8bD+rh+uU9Udk58qxrjmX0DxhM5dxrWk3Fwg@mail.gmail.com>

Hi all,

Last September I was introduced to Coccinelle [1,2] at a conference
and since then I kept wondering how I could ever try it. Last week I
was randomly reading parts of Varnish code (which I haven't done since
last August I think) and found a piece of code that felt odd to me. Since
Coccinelle's semantic patches are meant for C code (for the Linux kernel
initially) my brain eventually connected the right neurons and here I was
making my Coccinelle helloworld with Varnish.

The two patches only pick the right macros from miniobj.h and vas.h
throughout the code base, and fortunately spatch even outputs
git-friendly patches.

For instance, to fix the "mistake" I found in stevedore.c, I've
written this spatch:
   @@
   expression x, y;
   @@

   -if (x != NULL)
   - CHECK_OBJ_NOTNULL(x, y);
   +CHECK_OBJ_ORNULL(x, y);

Pretty simple :)

My patch set doesn't bring any value, only consistency to some extent.
I think spatch(1) might prove useful for refactoring too (vmod3to4.cocci?).
Coccinelle's semantic patches are rather expressive in my opinion, the
documentation could include some for vmod developers for instance (eg.
prefer this approach instead of that one).

Happy Easter,
Dridi

[1] http://coccinelle.lip6.fr/
[2] http://coccinellery.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: miniobj.cocci
Type: application/octet-stream
Size: 319 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140418/6cfd0ffb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vas.cocci
Type: application/octet-stream
Size: 207 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140418/6cfd0ffb/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: miniobj.patch
Type: text/x-patch
Size: 592 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140418/6cfd0ffb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vas.patch
Type: text/x-patch
Size: 26074 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140418/6cfd0ffb/attachment-0001.bin>

From jdzstz at gmail.com  Mon Apr 21 23:44:42 2014
From: jdzstz at gmail.com (jdzstz)
Date: Tue, 22 Apr 2014 01:44:42 +0200
Subject: Updated varnish cygwin patches to 3.0.5 varnish version (32 and 64
 bits)
In-Reply-To: <CA+wAnvwh7uU6BvxyD+aqD1pAx1rRWgYC7MZ8n-BagrdY-hKa_A@mail.gmail.com>
References: <CA+wAnvwh7uU6BvxyD+aqD1pAx1rRWgYC7MZ8n-BagrdY-hKa_A@mail.gmail.com>
Message-ID: <5355AD6A.5090108@gmail.com>

Hi All,

I have updated varnish packages in Cygwin (Windows) plataform to varnish version 3.0.5.

This is the first version available at both 32 and 64 bits windows architecture.

You can install it executing cygwin setup.exe and selecting "varnish" package in selection list at categories "Net" or "Web":
  - 32 bits installer: http://cygwin.com/setup-x86.exe
  - 64 bits installer: http://cygwin.com/setup-x86_64.exe

More information:
  - https://www.varnish-cache.org/trac/wiki/VarnishOnCygwinWindows
  - http://downloads.sourceforge.net/project/cygvarnish/cygport-packages/varnish-package-selection.png


The patches are also available at varnish trac wiki:

  - Changes that allows varnish to be compiled at cygwin environment:
https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_makefiles.patch
  - Changes that fixes varnishtest problems (timeouts and path
problems): https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_varnishtest.patch
  - Changes that allows windows paths for some varnish directories:
https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_windows_path.patch
  - Changes that fixes some problems with varnishd and tcp_nodelay problems:
https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_varnishd.patch

Almost all changes are written to be platform independent, so patched
code can be compiled at both cygwin and linux.


Regards,
Jorge


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com




From phk at phk.freebsd.dk  Tue Apr 22 08:24:10 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 22 Apr 2014 08:24:10 +0000
Subject: Semantic patches with spatch(1) from Coccinelle
In-Reply-To: <CABtDKm68YagMak8bD+rh+uU9Udk58qxrjmX0DxhM5dxrWk3Fwg@mail.gmail.com>
References: <CABtDKm68YagMak8bD+rh+uU9Udk58qxrjmX0DxhM5dxrWk3Fwg@mail.gmail.com>
Message-ID: <7176.1398155050@critter.freebsd.dk>

In message <CABtDKm68YagMak8bD+rh+uU9Udk58qxrjmX0DxhM5dxrWk3Fwg at mail.gmail.com>
, Dridi Boukelmoune writes:

>The two patches only pick the right macros from miniobj.h and vas.h
>throughout the code base, and fortunately spatch even outputs
>git-friendly patches.

Thanks, committed.

The backstory is that originally I only intended AZ and AN for pointer
arguments, but that was relaxed later as they were so damn convenient :-)

-- 
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  Tue Apr 22 09:11:55 2014
From: perbu at varnish-software.com (Per Buer)
Date: Tue, 22 Apr 2014 11:11:55 +0200
Subject: Responses to ranged requests
Message-ID: <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=mM+qnA@mail.gmail.com>

Hi.

moseleymark <https://www.varnish-cache.org/users/moseleymark> in the forum,
commented that Varnish responds with a "200 OK" when responding to ranged
requests. Looking at the tests, that seems to be desired behavior.

Looking at RFC 2049 I think the correct response is "206 partial". From
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html :

10.2.7 206 Partial Content

The server has fulfilled the partial GET request for the resource. The
request MUST have included a Range header field (section 14.35) indicating
the desired range, and MAY have included an If-Range header field (section
14.27 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.27>) to
make the request conditional.

The response MUST include the following header fields:

      - Either a Content-Range header field (section 14.16) indicating
        the range included with this response, or a multipart/byteranges
        Content-Type including Content-Range fields for each part. If a
        Content-Length header field is present in the response, its
        value MUST match the actual number of OCTETs transmitted in the
        message-body.

      - Date

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the 206 response is the result of an If-Range request that used a strong
cache validator (see section 13.3.3), the response SHOULD NOT include other
entity-headers. If the response is the result of an If-Range request that
used a weak validator, the response MUST NOT include other entity-headers;
this prevents inconsistencies between cached entity-bodies and updated
headers. Otherwise, the response MUST include all of the entity-headers
that would have been returned with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified headers do not match exactly, see
13.5.4 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.4>.

A cache that does not support the Range and Content-Range headers MUST NOT
cache 206 (Partial) responses.


-- 
 <http://www.varnish-software.com/> *Per Buer*
CTO | Varnish Software
Phone: +47 958 39 117 | Skype: per.buer
We Make Websites Fly!

Winner of the Red Herring Top 100 Global Award 2013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140422/47ed59c8/attachment.html>

From phk at phk.freebsd.dk  Tue Apr 22 09:21:41 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 22 Apr 2014 09:21:41 +0000
Subject: Responses to ranged requests
In-Reply-To: <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=mM+qnA@mail.gmail.com>
References: <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=mM+qnA@mail.gmail.com>
Message-ID: <35364.1398158501@critter.freebsd.dk>

In message <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=mM+qnA at mail.gmail.com>
, Per Buer writes:

>moseleymark <https://www.varnish-cache.org/users/moseleymark> in the forum,
>commented that Varnish responds with a "200 OK" when responding to ranged
>requests. Looking at the tests, that seems to be desired behavior.

Test-case c00034 tells me that Varnish correctly responds with 206 if
it does respect the range, and 200 otherwise ?

Do you have a case where this is not the case ?

-- 
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  Tue Apr 22 09:37:22 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 22 Apr 2014 09:37:22 +0000
Subject: Updated varnish cygwin patches to 3.0.5 varnish version (32 and
 64 bits)
In-Reply-To: <5355AD6A.5090108@gmail.com>
References: <CA+wAnvwh7uU6BvxyD+aqD1pAx1rRWgYC7MZ8n-BagrdY-hKa_A@mail.gmail.com>
 <5355AD6A.5090108@gmail.com>
Message-ID: <35551.1398159442@critter.freebsd.dk>

In message <5355AD6A.5090108 at gmail.com>, jdzstz writes:

>  - Changes that fixes varnishtest problems (timeouts and path
>problems): https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_varnishtest.patch

This patch kind of hint that Varnish at Cygwin must suck pretty
badly performance wise ?  Is that because of the hardware you
run it on, or is it chronic ?

>  - Changes that fixes some problems with varnishd and tcp_nodelay problems:
>https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_varnishd.patch

Where on Earth does the idea that TCP_NODELAY takes a bool argument
come from ?  Are you sure about this ?

Don't let the canonical decriptions mention about "The boolean option
TCP_NODELAY [...]" confuse you:  It still takes an int argument any
place I have ever seen it.

If the Cygwin crew made it take a bool, they're portability-mororns.

-- 
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  Tue Apr 22 09:49:22 2014
From: perbu at varnish-software.com (Per Buer)
Date: Tue, 22 Apr 2014 11:49:22 +0200
Subject: Responses to ranged requests
In-Reply-To: <35364.1398158501@critter.freebsd.dk>
References: <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=mM+qnA@mail.gmail.com>
 <35364.1398158501@critter.freebsd.dk>
Message-ID: <CAOXZevD-ayyWvKC_ap4sVobmK2tQTLAjJDFYnrxVSaVpY4ABuQ@mail.gmail.com>

On Tue, Apr 22, 2014 at 11:21 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=
> mM+qnA at mail.gmail.com>
> , Per Buer writes:
>
> >moseleymark <https://www.varnish-cache.org/users/moseleymark> in the
> forum,
> >commented that Varnish responds with a "200 OK" when responding to ranged
> >requests. Looking at the tests, that seems to be desired behavior.
>
> Test-case c00034 tells me that Varnish correctly responds with 206 if
> it does respect the range, and 200 otherwise ?
>
> Do you have a case where this is not the case ?
>

User error. Both the user reporting it and I had syntax errors on the
ranged requests and Varnish correctly responded with the whole content and
a 200 error.

Move along. Nothing to see.

-- 
 <http://www.varnish-software.com/> *Per Buer*
CTO | Varnish Software
Phone: +47 958 39 117 | Skype: per.buer
We Make Websites Fly!

Winner of the Red Herring Top 100 Global Award 2013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140422/940f5310/attachment.html>

From perbu at varnish-software.com  Tue Apr 22 10:31:28 2014
From: perbu at varnish-software.com (Per Buer)
Date: Tue, 22 Apr 2014 12:31:28 +0200
Subject: Responses to ranged requests
In-Reply-To: <CAOXZevD-ayyWvKC_ap4sVobmK2tQTLAjJDFYnrxVSaVpY4ABuQ@mail.gmail.com>
References: <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=mM+qnA@mail.gmail.com>
 <35364.1398158501@critter.freebsd.dk>
 <CAOXZevD-ayyWvKC_ap4sVobmK2tQTLAjJDFYnrxVSaVpY4ABuQ@mail.gmail.com>
Message-ID: <CAOXZevDpa6yQz+wV7RxJpWYntTbh1jSGKuHKYUE3FANLd1=KCQ@mail.gmail.com>

On Tue, Apr 22, 2014 at 11:49 AM, Per Buer <perbu at varnish-software.com>wrote:

> On Tue, Apr 22, 2014 at 11:21 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:
>
>> In message <CAOXZevBTrbUf7HGD=S-pH7k5Kchm5akj5F+vQCcXXap=
>> mM+qnA at mail.gmail.com>
>> , Per Buer writes:
>>
>> >moseleymark <https://www.varnish-cache.org/users/moseleymark> in the
>> forum,
>> >commented that Varnish responds with a "200 OK" when responding to ranged
>> >requests. Looking at the tests, that seems to be desired behavior.
>>
>> Test-case c00034 tells me that Varnish correctly responds with 206 if
>> it does respect the range, and 200 otherwise ?
>>
>> Do you have a case where this is not the case ?
>>
>
> User error. Both the user reporting it and I had syntax errors on the
> ranged requests and Varnish correctly responded with the whole content and
> a 200 error.
>
> Move along. Nothing to see.
>

The source of my confusion is that Varnish will respond with a "200 OK" on
a ranged request and give the whole document on a cache miss, whereas it
will respond as expected with the range on a cache hit.



-- 
 <http://www.varnish-software.com/> *Per Buer*
CTO | Varnish Software
Phone: +47 958 39 117 | Skype: per.buer
We Make Websites Fly!

Winner of the Red Herring Top 100 Global Award 2013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140422/80cc1461/attachment.html>

From ingvar at redpill-linpro.com  Tue Apr 22 23:27:38 2014
From: ingvar at redpill-linpro.com (Ingvar Hagelund)
Date: Wed, 23 Apr 2014 01:27:38 +0200 (CEST)
Subject: Problems in the varnish-4.0.0 rpms
In-Reply-To: <498421803.1339692.1398207769054.JavaMail.zimbra@redpill-linpro.com>
Message-ID: <1922094285.1341325.1398209258938.JavaMail.zimbra@redpill-linpro.com>

I should have reported this by trac, but it is down at the moment. 

There are some serious build errors in the rpm packages of varnish-4.0.0 from the varnish-cache.org repository. 

Consider the following; varnish should _not_ provide things like libc.so.6, libncurses or /bin/bash !!! This breaks the rpm database. It should be fixed as soon as possible. 

$ rpm -qp --provides varnish-4.0.0-1.el6.x86_64.rpm 
/bin/bash 
/bin/sh 
libc.so.6()(64bit) 
libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3.2)(64bit) 
libc.so.6(GLIBC_2.3)(64bit) 
libdl.so.2()(64bit) 
libdl.so.2(GLIBC_2.2.5)(64bit) 
libedit.so.0()(64bit) 
libjemalloc.so.1()(64bit) 
libm.so.6()(64bit) 
libm.so.6(GLIBC_2.2.5)(64bit) 
libncurses.so.5()(64bit) 
libncursesw.so.5()(64bit) 
libnsl.so.1()(64bit) 
libpcre.so.0()(64bit) 
libpthread.so.0()(64bit) 
libpthread.so.0(GLIBC_2.2.5)(64bit) 
libpthread.so.0(GLIBC_2.3.2)(64bit) 
librt.so.1()(64bit) 
librt.so.1(GLIBC_2.2.5)(64bit) 
libtinfo.so.5()(64bit) 
libvarnishapi.so.1()(64bit) 
libvarnishcompat.so()(64bit) 
libvarnish.so()(64bit) 
libvcc.so()(64bit) 
libvgz.so()(64bit) 
varnishabi-4.0.0-26c2dc6 
varnish = 4.0.0-1.el6 
varnish(x86-64) = 4.0.0-1.el6 


This is caused by a small typo/bug in redhat/find-provides. The script calls the system's find-requires. It should call find-provides. Also the correct path is /usr/lib/rpm/redhat/find-provides, from the redhat-rpm-config package on redhat and derivates, though the path in the script may be available by historical reasons, or perhaps for compatibility with other rpm based distributions. 

Fixing the script will fix the bug. This would also make the explicit provides of LIBVARNISHAPI for various versions unnecessary, so they should be removed as well. I proposed adding these as a workaround in an earlier trac bug, since I didn't catch the script bug in tp2+. That workaround was dropped in verbatim, though it was hard coded for 64bit, which is yet another bug, though only visible on 32bit systems. 

Since all this happens in the rpm package only, the easiest way out is fixing the script by adding a patch to the rpm, fixing those other bits, bump the rpm Release tag, and then you only need to roll new rpm packages. A complete release should no be necessary. 

Ingvar 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20140423/b31f1cfe/attachment.html>

From lkarsten at varnish-software.com  Wed Apr 23 12:19:06 2014
From: lkarsten at varnish-software.com (Lasse Karstensen)
Date: Wed, 23 Apr 2014 14:19:06 +0200
Subject: Problems in the varnish-4.0.0 rpms
In-Reply-To: <1922094285.1341325.1398209258938.JavaMail.zimbra@redpill-linpro.com>
References: <498421803.1339692.1398207769054.JavaMail.zimbra@redpill-linpro.com>
 <1922094285.1341325.1398209258938.JavaMail.zimbra@redpill-linpro.com>
Message-ID: <20140423121905.GB3777@immer.varnish-software.com>

On Wed, Apr 23, 2014 at 01:27:38AM +0200, Ingvar Hagelund wrote:
> I should have reported this by trac, but it is down at the moment. 

Hi Ingvar.

Thanks for noticing and reporting this.

I've filed it in trac now:

    https://www.varnish-cache.org/trac/ticket/1484


-- 
Lasse Karstensen



From martin at varnish-software.com  Fri Apr 25 09:35:41 2014
From: martin at varnish-software.com (Martin Blix Grydeland)
Date: Fri, 25 Apr 2014 11:35:41 +0200
Subject: [PATCH 1/2] Remove negative Age assertion and truncate to zero
 instead.
Message-ID: <1398418542-28276-1-git-send-email-martin@varnish-software.com>

The Age reported on response objects is calculated from the last
request timestamp taken. For a cache hit that hasn't been on a
waitinglist, that will be the Start timestamp. This opens a race where
the requests' last timestamp could be before the objects t_origin.

Truncate the Age to zero rather than assert in that case.

Fixes: #1486
---
 bin/varnishd/cache/cache_req_fsm.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/bin/varnishd/cache/cache_req_fsm.c b/bin/varnishd/cache/cache_req_fsm.c
index 2518422..af5d76b 100644
--- a/bin/varnishd/cache/cache_req_fsm.c
+++ b/bin/varnishd/cache/cache_req_fsm.c
@@ -117,10 +117,15 @@ cnt_deliver(struct worker *wrk, struct req *req)
 	/* We base Age calculation upon the last timestamp taken during
 	   client request processing. This gives some inaccuracy, but
 	   since Age is only full second resolution that shouldn't
-	   matter. */
-	assert(req->t_prev > req->obj->exp.t_origin);
-	http_PrintfHeader(req->resp, "Age: %.0f",
-	    req->t_prev - req->obj->exp.t_origin);
+	   matter. (Last request timestamp could be a Start timestamp
+	   taken before the object entered into cache leading to negative
+	   age. Truncate to zero in that case).
+	*/
+	if (req->t_prev > req->obj->exp.t_origin)
+		http_PrintfHeader(req->resp, "Age: %.0f",
+		    req->t_prev - req->obj->exp.t_origin);
+	else
+		http_PrintfHeader(req->resp, "Age: %.0f", 0.);
 
 	http_SetHeader(req->resp, "Via: 1.1 varnish (v4)");
 
-- 
1.9.2




From martin at varnish-software.com  Fri Apr 25 09:35:42 2014
From: martin at varnish-software.com (Martin Blix Grydeland)
Date: Fri, 25 Apr 2014 11:35:42 +0200
Subject: [PATCH 2/2] Copy the status code, proto,
 status string and response message on backend IMS.
In-Reply-To: <1398418542-28276-1-git-send-email-martin@varnish-software.com>
References: <1398418542-28276-1-git-send-email-martin@varnish-software.com>
Message-ID: <1398418542-28276-2-git-send-email-martin@varnish-software.com>

When revalidating using backend IMS, copy the status code, status
code, status string and response message from the original object into
the new revalidated object. This makes sure that none of the 304
message fields gets applied to the new revalidated object.

This change also removes the forced 200 status of the revalidated
object, inheriting the status code of the original object instead.

Fixes: #1485
---
 bin/varnishd/cache/cache_fetch.c |  8 +++++++-
 bin/varnishtest/tests/r01485.vtc | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 bin/varnishtest/tests/r01485.vtc

diff --git a/bin/varnishd/cache/cache_fetch.c b/bin/varnishd/cache/cache_fetch.c
index 5a0a9ff..8603777 100644
--- a/bin/varnishd/cache/cache_fetch.c
+++ b/bin/varnishd/cache/cache_fetch.c
@@ -356,7 +356,13 @@ vbf_stp_startfetch(struct worker *wrk, struct busyobj *bo)
 	AZ(bo->do_esi);
 
 	if (bo->ims_obj != NULL && bo->beresp->status == 304) {
-		bo->beresp->status = 200;
+		http_SetH(bo->beresp, HTTP_HDR_PROTO,
+		    bo->ims_obj->http->hd[HTTP_HDR_PROTO].b);
+		bo->beresp->status = bo->ims_obj->http->status;
+		http_SetH(bo->beresp, HTTP_HDR_STATUS,
+		    bo->ims_obj->http->hd[HTTP_HDR_STATUS].b);
+		http_SetH(bo->beresp, HTTP_HDR_RESPONSE,
+		    bo->ims_obj->http->hd[HTTP_HDR_RESPONSE].b);
 		http_Merge(bo->ims_obj->http, bo->beresp,
 		    bo->ims_obj->changed_gzip);
 		do_ims = 1;
diff --git a/bin/varnishtest/tests/r01485.vtc b/bin/varnishtest/tests/r01485.vtc
new file mode 100644
index 0000000..caf267a
--- /dev/null
+++ b/bin/varnishtest/tests/r01485.vtc
@@ -0,0 +1,32 @@
+varnishtest "#1485: Wrong response reason phrase"
+
+server s1 {
+	rxreq
+	txresp -hdr "Etag: foo"
+
+	rxreq
+	expect req.http.If-None-Match == "foo"
+	txresp -status 304 -msg "Not Modified"
+} -start
+
+varnish v1 -vcl+backend {
+	sub vcl_backend_response {
+		set beresp.ttl = 1ms;
+		set beresp.grace = 0s;
+		set beresp.keep = 1h;
+	}
+} -start
+
+client c1 {
+	txreq
+	rxresp
+	expect resp.status == 200
+	expect resp.msg == "OK"
+
+	delay 0.1
+
+	txreq
+	rxresp
+	expect resp.status == 200
+	expect resp.msg == "OK"
+} -run
-- 
1.9.2




From jdzstz at gmail.com  Fri Apr 25 18:04:10 2014
From: jdzstz at gmail.com (jdzstz - gmail dot com)
Date: Fri, 25 Apr 2014 20:04:10 +0200
Subject: Updated varnish cygwin patches to 3.0.5 varnish version (32 and
 64 bits)
In-Reply-To: <35551.1398159442@critter.freebsd.dk>
References: <CA+wAnvwh7uU6BvxyD+aqD1pAx1rRWgYC7MZ8n-BagrdY-hKa_A@mail.gmail.com>
 <5355AD6A.5090108@gmail.com> <35551.1398159442@critter.freebsd.dk>
Message-ID: <CA+wAnvz7ATTZ4BB+JH2ppAodeVLf+t1HV4OM6bDfBxE4cZnXkw@mail.gmail.com>

Hello,

About your questions:

*1. Changes that fixes varnishtest problems (timeouts and path problems):*

I have detected that the execution of GCC for compilation of VCL is slower
than Linux and causes some problems (at least in my old laptop)

Last summer I changed to a new PC with SSD disk and more RAM but I have not
tried to execute varnishtest removing this timeout changes.

My idea is to try removing this changes values for Varnish 4.0.0 (I was
able to compile it but I have not check the varnishtest errors yet)

*2. Changes that fixes some problems with varnishd and tcp_nodelay
problems:*

It is a bug of cygwin, I have to write to cygwin developers, but I prefered
to make first a provisional fix for this issue:

  1.The getsockopt function at cygwin is documented  returns a INT value

  2.But the cygwin getsockopt function internally calls to windows
getsockopt, that has his own rules...

   -
   http://msdn.microsoft.com/en-us/library/windows/desktop/ms738544%28v=vs.85%29.aspx

  3. The problem is that windows returns a "boolean" size value. This
return value type causes trobles at following assert of varnish:

   - assert(l == sizeof tcp_nodelay);

Because *l* is INT size (sizeof tcp_nodelay before getsockopt call) and
*sizeof tcp_nodelay* is BOOL size

It seems that nobody had troubles before with this "tcp_nodelay", because
if you have a zeroed int variable and call to *getsockopt*, the windows
function returning BOOL only set first bits of int and everything works
fine, unless you do a comparion of sizeof of variables.

(I have also tried to leave the int variable and removing "assert" and it
also works fine)

My idea is to send the bug this following week to Cygwin Developers
Mailist. They should wrap windows response to avoid this issue.

It will be fine to remove my workaround for Varnish 4.0.0, but it depends
on Cygwin release times.

Regards,
Jorge D?az



2014-04-22 11:37 GMT+02:00 Poul-Henning Kamp <phk at phk.freebsd.dk>:

> In message <5355AD6A.5090108 at gmail.com>, jdzstz writes:
>
> >  - Changes that fixes varnishtest problems (timeouts and path
> >problems):
> https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_varnishtest.patch
>
> This patch kind of hint that Varnish at Cygwin must suck pretty
> badly performance wise ?  Is that because of the hardware you
> run it on, or is it chronic ?
>
> >  - Changes that fixes some problems with varnishd and tcp_nodelay
> problems:
> >
> https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.5-cygwin_varnishd.patch
>
> Where on Earth does the idea that TCP_NODELAY takes a bool argument
> come from ?  Are you sure about this ?
>
> Don't let the canonical decriptions mention about "The boolean option
> TCP_NODELAY [...]" confuse you:  It still takes an int argument any
> place I have ever seen it.
>
> If the Cygwin crew made it take a bool, they're portability-mororns.
>
> --
> 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-dev/attachments/20140425/2d3911f6/attachment.html>

From martin at varnish-software.com  Wed Apr 30 11:51:12 2014
From: martin at varnish-software.com (Martin Blix Grydeland)
Date: Wed, 30 Apr 2014 13:51:12 +0200
Subject: [PATCH] Remember to signal the thread to exit when decimating the
 flock
Message-ID: <1398858672-8534-1-git-send-email-martin@varnish-software.com>

The pool herder didn't signal the thread when decimating the flock,
causing the thread to be leaked.

Spotted by: xcir
Fixes: #1490

Also close a couple of other races:

When pthread_cond_timedwait returns ETIMEDOUT, the predicate
(wrk->task.func == NULL) could still have changed while reacquiring
the mutex. If so, the signal would've been lost and the thread
leaked. Changed the idle wait loop in Pool_Work_Thread() to always
check the predicate before resuming the cond_wait.

The update of the predicate (wrk->task.func) from e.g. Pool_Task() is
done without holding the mutex. This opens a race on the predicate,
and the possibility of the worker going back on cond_wait loosing the
signal. Changed to update the predicate while holding the mutex.
---
 bin/varnishd/cache/cache_pool.c  | 31 +++++++++++++++++++++----------
 bin/varnishtest/tests/r01490.vtc | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+), 10 deletions(-)
 create mode 100644 bin/varnishtest/tests/r01490.vtc

diff --git a/bin/varnishd/cache/cache_pool.c b/bin/varnishd/cache/cache_pool.c
index 75fac47..fbfb993 100644
--- a/bin/varnishd/cache/cache_pool.c
+++ b/bin/varnishd/cache/cache_pool.c
@@ -163,12 +163,12 @@ pool_accept(struct worker *wrk, void *arg)
 		}
 		VTAILQ_REMOVE(&pp->idle_queue, &wrk2->task, list);
 		AZ(wrk2->task.func);
-		Lck_Unlock(&pp->mtx);
 		assert(sizeof *wa2 == WS_Reserve(wrk2->aws, sizeof *wa2));
 		wa2 = (void*)wrk2->aws->f;
 		memcpy(wa2, wa, sizeof *wa);
 		wrk2->task.func = SES_pool_accept_task;
 		wrk2->task.priv = pp->sesspool;
+		Lck_Unlock(&pp->mtx);
 		AZ(pthread_cond_signal(&wrk2->cond));
 
 		/*
@@ -204,9 +204,9 @@ Pool_Task(struct pool *pp, struct pool_task *task, enum pool_how how)
 	if (wrk != NULL) {
 		VTAILQ_REMOVE(&pp->idle_queue, &wrk->task, list);
 		AZ(wrk->task.func);
-		Lck_Unlock(&pp->mtx);
 		wrk->task.func = task->func;
 		wrk->task.priv = task->priv;
+		Lck_Unlock(&pp->mtx);
 		AZ(pthread_cond_signal(&wrk->cond));
 		return (0);
 	}
@@ -237,6 +237,17 @@ Pool_Task(struct pool *pp, struct pool_task *task, enum pool_how how)
 }
 
 /*--------------------------------------------------------------------
+ * Empty function used as a pointer value for the thread exit condition.
+ */
+
+static void
+pool_kiss_of_death(struct worker *wrk, void *priv)
+{
+	(void)wrk;
+	(void)priv;
+}
+
+/*--------------------------------------------------------------------
  * This is the work function for worker threads in the pool.
  */
 
@@ -274,7 +285,6 @@ Pool_Work_Thread(void *priv, struct worker *wrk)
 				wrk->lastused = VTIM_real();
 			wrk->task.func = NULL;
 			wrk->task.priv = wrk;
-			AZ(wrk->task.func);
 			VTAILQ_INSERT_HEAD(&pp->idle_queue, &wrk->task, list);
 			if (!stats_clean)
 				WRK_SumStat(wrk);
@@ -283,12 +293,12 @@ Pool_Work_Thread(void *priv, struct worker *wrk)
 				    wrk->vcl == NULL ?  0 : wrk->lastused+60.);
 				if (i == ETIMEDOUT)
 					VCL_Rel(&wrk->vcl);
-			} while (i);
+			} while (wrk->task.func == NULL);
 			tp = &wrk->task;
 		}
 		Lck_Unlock(&pp->mtx);
 
-		if (tp->func == NULL)
+		if (tp->func == pool_kiss_of_death)
 			break;
 
 		assert(wrk->pool == pp);
@@ -387,23 +397,24 @@ pool_herder(void *priv)
 				CAST_OBJ_NOTNULL(wrk, pt->priv, WORKER_MAGIC);
 
 				if (wrk->lastused < t_idle ||
-				    pp->nthr > cache_param->wthread_max)
+				    pp->nthr > cache_param->wthread_max) {
+					/* Give it a kiss on the cheek... */
 					VTAILQ_REMOVE(&pp->idle_queue,
 					    &wrk->task, list);
-				else
+					wrk->task.func = pool_kiss_of_death;
+					AZ(pthread_cond_signal(&wrk->cond));
+				} else
 					wrk = NULL;
 			}
 			Lck_Unlock(&pp->mtx);
 
-			/* And give it a kiss on the cheek... */
 			if (wrk != NULL) {
+				/* Update counters */
 				pp->nthr--;
 				Lck_Lock(&pool_mtx);
 				VSC_C_main->threads--;
 				VSC_C_main->threads_destroyed++;
 				Lck_Unlock(&pool_mtx);
-				wrk->task.func = NULL;
-				wrk->task.priv = NULL;
 				VTIM_sleep(cache_param->wthread_destroy_delay);
 				continue;
 			}
diff --git a/bin/varnishtest/tests/r01490.vtc b/bin/varnishtest/tests/r01490.vtc
new file mode 100644
index 0000000..82ffdb4
--- /dev/null
+++ b/bin/varnishtest/tests/r01490.vtc
@@ -0,0 +1,38 @@
+varnishtest "#1490 - thread destruction"
+
+server s1 {
+} -start
+
+varnish v1 \
+	-arg "-p debug=+syncvsl" \
+	-arg "-p vsl_mask=+WorkThread" \
+	-arg "-p thread_pool_min=2" \
+	-arg "-p thread_pool_max=3" \
+	-arg "-p thread_pools=1" \
+	-vcl+backend {}
+varnish v1 -start
+
+varnish v1 -expect threads == 2
+
+logexpect l1 -v v1 -g raw {
+	expect * 0 WorkThread {^\S+ start$}
+	expect * 0 WorkThread {^\S+ end$}
+} -start
+
+varnish v1 -cliok "param.set thread_pool_min 3"
+
+# Herder thread sleeps 5 seconds. Have to wait longer than that.
+delay 6
+
+varnish v1 -expect threads == 3
+
+varnish v1 -cliok "param.set thread_pool_min 2"
+varnish v1 -cliok "param.set thread_pool_max 2"
+
+# Herder thread sleeps 5 seconds. Have to wait longer than that.
+delay 6
+
+varnish v1 -expect threads == 2
+
+# Use logexpect to see that the thread actually exited
+logexpect l1 -wait
-- 
1.9.2