From phk at phk.freebsd.dk  Fri Jan  1 11:18:07 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 01 Jan 2010 11:18:07 +0000
Subject: inline C code and post data 
In-Reply-To: Your message of "Thu, 31 Dec 2009 16:32:15 CST."
	<6d0f643a0912311432v1e594e5cl601f1a5b19b59956@mail.gmail.com> 
Message-ID: <61328.1262344687@critter.freebsd.dk>

In message <6d0f643a0912311432v1e594e5cl601f1a5b19b59956 at mail.gmail.com>, Cal H
eldenbrand writes:

>I just started experimenting with the coolness of using inline C in VCL, and
>I've run into a bit of a hurdle -- I can't find any VRT functions that allow
>me to dig into the request body where the post data is at.

The post data is not available at any point near VCL, it is transferred
to the backend as part of the backend fetch.

Poul-Henning

PS: Happy NewYear

-- 
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 cal at fbsdata.com  Fri Jan  1 20:02:42 2010
From: cal at fbsdata.com (Cal Heldenbrand)
Date: Fri, 1 Jan 2010 14:02:42 -0600
Subject: inline C code and post data
In-Reply-To: <61328.1262344687@critter.freebsd.dk>
References: <6d0f643a0912311432v1e594e5cl601f1a5b19b59956@mail.gmail.com> 
	<61328.1262344687@critter.freebsd.dk>
Message-ID: <6d0f643a1001011202q76bcde16vbdcc86fcf76d16fb@mail.gmail.com>

How difficult do you think it would be to provide this to the VRT level?
I'd be happy to do the coding if you point me in the right direction of
where the post data is handled in the source.

I think it would be a useful tool for the rest of the community as well.  (I
remember some mailing list post on doing security matching, similar to
Apache's mod_security)

Thanks, and happy hangover day!

--Cal


On Fri, Jan 1, 2010 at 5:18 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <6d0f643a0912311432v1e594e5cl601f1a5b19b59956 at mail.gmail.com>,
> Cal H
> eldenbrand writes:
>
> >I just started experimenting with the coolness of using inline C in VCL,
> and
> >I've run into a bit of a hurdle -- I can't find any VRT functions that
> allow
> >me to dig into the request body where the post data is at.
>
> The post data is not available at any point near VCL, it is transferred
> to the backend as part of the backend fetch.
>
> Poul-Henning
>
> PS: Happy NewYear
>
> --
> 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/20100101/9503f13a/attachment.html>

From ej at twitter.com  Tue Jan  5 22:56:48 2010
From: ej at twitter.com (Eric Jensen)
Date: Tue, 5 Jan 2010 14:56:48 -0800
Subject: synthetic ESI for JSONP
Message-ID: <CED9F3D6-FDDB-4E37-9D21-E21380AD1EE3@twitter.com>

I am playing with a VCL for doing ESI on "synthetic" responses in order to serve JSONP callback requests.  Basically, to support JSONP a javascript client makes a request with a randomly generated "&callback=blah135297" parameter and we must return responses that look like "blah135297(CACHEABLE JSON RESPONSE HERE);"

I've come up with the following example solution to construct the ESI template for this within varnish itself:

sub vcl_recv {
  if (req.url ~ "callback") {
        set req.http.X-Callback = regsub(req.url, ".*[\?&]callback=([/@.:A-Za-z0-9_]+).*", "\1");
        set req.http.X-ESI-Url = req.url;
        set req.url = "/VARNISHDUMMY";
  }
}

sub vcl_fetch {
 if (req.http.X-ESI-Url) {
      synthetic req.http.X-Callback "(<esi:include src=%22" req.http.X-ESI-Url "%22/>);";
      esi;
 }
}

This works, but it has two undesirable properties that I'm looking for suggestions on how to fix:

1.  It makes an unnecessary dummy request to the backend.  Is there some way I can create a noop backend, set some parameter to make the request itself a noop, or just avoid the actual fetch altogether but still get into vcl_fetch which is the only place you can call esi?

2.  The response code, headers, etc. from the dummy request are returned to the client instead of the meaningful ones from the ESI request.  Is there some way to copy the ESI response into the one to be returned?  Can I access it from C somehow?

Thanks,
eric

From cal at fbsdata.com  Wed Jan  6 15:45:28 2010
From: cal at fbsdata.com (Cal Heldenbrand)
Date: Wed, 6 Jan 2010 09:45:28 -0600
Subject: module init hook
Message-ID: <6d0f643a1001060745k3cb5dcc9n766cf52e0a809c96@mail.gmail.com>

Hello,

Is there a good method to load my module in the main varnishd thread?
Currently I'm just adding some inline code to vcl_recv to open up my shared
lib and call dlsym() to load my functions.  Looking at the compiled VCL
code, is it possible to inject something in VGC_Init()?  And, would that
load my module once on startup, then still be available to each handler
thread?

Thanks!

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

From paul.mansfield at taptu.com  Wed Jan  6 16:25:12 2010
From: paul.mansfield at taptu.com (Paul Mansfield)
Date: Wed, 06 Jan 2010 16:25:12 +0000
Subject: idea for load "balancer" with fan-out/ voting
Message-ID: <4B44B968.6060806@taptu.com>

just some ideas for discussion...

whilst varnish has been very good at alleviating load by virtue of its
forced caching feature, I was wondering whether it's be possible to have
one request be duplicated to multiple back-end servers and the first one
to reply is used and the others ignored.

you see, if you're using java, the servers might be responding quite
quickly and thus be used in favour of slower servers, but then they hit
garbage collection at some non-deterministic time, and for a very short
while response times become very long.

so if you could duplicate an http request to multiple servers and get
the first response, you'd have to be pretty unlucky for all of them to
be garbage collecting and unresponsive.



From phk at phk.freebsd.dk  Wed Jan  6 16:52:43 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 06 Jan 2010 16:52:43 +0000
Subject: idea for load "balancer" with fan-out/ voting 
In-Reply-To: Your message of "Wed, 06 Jan 2010 16:25:12 GMT."
	<4B44B968.6060806@taptu.com> 
Message-ID: <2261.1262796763@critter.freebsd.dk>

In message <4B44B968.6060806 at taptu.com>, Paul Mansfield writes:
>just some ideas for discussion...
>
>whilst varnish has been very good at alleviating load by virtue of its
>forced caching feature, I was wondering whether it's be possible to have
>one request be duplicated to multiple back-end servers and the first one
>to reply is used and the others ignored.

Ouch.  That one is not easy, we pretty much hardcoded that we would
only fetch from one backend at a time for each session.

Sounds sort of hackish though.

Couldn't you solve this by aggressively probing your backends and
let them go sick during GC ?

-- 
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 Jan  6 16:54:47 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 06 Jan 2010 16:54:47 +0000
Subject: module init hook 
In-Reply-To: Your message of "Wed, 06 Jan 2010 09:45:28 CST."
	<6d0f643a1001060745k3cb5dcc9n766cf52e0a809c96@mail.gmail.com> 
Message-ID: <11646.1262796887@critter.freebsd.dk>

In message <6d0f643a1001060745k3cb5dcc9n766cf52e0a809c96 at mail.gmail.com>, Cal H
eldenbrand writes:

>Is there a good method to load my module in the main varnishd thread?

Not right now.

I am working on a way to use "libraries" from varnish, but it is not
ready yet.

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 cal at fbsdata.com  Wed Jan  6 17:05:41 2010
From: cal at fbsdata.com (Cal Heldenbrand)
Date: Wed, 6 Jan 2010 11:05:41 -0600
Subject: module init hook
In-Reply-To: <11646.1262796887@critter.freebsd.dk>
References: <6d0f643a1001060745k3cb5dcc9n766cf52e0a809c96@mail.gmail.com> 
	<11646.1262796887@critter.freebsd.dk>
Message-ID: <6d0f643a1001060905l126f84c2p73707a0b342c89cd@mail.gmail.com>

I read your wiki
doc<http://varnish.projects.linpro.no/wiki/ArchitectureInlineC>on
shared libs, it looks like an awesome UI to make things easy.
(Especially if VCL variables are passed to functions as char arrays, without
the need to call VRT functions directly)

I'd like to help test when it's ready.  :-)

Thanks,

--Cal


On Wed, Jan 6, 2010 at 10:54 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <6d0f643a1001060745k3cb5dcc9n766cf52e0a809c96 at mail.gmail.com>,
> Cal H
> eldenbrand writes:
>
> >Is there a good method to load my module in the main varnishd thread?
>
> Not right now.
>
> I am working on a way to use "libraries" from varnish, but it is not
> ready yet.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100106/db8b6c0a/attachment.html>

From r.maccallum at imperial.ac.uk  Thu Jan  7 11:29:08 2010
From: r.maccallum at imperial.ac.uk (Bob MacCallum)
Date: Thu, 7 Jan 2010 11:29:08 +0000
Subject: idea for load "balancer" with fan-out/ voting 
In-Reply-To: <2261.1262796763@critter.freebsd.dk>
References: <4B44B968.6060806@taptu.com> <2261.1262796763@critter.freebsd.dk>
Message-ID: <19269.50564.717133.976149@bio-iisrv1.bio.ic.ac.uk>


Sorry, I'm not contributing to the debate, but this has me LOL:

 > Couldn't you solve this by aggressively probing your backends...

:-)

-- 
Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
Division of Cell and Molecular Biology | Imperial College London |
Phone +442075941945 | Email r.maccallum at imperial.ac.uk


From cal at fbsdata.com  Thu Jan  7 15:34:51 2010
From: cal at fbsdata.com (Cal Heldenbrand)
Date: Thu, 7 Jan 2010 09:34:51 -0600
Subject: inline C code and post data
In-Reply-To: <6d0f643a1001011202q76bcde16vbdcc86fcf76d16fb@mail.gmail.com>
References: <6d0f643a0912311432v1e594e5cl601f1a5b19b59956@mail.gmail.com> 
	<61328.1262344687@critter.freebsd.dk>
	<6d0f643a1001011202q76bcde16vbdcc86fcf76d16fb@mail.gmail.com>
Message-ID: <6d0f643a1001070734s2805a5d4md6b17ca4df0b5bb8@mail.gmail.com>

Poul-Henning,

I think I managed to get this working, without needing a modification on the
varnish source.  Here's a snippet of the important parts of how I
implemented this.  (I left out all of my error checking for readability)

void get_req_body(struct sess *sp)
{

   /* create a new shared memory file to store the request body in.
    * Make sure this is deleted after we're done or this will eat up memory!
    */
   int memfd = shm_open(pidstr, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);

   // read the body from the client HTTP connection,
   int rsize = read(sp->htc->fd, body, content_length);

   // write the body into shm
   int wsize = write(memfd, body, content_length);

   // seek the file descriptor back to the beginning of the file
   lseek(memfd, 0, SEEK_SET);

   /* set Varnish's HTTP file descriptor to this new shm file.
    * This fools varnish into reading the request body
    * later on when passing it to the backend
    *
    * Not sure WHY this works though... If it needs to write
    * to the client during vcl_deliver, wouldn't it just
    * write the contents to this shm file?  It must be a
    * different file descriptor for writing?
    */
   sp->htc->fd = memfd;
}

This method was sort of my last ditch effort, and I was surprised that it
worked.  I couldn't find exactly where the deliver code writes to the
socket, but the only explanation is that there is a separate socket for
writing to the client.  Is that correct?

Also, I'm not an expert on how licenses work -- if I want to distribute
this, do I need to license it the same as varnish if I include your headers?

Thanks!

--Cal


On Fri, Jan 1, 2010 at 2:02 PM, Cal Heldenbrand <cal at fbsdata.com> wrote:

> How difficult do you think it would be to provide this to the VRT level?
> I'd be happy to do the coding if you point me in the right direction of
> where the post data is handled in the source.
>
> I think it would be a useful tool for the rest of the community as well.
> (I remember some mailing list post on doing security matching, similar to
> Apache's mod_security)
>
> Thanks, and happy hangover day!
>
> --Cal
>
>
>
> On Fri, Jan 1, 2010 at 5:18 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:
>
>> In message <6d0f643a0912311432v1e594e5cl601f1a5b19b59956 at mail.gmail.com>,
>> Cal H
>> eldenbrand writes:
>>
>> >I just started experimenting with the coolness of using inline C in VCL,
>> and
>> >I've run into a bit of a hurdle -- I can't find any VRT functions that
>> allow
>> >me to dig into the request body where the post data is at.
>>
>> The post data is not available at any point near VCL, it is transferred
>> to the backend as part of the backend fetch.
>>
>> Poul-Henning
>>
>> PS: Happy NewYear
>>
>> --
>> 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/20100107/6fd79b7d/attachment.html>

From slink at schokola.de  Sun Jan 10 18:54:55 2010
From: slink at schokola.de (Nils Goroll)
Date: Sun, 10 Jan 2010 19:54:55 +0100
Subject: idea for load "balancer" with fan-out/ voting
In-Reply-To: <4B44B968.6060806@taptu.com>
References: <4B44B968.6060806@taptu.com>
Message-ID: <4B4A227F.6000102@schokola.de>

Hi Paul,

> so if you could duplicate an http request to multiple servers and get
> the first response, you'd have to be pretty unlucky for all of them to
> be garbage collecting and unresponsive.

This issue can (and should) be solved by properly tuning your Java VMs.

Duplicating workload on the backend to me sounds just like the opposite of what 
you usually want to achieve with an optimization tool like varnish.

Nils


From aotto at mosso.com  Sun Jan 10 19:41:08 2010
From: aotto at mosso.com (Adrian Otto)
Date: Sun, 10 Jan 2010 14:41:08 -0500
Subject: idea for load "balancer" with fan-out/ voting
Message-ID: <le6yhh7unsc3l1sl69p5hneg.1263152468844@email.android.com>

Most applications won't handle duplicate requests gracefully, especially REST like systems that are doing operations like POST or PUT to update data. Generally, once you begin a write operation, you want it to run until the app server tells you there was a timeout.

For read-only operations you might try a short timeout from the load balancer, and upon timeout (no first-byte-response after 2 seconds for example) then mark the node as unhealthy and try a second node with no timeout. Don't be tempted to try more than two because in high load situations that only makes matters worse. You also need a concept of "fewest nodes in pool" so that when things do get slow on the whole cluster you don't end up pruning it to the point where it's too small to be able to do any useful work.... more importantly so you don't empty the cluster. The idea is just to temporarily prune a node or two that get slow, but should recover later.

This approach is better than aggressive polling because it uses less resources (on the proxy and the app server) and the end user never gets trapped on a slow/dead node in the time between the last good health check and the failure event.

Adrian

Nils Goroll <slink at schokola.de> wrote:

>Hi Paul,
>
>> so if you could duplicate an http request to multiple servers and get
>> the first response, you'd have to be pretty unlucky for all of them to
>> be garbage collecting and unresponsive.
>
>This issue can (and should) be solved by properly tuning your Java VMs.
>
>Duplicating workload on the backend to me sounds just like the opposite of what 
>you usually want to achieve with an optimization tool like varnish.
>
>Nils
>_______________________________________________
>varnish-dev mailing list
>varnish-dev at projects.linpro.no
>http://projects.linpro.no/mailman/listinfo/varnish-dev

From paul.mansfield at taptu.com  Mon Jan 11 18:03:44 2010
From: paul.mansfield at taptu.com (Paul Mansfield)
Date: Mon, 11 Jan 2010 18:03:44 +0000
Subject: idea for load "balancer" with fan-out/ voting
In-Reply-To: <4B4A227F.6000102@schokola.de>
References: <4B44B968.6060806@taptu.com> <4B4A227F.6000102@schokola.de>
Message-ID: <4B4B6800.2000706@taptu.com>

On 10/01/10 18:54, Nils Goroll wrote:
> Hi Paul,
>
>> so if you could duplicate an http request to multiple servers and get
>> the first response, you'd have to be pretty unlucky for all of them to
>> be garbage collecting and unresponsive.
>
> This issue can (and should) be solved by properly tuning your Java VMs.
>
> Duplicating workload on the backend to me sounds just like the opposite
> of what you usually want to achieve with an optimization tool like
varnish.

well, this is a sledge-hammer to crack a java nut idea.

problem with java developers is that their answer when faced with
performance problems is to simply throw more memory at it... and even
with fast multi-core CPUs it takes a while to garbage collect a VM which
has eaten ++30GB of ram.

;-(


From slink at schokola.de  Mon Jan 11 19:22:26 2010
From: slink at schokola.de (Nils Goroll)
Date: Mon, 11 Jan 2010 20:22:26 +0100
Subject: idea for load "balancer" with fan-out/ voting
In-Reply-To: <4B4B6800.2000706@taptu.com>
References: <4B44B968.6060806@taptu.com> <4B4A227F.6000102@schokola.de>
	<4B4B6800.2000706@taptu.com>
Message-ID: <4B4B7A72.4050002@schokola.de>

Hi,

> problem with java developers is that their answer when faced with
> performance problems is to simply throw more memory at it... and even
> with fast multi-core CPUs it takes a while to garbage collect a VM which
> has eaten ++30GB of ram.

This is really off-topic, but properly tuning your VMs probably means 
considering the concurrent mark/sweep collector.

Nils


From ask at develooper.com  Mon Jan 11 19:34:52 2010
From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Mon, 11 Jan 2010 11:34:52 -0800
Subject: idea for load "balancer" with fan-out/ voting
In-Reply-To: <4B4A227F.6000102@schokola.de>
References: <4B44B968.6060806@taptu.com> <4B4A227F.6000102@schokola.de>
Message-ID: <8D32A605-2B93-4119-A1B3-D1BC1E43D98E@develooper.com>

I have probably mentioned it before, but I really like how Perlbal checks that a backend is working and responding to requests with an OPTIONS * (configurable) request before sending real requests down that connection.

That way the backend can just disconnect and stop responding to the OPTIONS requests when it doesn't or can't do more work.


  - ask

From mpage at facebook.com  Tue Jan 12 00:13:23 2010
From: mpage at facebook.com (Matthew Page)
Date: Mon, 11 Jan 2010 16:13:23 -0800
Subject: Response bodies cached for HitPass objects
Message-ID: <C770FEA3.1D82%mpage@facebook.com>

Hey All,

It looks like response bodies are cached for the entire life of a HitPass object. Is this true? This is a little surprising since the response body will never be used after it is initially written back to the client. (And we really only want to be caching the ?passness? of the resource.)

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-dev/attachments/20100111/82cfa83b/attachment.html>

From phk at phk.freebsd.dk  Wed Jan 13 20:20:14 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 13 Jan 2010 20:20:14 +0000
Subject: Response bodies cached for HitPass objects 
In-Reply-To: Your message of "Mon, 11 Jan 2010 16:13:23 PST."
	<C770FEA3.1D82%mpage@facebook.com> 
Message-ID: <26230.1263414014@critter.freebsd.dk>

In message <C770FEA3.1D82%mpage at facebook.com>, Matthew Page writes:

>It looks like response bodies are cached for the entire life of a HitPass
>object. Is this true?

Yes, it's a shortcut we made back then.  The reasoning was that hit-for-pass
objects probably would have pretty short lifetimes (usually the default
TTL) and thus not cost too much storage for too long.

As part of changes on the drawingboard now, that will be 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  Tue Jan 19 20:21:30 2010
From: slink at schokola.de (Nils Goroll)
Date: Tue, 19 Jan 2010 21:21:30 +0100
Subject: Support for first byte/between bytes timeouts on systems without
	SO_RCVTIMEO ?
Message-ID: <4B56144A.8060703@schokola.de>

Hi,

has anyone worked already on getting the timeouts implemented on systems without 
SO_RCVTIMEO (namely: Solaris) ?

Cheers, Nils


From ntwrkd at gmail.com  Tue Jan 19 23:22:51 2010
From: ntwrkd at gmail.com (ntwrkd)
Date: Tue, 19 Jan 2010 15:22:51 -0800
Subject: Varnish seeming to not respect mod_expires and mod_headers expires
Message-ID: <f257b9ab1001191522h2f4effbcj96f703ae6c3beec4@mail.gmail.com>

I read the tutorial at
http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching which
states that Varnish should respect the Expires headers; however, it
doesn't seem to be inherited by my implementation.

I have a pretty standard config
backend default {
.host = "127.0.0.1";
.port = "80";
}

sub vcl_recv {
  if (req.url ~
"\.(jpg|jpeg|gif|png|tiff|tif|svg|swf|ico|mp3|mp4|m4a|ogg|mov|avi|wmv)$")
{
      lookup;
  }

  if (req.url ~ "\.(css|js)$") {
      lookup;
  }
}
sub vcl_fetch {
        if( req.request != "POST" )
        {
                unset obj.http.set-cookie;
        }

        set obj.ttl = 600s;
        set obj.prefetch =  -30s;
        unset obj.http.Server;
        set obj.http.Server = "Apache/2.2.10";
        deliver;
}


From kristian at redpill-linpro.com  Fri Jan 22 14:10:48 2010
From: kristian at redpill-linpro.com (Kristian Lyngstol)
Date: Fri, 22 Jan 2010 15:10:48 +0100
Subject: 120 of 143 tests failed
In-Reply-To: <5e98f3430912041253v7f239817s2d59b4e9fffcdbc4@mail.gmail.com>
References: <5e98f3430912041253v7f239817s2d59b4e9fffcdbc4@mail.gmail.com>
Message-ID: <20100122141048.GC9672@kjeks.varnish-cache.com>

On Fri, Dec 04, 2009 at 09:53:36PM +0100, Jon Skarpeteig wrote:
> 120 of 143 tests failed

(...)

Did you figure this out? Most of the time, this is a problem with
conflicting ports (ie: one test is slow and the next ones get affected by
it).

-- 
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-dev/attachments/20100122/8be69811/attachment.bin>

From slink at schokola.de  Fri Jan 22 19:56:28 2010
From: slink at schokola.de (Nils Goroll)
Date: Fri, 22 Jan 2010 20:56:28 +0100
Subject: Any known issues with Solaris event ports?
In-Reply-To: <2202B2DC-E228-44CF-A7CF-E853AB7B7ECC@omniti.com>
References: <49A71CB3.5060905@schokola.de>
	<2202B2DC-E228-44CF-A7CF-E853AB7B7ECC@omniti.com>
Message-ID: <4B5A02EC.5010508@schokola.de>

Hi Theo and all,

I'd appreciate reviews of some fixes to the event port waiter:

http://varnish.projects.linpro.no/ticket/629

These look promising to me, but I might have missed something important.

Thank you, Nils


From jesus at omniti.com  Fri Jan 22 20:38:28 2010
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 22 Jan 2010 15:38:28 -0500
Subject: Any known issues with Solaris event ports?
In-Reply-To: <4B5A02EC.5010508@schokola.de>
References: <49A71CB3.5060905@schokola.de>
	<2202B2DC-E228-44CF-A7CF-E853AB7B7ECC@omniti.com>
	<4B5A02EC.5010508@schokola.de>
Message-ID: <0F2AB4ED-8DDE-41B5-BBC7-8F84A980982A@omniti.com>

This looks really good.

Your description of the problems in the ticket look spot on and the implementation looks correct as well.

I'll see what I can do about pulling this and running it somewhere -- but I'm swamped with some rollouts right now.

On Jan 22, 2010, at 2:56 PM, Nils Goroll wrote:

> Hi Theo and all,
> 
> I'd appreciate reviews of some fixes to the event port waiter:
> 
> http://varnish.projects.linpro.no/ticket/629
> 
> These look promising to me, but I might have missed something important.
> 
> Thank you, Nils

--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle







From slink at schokola.de  Fri Jan 22 21:12:00 2010
From: slink at schokola.de (Nils Goroll)
Date: Fri, 22 Jan 2010 22:12:00 +0100
Subject: Any known issues with Solaris event ports?
In-Reply-To: <0F2AB4ED-8DDE-41B5-BBC7-8F84A980982A@omniti.com>
References: <49A71CB3.5060905@schokola.de>
	<2202B2DC-E228-44CF-A7CF-E853AB7B7ECC@omniti.com>
	<4B5A02EC.5010508@schokola.de>
	<0F2AB4ED-8DDE-41B5-BBC7-8F84A980982A@omniti.com>
Message-ID: <4B5A14A0.7010707@schokola.de>

Hi Theo,

> but I'm swamped with some rollouts right now.

Don't worry, good luck with your projects and thanks for your quick review!

Nils


From tfheen at redpill-linpro.com  Mon Jan 25 09:04:54 2010
From: tfheen at redpill-linpro.com (Tollef Fog Heen)
Date: Mon, 25 Jan 2010 10:04:54 +0100
Subject: Varnish seeming to not respect mod_expires and mod_headers expires
In-Reply-To: <f257b9ab1001191522h2f4effbcj96f703ae6c3beec4@mail.gmail.com>
	(ntwrkd@gmail.com's message of "Tue, 19 Jan 2010 15:22:51 -0800")
References: <f257b9ab1001191522h2f4effbcj96f703ae6c3beec4@mail.gmail.com>
Message-ID: <87aaw2wo5l.fsf@qurzaw.linpro.no>

]] ntwrkd 

| I read the tutorial at
| http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching which
| states that Varnish should respect the Expires headers; however, it
| doesn't seem to be inherited by my implementation.

[...]

|         set obj.ttl = 600s;

You override the TTL here, so you never let it use the Expires header
available.

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