From peterjanovsky at yahoo.com  Mon May 10 20:31:32 2010
From: peterjanovsky at yahoo.com (Peter Janovsky)
Date: Mon, 10 May 2010 13:31:32 -0700 (PDT)
Subject: chunked transfer encoding
Message-ID: <762129.15939.qm@web51904.mail.re2.yahoo.com>

i've noticed there has been talk surrounding chunked transfer encoding in the response.  does varnish 2.1.2 support chunked transfers from the backend to the client?  if it doesn't is there a workaround for the issue?

thnx - peter


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

From phk at phk.freebsd.dk  Mon May 10 20:39:42 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 10 May 2010 20:39:42 +0000
Subject: chunked transfer encoding 
In-Reply-To: Your message of "Mon, 10 May 2010 13:31:32 MST."
	<762129.15939.qm@web51904.mail.re2.yahoo.com> 
Message-ID: <64794.1273523982@critter.freebsd.dk>

In message <762129.15939.qm at web51904.mail.re2.yahoo.com>, Peter Janovsky writes
:

>i've noticed there has been talk surrounding chunked transfer encoding in the response.  does varnish 2.1.2 support chunked transfers from the backend to the client?  if it doesn't is there a workaround for the issue?

All varnish versions have supported that.

2.1.1 had a bug in the handling of 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 peterjanovsky at yahoo.com  Mon May 10 22:14:29 2010
From: peterjanovsky at yahoo.com (Peter Janovsky)
Date: Mon, 10 May 2010 15:14:29 -0700 (PDT)
Subject: chunked transfer encoding
In-Reply-To: <64794.1273523982@critter.freebsd.dk>
References: <64794.1273523982@critter.freebsd.dk>
Message-ID: <97924.57505.qm@web51902.mail.re2.yahoo.com>

thnx poul, i must have read the documentation wrong. for my clarificaiton, if the backend specifies "Transfer-Encoding: chunked" and we are caching the file within varnish, varnish will send chunk the response to the client while simultaneously caching the file?

peter



________________________________
From: Poul-Henning Kamp <phk at phk.freebsd.dk>
To: Peter Janovsky <peterjanovsky at yahoo.com>
Cc: Varnish Development <varnish-dev at varnish-cache.org>
Sent: Mon, May 10, 2010 4:39:42 PM
Subject: Re: chunked transfer encoding 

In message <762129.15939.qm at web51904.mail.re2.yahoo.com>, Peter Janovsky writes
:

>i've noticed there has been talk surrounding chunked transfer encoding in the response.  does varnish 2.1.2 support chunked transfers from the backend to the client?  if it doesn't is there a workaround for the issue?

All varnish versions have supported that.

2.1.1 had a bug in the handling of 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.



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

From phk at phk.freebsd.dk  Tue May 11 09:40:54 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 11 May 2010 09:40:54 +0000
Subject: chunked transfer encoding 
In-Reply-To: Your message of "Mon, 10 May 2010 15:14:29 MST."
	<97924.57505.qm@web51902.mail.re2.yahoo.com> 
Message-ID: <80708.1273570854@critter.freebsd.dk>

In message <97924.57505.qm at web51902.mail.re2.yahoo.com>, Peter Janovsky writes:

>thnx poul, i must have read the documentation wrong. for my
>clarificaiton, if the backend specifies "Transfer-Encoding: chunked"
>and we are caching the file within varnish, varnish will send chunk
>the response to the client while simultaneously caching the file?

No, Varnish will receive the entire object from the backend, then
sind it with Content-Length to the client.

-- 
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  Thu May 13 13:10:13 2010
From: slink at schokola.de (Nils Goroll)
Date: Thu, 13 May 2010 15:10:13 +0200
Subject: Contributions...
Message-ID: <4BEBFA35.7080305@schokola.de>

Hi,

over the last couple of months I've opened some tickets with suggested
fixes/improvements which haven't caught attention (yet).

I there anything more I could do to help or should I rather just remain quiet
and patient, which I will happily do?

Thanks, Nils



From phk at phk.freebsd.dk  Thu May 13 18:17:34 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 13 May 2010 18:17:34 +0000
Subject: Contributions... 
In-Reply-To: Your message of "Thu, 13 May 2010 15:10:13 +0200."
	<4BEBFA35.7080305@schokola.de> 
Message-ID: <2319.1273774654@critter.freebsd.dk>

In message <4BEBFA35.7080305 at schokola.de>, Nils Goroll writes:

>over the last couple of months I've opened some tickets with suggested
>fixes/improvements which haven't caught attention (yet).

Solaris is sort of a "tier-2" platform for us right now, partly because
we lack solaris machines and mostly because we lack time.

>I there anything more I could do to help or should I rather just remain quiet
>and patient, which I will happily do?

Please be patient :-)

None of this stuff is lost or rejected, I just havn't gotten to it yet.

-- 
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  Thu May 13 18:59:21 2010
From: slink at schokola.de (Nils Goroll)
Date: Thu, 13 May 2010 20:59:21 +0200
Subject: Contributions...
In-Reply-To: <2319.1273774654@critter.freebsd.dk>
References: <2319.1273774654@critter.freebsd.dk>
Message-ID: <4BEC4C09.8010002@schokola.de>

Hi Poul-Henning,

>> over the last couple of months I've opened some tickets with suggested
>> fixes/improvements which haven't caught attention (yet).
> 
> Solaris is sort of a "tier-2" platform for us right now, partly because
> we lack solaris machines and mostly because we lack time.

That's alright - and probably a motivation for others and myself to get involved.

>> I there anything more I could do to help or should I rather just remain quiet
>> and patient, which I will happily do?
> 
> Please be patient :-)
> 
> None of this stuff is lost or rejected, I just havn't gotten to it yet.

Thanks for your feedback.

Nils



From perbu at varnish-software.com  Thu May 13 21:29:18 2010
From: perbu at varnish-software.com (Per Buer)
Date: Thu, 13 May 2010 23:29:18 +0200
Subject: Contributions...
In-Reply-To: <2319.1273774654@critter.freebsd.dk>
References: <4BEBFA35.7080305@schokola.de> <2319.1273774654@critter.freebsd.dk>
Message-ID: <AANLkTilupV4xLqAjb3rUEiWM1R2JkpYj5CTb6CjLhAwW@mail.gmail.com>

On Thu, May 13, 2010 at 8:17 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <4BEBFA35.7080305 at schokola.de>, Nils Goroll writes:
>
>>over the last couple of months I've opened some tickets with suggested
>>fixes/improvements which haven't caught attention (yet).
>
> Solaris is sort of a "tier-2" platform for us right now, partly because
> we lack solaris machines and mostly because we lack time.

Actually the Solaris machine is installed. It just need to get
installed in the server center. It should show up by the end of next
week.

-- 
Per Buer,  Varnish Software
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer



From tfheen at varnish-software.com  Fri May 14 14:46:34 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Fri, 14 May 2010 16:46:34 +0200
Subject: log action in VCL
Message-ID: <87bpcia6d1.fsf@qurzaw.linpro.no>


Hi,

We've talked about having a ?log? action in VCL for the longest time,
so I implemented it.  Patch attached.  I'm not entirely happy about the
name of the shmlog tag, but I can live with VCL_Log.

Comments/ok to commit?

Patch attached.

-- 
Tollef Fog Heen
Varnish Software
t: +47 21 54 41 73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcl_log.diff
Type: text/x-diff
Size: 2342 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100514/9d5c2b35/attachment.bin>

From phk at phk.freebsd.dk  Sat May 15 10:51:22 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 15 May 2010 10:51:22 +0000
Subject: log action in VCL 
In-Reply-To: Your message of "Fri, 14 May 2010 16:46:34 +0200."
	<87bpcia6d1.fsf@qurzaw.linpro.no> 
Message-ID: <15221.1273920682@critter.freebsd.dk>

In message <87bpcia6d1.fsf at qurzaw.linpro.no>, Tollef Fog Heen writes:

>We've talked about having a =C2?log=C2? action in VCL for the longest time,
>so I implemented it.  Patch attached.  I'm not entirely happy about the
>name of the shmlog tag, but I can live with VCL_Log.

I think VCL_Log is pretty OK for a name, I certainly cannot come up with
a better one right now.

The patch looks OK.

One of the reasons I have not done this myself yet, is that I would
like to have the log message contain a back-vector to the source,
but have not found a good way of doing that.

It is already possible to have more than one VCL in play at the
same time, and it may become even more so soonish, and since
the VCL_Log is very likely to be used for debugging, I really
hate the scenario where log messages from one VCL version confuses
people working on a newer one.

The absolute coords of a VCL source token is presently <vcl_name,
src_file, line, char> which is far too verbose for my taste.

We could add a log-record per request, that tells which VCL this
is being processed by, that would eliminate the first element of
the set, leaving only a numeric triplet for the ID.

Thoughts welcome...

-- 
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  Tue May 18 08:12:58 2010
From: slink at schokola.de (Nils Goroll)
Date: Tue, 18 May 2010 10:12:58 +0200
Subject: Memory barriers
Message-ID: <4BF24C0A.40508@schokola.de>

Hi Poul-Henning and All,

i noticed this:

http://varnish-cache.org/changeset/4796

Once you're at it, it would appear to me that adding differentiated macros for
load/store/both (AMD64: lfence/sfence/mfence) or even more specific macros was a
good idea.

http://markmail.org/message/fzzgebam4bwhfiv3

Solaris has membar_consumer_producer for load/store and membar_enter/exit for
the general case:

http://docs.sun.com/app/docs/doc/816-5168/membar-producer-3c?a=view

While membar_enter and exit are the same on AMD64, they are not on SPARC and
probably other RISC:

http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sparc/v9/ml/lock_prim.s#117
http://developers.sun.com/solaris/articles/atomic_sparc/#MEMBARinstruction

Apologies if this just bores you, it was just that the commit had triggered my
personal interest and I'm simply sharing what appeared relevant to me.

Nils



From phk at phk.freebsd.dk  Tue May 18 08:17:23 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 18 May 2010 08:17:23 +0000
Subject: Memory barriers 
In-Reply-To: Your message of "Tue, 18 May 2010 10:12:58 +0200."
	<4BF24C0A.40508@schokola.de> 
Message-ID: <15639.1274170643@critter.freebsd.dk>

In message <4BF24C0A.40508 at schokola.de>, Nils Goroll writes:

>http://varnish-cache.org/changeset/4796
>
>Once you're at it, it would appear to me that adding differentiated macros for
>load/store/both (AMD64: lfence/sfence/mfence) or even more specific macros was >a good idea.

Only if I need them.

The membars I need are (until now) only for store order since the data 
structures in question are internally consistent with the right store order.

This stuff is still experimental any way, so I'm not making any
firm decisions yet.

-- 
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 May 19 19:30:17 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 19 May 2010 19:30:17 +0000
Subject: Memory barriers 
In-Reply-To: Your message of "Tue, 18 May 2010 08:17:23 GMT."
	<15639.1274170643@critter.freebsd.dk> 
Message-ID: <117.1274297417@critter.freebsd.dk>

In message <15639.1274170643 at critter.freebsd.dk>, "Poul-Henning Kamp" writes:
>In message <4BF24C0A.40508 at schokola.de>, Nils Goroll writes:
>
>>http://varnish-cache.org/changeset/4796
>>
>>Once you're at it, it would appear to me that adding differentiated macros for
>>load/store/both (AMD64: lfence/sfence/mfence) or even more specific macros was >a good idea.
>
>Only if I need them.

Ok, I just found out that Linux does not expose the various membar
macros to userland (there is a proposal for a syscall to do it ??)
So I bit the bullet and add the VMB VTLA and put a pthread-compat
version in it, since that will be cheaper than a syscall on any OS
with a decent pthread implementation.

Poul-Henning

PS: Please hand me the ability to edit POSIX standards unhindered for
just one day, and the world will be a better place, I promise...

-- 
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 h.skwirblies at schottenland.de  Fri May 28 09:30:44 2010
From: h.skwirblies at schottenland.de (Hajo Skwirblies)
Date: Fri, 28 May 2010 11:30:44 +0200
Subject: Plans for -s persistent and Parent restarts
Message-ID: <4BFF8D44.5000900@schottenland.de>

Hello Varnish Developers,

I learned from a discussion in January 
(http://www.gossamer-threads.com/lists/varnish/misc/13727) that a 
persistent silo is not (yet) intended to survive a parent restart.

I tried versions 2.1, 2.1.2 and r4859 from svn: Always the cached 
objects survive a child restart but do not survive the parent 
restarting. Did I miss something in my configuration or is this behavior 
intended and I misunderstand the meaning of persistence in varnish?


Mit freundlichen Gr??en
Best Regards

Hajo Skwirblies



From phk at phk.freebsd.dk  Fri May 28 09:34:01 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 28 May 2010 09:34:01 +0000
Subject: Plans for -s persistent and Parent restarts 
In-Reply-To: Your message of "Fri, 28 May 2010 11:30:44 +0200."
	<4BFF8D44.5000900@schottenland.de> 
Message-ID: <27724.1275039241@critter.freebsd.dk>

In message <4BFF8D44.5000900 at schottenland.de>, Hajo Skwirblies writes:

>I tried versions 2.1, 2.1.2 and r4859 from svn: Always the cached 
>objects survive a child restart but do not survive the parent 
>restarting. Did I miss something in my configuration or is this behavior 
>intended and I misunderstand the meaning of persistence in varnish?

Which -spersistent argument did you use ?

-- 
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 h.skwirblies at schottenland.de  Fri May 28 11:05:39 2010
From: h.skwirblies at schottenland.de (Hajo Skwirblies)
Date: Fri, 28 May 2010 13:05:39 +0200
Subject: Plans for -s persistent and Parent restarts
In-Reply-To: <27724.1275039241@critter.freebsd.dk>
References: <27724.1275039241@critter.freebsd.dk>
Message-ID: <4BFFA383.70104@schottenland.de>

Here is my start Command:

sbin/varnishd -n /opt/varnish \
	-s persistent,/home/www/cache/silo1,256M \
	-s persistent,/home/www/cache/silo2,256M \
	-h classic,500009 \
	-f etc/config.vcl \


config.vcl basically proxies everything it gets for certain domains to 
their designated backends, strips cookies and cache control headers from 
images and sets their beresp.ttl to 86400 in vcl_fetch.

Mit freundlichen Gr??en
Best Regards

Hajo Skwirblies



From jdzstz at gmail.com  Mon May 31 10:52:52 2010
From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=)
Date: Mon, 31 May 2010 12:52:52 +0200
Subject: Varnish LINGER crash on Solaris (Ticket #649)
Message-ID: <AANLkTik-i3Kh45hQTP4zVYzw50Kz2zGvT8xWdpYQS--q@mail.gmail.com>

Hello,

I am testing Varnish (r4576 <http://varnish-cache.org/changeset/4576>) in
Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000.
We are planning to use a cache like Varnish or Squid and I have followed the
instructions in
http://letsgetdugg.com/2009/12/04/varnish-on-solaris/<http://letsgetdugg.com/2009/12/04/varnish-on-solaris/>
I have the same LINGER crash like in
#660<http://varnish-cache.org/ticket/660>that has the same root cause
in
#649 <http://varnish-cache.org/ticket/649>

I have trying to fix the bug and I have found *the problem is that solaris
setsockopt returns sometimes EINVAL* when it is no invalid parameters,
problem found in Java JVM in Solaris:
*  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870>
*
http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464<http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464>

I think the solution is to changed the definition of "TCP_Check" in *
libvarnish.h* only for Solaris*

/* In Solaris OS, errno == EINVAL is OK because setsockopt(3SOCKET) call
returns EINVAL when the connection is reset. */
#if defined (__SVR4) && defined (__sun)
#define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN
|| errno == EINVAL)
#else
#define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN)
#endif

Do you think it is ok to commit it to trunk ?

Thank you
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100531/b5e49f47/attachment.html>

From phk at phk.freebsd.dk  Mon May 31 11:09:43 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 31 May 2010 11:09:43 +0000
Subject: Varnish LINGER crash on Solaris (Ticket #649) 
In-Reply-To: Your message of "Mon, 31 May 2010 12:52:52 +0200."
	<AANLkTik-i3Kh45hQTP4zVYzw50Kz2zGvT8xWdpYQS--q@mail.gmail.com> 
Message-ID: <66718.1275304183@critter.freebsd.dk>


Can I get you to open a ticket with this text in it, so we have
a record of why we are doing this ?

Poul-Henning

In message <AANLkTik-i3Kh45hQTP4zVYzw50Kz2zGvT8xWdpYQS--q at mail.gmail.com>, =?IS
O-8859-1?Q?Jorge_D=EDaz?= writes:
>--===============8061307876579297173==
>Content-Type: multipart/alternative; boundary=0016e659f6d29162560487e1a818
>
>--0016e659f6d29162560487e1a818
>Content-Type: text/plain; charset=ISO-8859-1
>
>Hello,
>
>I am testing Varnish (r4576 <http://varnish-cache.org/changeset/4576>) in
>Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000.
>We are planning to use a cache like Varnish or Squid and I have followed the
>instructions in
>http://letsgetdugg.com/2009/12/04/varnish-on-solaris/<http://letsgetdugg.com/2009/12/04/varnish-on-solaris/>
>I have the same LINGER crash like in
>#660<http://varnish-cache.org/ticket/660>that has the same root cause
>in
>#649 <http://varnish-cache.org/ticket/649>
>
>I have trying to fix the bug and I have found *the problem is that solaris
>setsockopt returns sometimes EINVAL* when it is no invalid parameters,
>problem found in Java JVM in Solaris:
>*  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870>
>*
>http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464<http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464>
>
>I think the solution is to changed the definition of "TCP_Check" in *
>libvarnish.h* only for Solaris*
>
>/* In Solaris OS, errno == EINVAL is OK because setsockopt(3SOCKET) call
>returns EINVAL when the connection is reset. */
>#if defined (__SVR4) && defined (__sun)
>#define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN
>|| errno == EINVAL)
>#else
>#define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN)
>#endif
>
>Do you think it is ok to commit it to trunk ?
>
>Thank you
>*
>
>--0016e659f6d29162560487e1a818
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>Hello,<br><br><p>
>I am testing Varnish (<a class=3D"changeset" href=3D"http://varnish-cache.o=
>rg/changeset/4576" title=3D"Tell FlexeLint=20
>that we ignore returnvalues on purpose.">r4576</a>) in Solaris 10 5.10=20
>Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000. <br>
>We are planning to use a cache like Varnish or Squid and I have followed
> the instructions in <a class=3D"ext-link" href=3D"http://letsgetdugg.com/2=
>009/12/04/varnish-on-solaris/"><span class=3D"icon">=A0</span>http://letsge=
>tdugg.com/2009/12/04/varnish-on-solaris/</a>
></p>
>
>I have the same LINGER crash like in <a class=3D"closed ticket" href=3D"htt=
>p://varnish-cache.org/ticket/660" title=3D"defect: Varnish LINGER
> crash in tcp.c (closed: duplicate)">#660</a> that has the same root=20
>cause in <a class=3D"new ticket" href=3D"http://varnish-cache.org/ticket/64=
>9" title=3D"defect: Varnish LINGER
> crash on Solaris (new)">#649</a> <br><br>I have trying to fix the bug and =
>I have found <strong>the problem is=20
>that solaris setsockopt returns sometimes EINVAL</strong> when it is no=20
>invalid parameters, problem found in Java JVM in Solaris:<br>
>* <a class=3D"ext-link" href=3D"http://bugs.sun.com/bugdatabase/view_bug.do=
>?bug_id=3D6378870"><span class=3D"icon">=A0</span>http://bugs.sun.com/bugda=
>tabase/view_bug.do?bug_id=3D6378870</a>
>  <br>
>* <a class=3D"ext-link" href=3D"http://bugs.opensolaris.org/bugdatabase/vie=
>w_bug.do;jsessionid=3D7141b1811572e415779f4a711a96?bug_id=3D6850464"><span =
>class=3D"icon">=A0</span>http://bugs.opensolaris.org/bugdatabase/view_bug.d=
>o;jsessionid=3D7141b1811572e415779f4a711a96?bug_id=3D6850464</a>
><br><br>I think the solution is to changed the definition of &quot;TCP_Chec=
>k&quot; in <b>libvarnish.h</b> only for Solaris<strong><br><br><span style=
>=3D"font-family: courier new,monospace;">/* In Solaris OS, errno =3D=3D EIN=
>VAL is OK because setsockopt(3SOCKET) call returns EINVAL when the connecti=
>on is reset. */</span><br style=3D"font-family: courier new,monospace;">
><span style=3D"font-family: courier new,monospace;">#if defined (__SVR4) &a=
>mp;&amp; defined (__sun) </span><br style=3D"font-family: courier new,monos=
>pace;"><span style=3D"font-family: courier new,monospace;">#define TCP_Chec=
>k(a) ((a) =3D=3D 0 || errno =3D=3D ECONNRESET || errno =3D=3D ENOTCONN || e=
>rrno =3D=3D EINVAL)</span><br style=3D"font-family: courier new,monospace;"=
>>
><span style=3D"font-family: courier new,monospace;">#else</span><br style=
>=3D"font-family: courier new,monospace;"><span style=3D"font-family: courie=
>r new,monospace;">#define TCP_Check(a) ((a) =3D=3D 0 || errno =3D=3D ECONNR=
>ESET || errno =3D=3D ENOTCONN)</span><br style=3D"font-family: courier new,=
>monospace;">
><span style=3D"font-family: courier new,monospace;">#endif</span><br style=
>=3D"font-family: courier new,monospace;"><br><span style=3D"font-weight: no=
>rmal;">Do you think it is ok to commit it to trunk ?<br><br>Thank you<br></=
>span></strong>
>
>--0016e659f6d29162560487e1a818--
>
>
>--===============8061307876579297173==
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>_______________________________________________
>varnish-dev mailing list
>varnish-dev at varnish-cache.org
>http://lists.varnish-cache.org/mailman/listinfo/varnish-dev
>--===============8061307876579297173==--
>

-- 
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 jdzstz at gmail.com  Mon May 31 11:21:28 2010
From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=)
Date: Mon, 31 May 2010 13:21:28 +0200
Subject: Varnish LINGER crash on Solaris (Ticket #649)
In-Reply-To: <66718.1275304183@critter.freebsd.dk>
References: <AANLkTik-i3Kh45hQTP4zVYzw50Kz2zGvT8xWdpYQS--q@mail.gmail.com>
	<66718.1275304183@critter.freebsd.dk>
Message-ID: <AANLkTikj1VDhe72GwsTzkOpbwRHAuG0OP360PqVP5AoM@mail.gmail.com>

The ticket exists:

http://varnish-cache.org/ticket/649

I need somebody to test it in linux, only check that it compiles OK.

I am new to Varnish, ?everybody can commit changes to trunk? or only admin
users?

Thanks


2010/5/31 Poul-Henning Kamp <phk at phk.freebsd.dk>

>
> Can I get you to open a ticket with this text in it, so we have
> a record of why we are doing this ?
>
> Poul-Henning
>
> In message <AANLkTik-i3Kh45hQTP4zVYzw50Kz2zGvT8xWdpYQS--q at mail.gmail.com>,
> =?IS
> O-8859-1?Q?Jorge_D=EDaz?= writes:
> >--===============8061307876579297173==
> >Content-Type: multipart/alternative; boundary=0016e659f6d29162560487e1a818
> >
> >--0016e659f6d29162560487e1a818
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >Hello,
> >
> >I am testing Varnish (r4576 <http://varnish-cache.org/changeset/4576>) in
> >Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000.
> >We are planning to use a cache like Varnish or Squid and I have followed
> the
> >instructions in
> >http://letsgetdugg.com/2009/12/04/varnish-on-solaris/<
> http://letsgetdugg.com/2009/12/04/varnish-on-solaris/>
> >I have the same LINGER crash like in
> >#660<http://varnish-cache.org/ticket/660>that has the same root cause
> >in
> >#649 <http://varnish-cache.org/ticket/649>
> >
> >I have trying to fix the bug and I have found *the problem is that solaris
> >setsockopt returns sometimes EINVAL* when it is no invalid parameters,
> >problem found in Java JVM in Solaris:
> >*  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870<
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378870>
> >*
> >
> http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464
> <
> http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=7141b1811572e415779f4a711a96?bug_id=6850464
> >
> >
> >I think the solution is to changed the definition of "TCP_Check" in *
> >libvarnish.h* only for Solaris*
> >
> >/* In Solaris OS, errno == EINVAL is OK because setsockopt(3SOCKET) call
> >returns EINVAL when the connection is reset. */
> >#if defined (__SVR4) && defined (__sun)
> >#define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno == ENOTCONN
> >|| errno == EINVAL)
> >#else
> >#define TCP_Check(a) ((a) == 0 || errno == ECONNRESET || errno ==
> ENOTCONN)
> >#endif
> >
> >Do you think it is ok to commit it to trunk ?
> >
> >Thank you
> >*
> >
> >--0016e659f6d29162560487e1a818
> >Content-Type: text/html; charset=ISO-8859-1
> >Content-Transfer-Encoding: quoted-printable
> >
> >Hello,<br><br><p>
> >I am testing Varnish (<a class=3D"changeset" href=3D"
> http://varnish-cache.o=
> >rg/changeset/4576" title=3D"Tell FlexeLint=20
> >that we ignore returnvalues on purpose.">r4576</a>) in Solaris 10 5.10=20
> >Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000. <br>
> >We are planning to use a cache like Varnish or Squid and I have followed
> > the instructions in <a class=3D"ext-link" href=3D"
> http://letsgetdugg.com/2=
> >009/12/04/varnish-on-solaris/"><span class=3D"icon">=A0</span>
> http://letsge=
> >tdugg.com/2009/12/04/varnish-on-solaris/</a>
> ></p>
> >
> >I have the same LINGER crash like in <a class=3D"closed ticket"
> href=3D"htt=
> >p://varnish-cache.org/ticket/660" title=3D"defect: Varnish LINGER
> > crash in tcp.c (closed: duplicate)">#660</a> that has the same root=20
> >cause in <a class=3D"new ticket" href=3D"
> http://varnish-cache.org/ticket/64=
> >9" title=3D"defect: Varnish LINGER
> > crash on Solaris (new)">#649</a> <br><br>I have trying to fix the bug and
> =
> >I have found <strong>the problem is=20
> >that solaris setsockopt returns sometimes EINVAL</strong> when it is no=20
> >invalid parameters, problem found in Java JVM in Solaris:<br>
> >* <a class=3D"ext-link" href=3D"
> http://bugs.sun.com/bugdatabase/view_bug.do=
> >?bug_id=3D6378870"><span class=3D"icon">=A0</span>
> http://bugs.sun.com/bugda=
> >tabase/view_bug.do?bug_id=3D6378870</a>
> >  <br>
> >* <a class=3D"ext-link" href=3D"
> http://bugs.opensolaris.org/bugdatabase/vie=
> >w_bug.do;jsessionid=3D7141b1811572e415779f4a711a96?bug_id=3D6850464"><span
> =
> >class=3D"icon">=A0</span>
> http://bugs.opensolaris.org/bugdatabase/view_bug.d=
> >o;jsessionid=3D7141b1811572e415779f4a711a96?bug_id=3D6850464</a>
> ><br><br>I think the solution is to changed the definition of
> &quot;TCP_Chec=
> >k&quot; in <b>libvarnish.h</b> only for Solaris<strong><br><br><span
> style=
> >=3D"font-family: courier new,monospace;">/* In Solaris OS, errno =3D=3D
> EIN=
> >VAL is OK because setsockopt(3SOCKET) call returns EINVAL when the
> connecti=
> >on is reset. */</span><br style=3D"font-family: courier new,monospace;">
> ><span style=3D"font-family: courier new,monospace;">#if defined (__SVR4)
> &a=
> >mp;&amp; defined (__sun) </span><br style=3D"font-family: courier
> new,monos=
> >pace;"><span style=3D"font-family: courier new,monospace;">#define
> TCP_Chec=
> >k(a) ((a) =3D=3D 0 || errno =3D=3D ECONNRESET || errno =3D=3D ENOTCONN ||
> e=
> >rrno =3D=3D EINVAL)</span><br style=3D"font-family: courier
> new,monospace;"=
> >>
> ><span style=3D"font-family: courier new,monospace;">#else</span><br style=
> >=3D"font-family: courier new,monospace;"><span style=3D"font-family:
> courie=
> >r new,monospace;">#define TCP_Check(a) ((a) =3D=3D 0 || errno =3D=3D
> ECONNR=
> >ESET || errno =3D=3D ENOTCONN)</span><br style=3D"font-family: courier
> new,=
> >monospace;">
> ><span style=3D"font-family: courier new,monospace;">#endif</span><br
> style=
> >=3D"font-family: courier new,monospace;"><br><span style=3D"font-weight:
> no=
> >rmal;">Do you think it is ok to commit it to trunk ?<br><br>Thank
> you<br></=
> >span></strong>
> >
> >--0016e659f6d29162560487e1a818--
> >
> >
> >--===============8061307876579297173==
> >Content-Type: text/plain; charset="us-ascii"
> >MIME-Version: 1.0
> >Content-Transfer-Encoding: 7bit
> >Content-Disposition: inline
> >
> >_______________________________________________
> >varnish-dev mailing list
> >varnish-dev at varnish-cache.org
> >http://lists.varnish-cache.org/mailman/listinfo/varnish-dev
> >--===============8061307876579297173==--
> >
>
> --
> 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/20100531/c4000acf/attachment.html>

From phk at phk.freebsd.dk  Mon May 31 11:32:56 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 31 May 2010 11:32:56 +0000
Subject: Varnish LINGER crash on Solaris (Ticket #649) 
In-Reply-To: Your message of "Mon, 31 May 2010 13:21:28 +0200."
	<AANLkTikj1VDhe72GwsTzkOpbwRHAuG0OP360PqVP5AoM@mail.gmail.com> 
Message-ID: <80386.1275305576@critter.freebsd.dk>

In message <AANLkTikj1VDhe72GwsTzkOpbwRHAuG0OP360PqVP5AoM at mail.gmail.com>, =?IS
O-8859-1?Q?Jorge_D=EDaz?= writes:

>http://varnish-cache.org/ticket/649

Sorry, my misunderstanding.

I have committed a more comprehensive fix in r4868.

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  Mon May 31 13:10:07 2010
From: perbu at varnish-software.com (Per Buer)
Date: Mon, 31 May 2010 15:10:07 +0200
Subject: docs: getting rid of the troff pages.
Message-ID: <AANLkTikZfvhjlzqwNakLO1-axQXqnE5P8Z-zlT4rijzm@mail.gmail.com>

Hi.

Work continues on the documentation. Anders Berg has written the
installation guide and I've written a tutorial. They are both expected
to be more or less complete within a week or two (it's open to debate
whether or not the tutorial should cover advanced topics such as ESI
or if these things only should be documented in the reference guide -
I think the tutorial only should cover the basics).

The third and possibly the most essential part of the documentation is
the reference guide. The reference guide will amongst other things
contain the man pages for all the programs. Since including troff in
reStructuredText is difficult I suggest we convert the existing troff
pages into reStructuredText. This makes it easy to include the man
pages in the reference guide with the added bonus of making
contributing to the man pages easier (no one likes editing troff).

The problem is that we now add a build dependency on the Python
docutils. Personally I don't mind build-dependencies but the FreeBSD
tradition is that one compiles the software in its production
environment and one should try to keep the production environment as
clean as possible. If we are to honor this I suggest we check in the
converted man pages back into SVN the way we do with the TCL output.

-- 
Per Buer,  Varnish Software
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer



From tfheen at varnish-software.com  Mon May 31 13:28:44 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Mon, 31 May 2010 15:28:44 +0200
Subject: docs: getting rid of the troff pages.
In-Reply-To: <AANLkTikZfvhjlzqwNakLO1-axQXqnE5P8Z-zlT4rijzm@mail.gmail.com>
	(Per Buer's message of "Mon, 31 May 2010 15:10:07 +0200")
References: <AANLkTikZfvhjlzqwNakLO1-axQXqnE5P8Z-zlT4rijzm@mail.gmail.com>
Message-ID: <87eigs2oab.fsf@qurzaw.linpro.no>

]] Per Buer 

| The problem is that we now add a build dependency on the Python
| docutils. Personally I don't mind build-dependencies but the FreeBSD
| tradition is that one compiles the software in its production
| environment and one should try to keep the production environment as
| clean as possible. If we are to honor this I suggest we check in the
| converted man pages back into SVN the way we do with the TCL output.

As an alternative, we could just make them on make dist so as long as
you run from tarballs, you don't need python-docutils, but if you run
from SVN you have to have python-docutils (or tell us to not generate
man pages, I guess that's an option too).

I'd _really_ like us to not have more generated files in SVN, they're a
continuing headache each and every time I do a stable release.

-- 
Tollef Fog Heen
Varnish Software
t: +47 21 54 41 73



From phk at phk.freebsd.dk  Mon May 31 15:23:03 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 31 May 2010 15:23:03 +0000
Subject: docs: getting rid of the troff pages. 
In-Reply-To: Your message of "Mon, 31 May 2010 15:10:07 +0200."
	<AANLkTikZfvhjlzqwNakLO1-axQXqnE5P8Z-zlT4rijzm@mail.gmail.com> 
Message-ID: <98953.1275319383@critter.freebsd.dk>

In message <AANLkTikZfvhjlzqwNakLO1-axQXqnE5P8Z-zlT4rijzm at mail.gmail.com>, Per 
Buer writes:

>I think the tutorial only should cover the basics).

I disagree, we want the tutorial to help people as much as possible,
so there is no particular "basics vs advanced" border we should
respect.

In fact, if we want to push ESI adoption, we probably need to have
the tutorial explain it.

We can add it later, doesn't have to be now.

>I suggest we convert the existing troff
>pages into reStructuredText.

Given how seldom man-pages change, and how seldom people change
them to reflect local hacks, I would simply say build the
man pages if we have the tools, if not, too bad.

Make dist should probably complain if they are not made though.

I totally agree with Tollef on checking in generated files,
we should minimize that where we sensibly can[1]

Poul-Henning

[1] The main reason to check in the VCC files generated by Tcl was
Tcl's rarity, now that we use python, I'm open to generate them
at compiletime.

-- 
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  Mon May 31 17:50:05 2010
From: perbu at varnish-software.com (Per Buer)
Date: Mon, 31 May 2010 19:50:05 +0200
Subject: docs: getting rid of the troff pages.
In-Reply-To: <98953.1275319383@critter.freebsd.dk>
References: <AANLkTikZfvhjlzqwNakLO1-axQXqnE5P8Z-zlT4rijzm@mail.gmail.com>
	<98953.1275319383@critter.freebsd.dk>
Message-ID: <AANLkTimT7AZzpSfxqKdcVNNPQJopNHd0W5jR273N0uM_@mail.gmail.com>

On Mon, May 31, 2010 at 5:23 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> Given how seldom man-pages change, and how seldom people change
> them to reflect local hacks, I would simply say build the
> man pages if we have the tools, if not, too bad.
>
> Make dist should probably complain if they are not made though.

Excellent. I'll place the converted and brushed up rst files in
/doc/sphinx/reference/ - I would need some help to update the man
pages after I'm done so the files get where they belong after
convertion.

-- 
Per Buer,  Varnish Software
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer



From jdzstz at gmail.com  Mon May 31 19:31:31 2010
From: jdzstz at gmail.com (=?ISO-8859-1?Q?Jorge_D=EDaz?=)
Date: Mon, 31 May 2010 21:31:31 +0200
Subject: Problems with varnishncsa and duplicated ReqEnd (tickets #633, #685 
	and #709) - Solaris 10
Message-ID: <AANLkTileEWRZKnKQOR_wyCRtO44GPoPzM6NSZKFiqh35@mail.gmail.com>

I am testing Varnish (r4576 <http://varnish-cache.org/changeset/4576>) in
Solaris 10 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T2000.
We are using now Apache with mod_cache and we are planning to switch to
Varnish, I have followed the instructions in
http://letsgetdugg.com/2009/12/04/varnish-on-solaris/<http://letsgetdugg.com/2009/12/04/varnish-on-solaris/>

After fixing the LINGER problem (ticket
#649<http://varnish-cache.org/ticket/649>), varnish seems to work ok,
we have also make some little tests in
production enviroment, switching to Varnish during 3 hours in one of our
eight Apache Servers.

The only problem that is stopping us to making the change are some strange
behaviour with varnishncsa.
Original varnishncsa.c version generate coredumps and fixed file with
#685<http://varnish-cache.org/ticket/685>workaround generates a lot of
bogus requests.

After some investigations I have found that the root of the problems is a
duplicated ReqEnd record when there is a SessionClose EOF, I have filled the
bug in new ticket #709 <http://varnish-cache.org/ticket/709>  The duplicated
ReqEnd has no XID

Tickets #633 <http://varnish-cache.org/ticket/633> and
#685<http://varnish-cache.org/ticket/685>
they are almost the same. I think it would be nice to control the bogus
requests:

   1. Get XID from ReqEnd
   2. If XID == 0 then ignore ReqEnd
   3. If XID != = but bogus == 1 then print bogus request in standard error.

I attach to the mail two varnishncsa.c fixes:

   1. using workaround of #685  and adding extra logging
   2. retrieving xid and testing "if (!lp->bogus && lp->xid > 0)" and adding
   extra logging

I have to change the extra logging to stderr.


*I need help with #709 <http://varnish-cache.org/ticket/709> , somebody has
any clue about SessionClose EOF problem?? This issue is reported also in
varnish-misc list:
http://lists.varnish-cache.org/pipermail/varnish-misc/2009-December/003395.html
*
I attach my preproduction logs (with a BOGUS error and a duplicated ReqEnd)
and my modified varnishncsa:

    7 TxHeader     c X-backend: prepro
    7 ReqEnd       c 1937859944 1275326684.354095459 1275326684.376112938
0.000319004 0.021736622 0.000280857
    7 SessionClose c EOF
    7 ReqEnd       c 0 1275326684.386904716 1275326684.386904716 0.010791779
0.000000000 0.000000000
    7 StatSess     c 212.170.156.253 31325 0 1 1 0 0 1 288 0

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100531/dcf7abb8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acc_20100531_190000.log
Type: application/octet-stream
Size: 74760 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100531/dcf7abb8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: varnish_log.zip
Type: application/zip
Size: 289945 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100531/dcf7abb8/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: varnishncsa_jdzst_fix.c
Type: application/octet-stream
Size: 14818 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100531/dcf7abb8/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: varnishncsa_jdzst_fix2.c
Type: application/octet-stream
Size: 14824 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100531/dcf7abb8/attachment-0002.obj>