From apj at mutt.dk Fri Dec 2 09:59:43 2011 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Fri, 2 Dec 2011 10:59:43 +0100 Subject: vcl_error function not getting executed In-Reply-To: References: Message-ID: <20111202095943.GL3214@nerd.dk> On Wed, Nov 30, 2011 at 10:27:40AM +0000, manju m wrote: > > I have a requirement for customizing 404 error page for varnish, and i > have done the changes. > But the changes are not getting picked up, i still get the error page > from the application , not the one which i have configured in varnish, > even after restarting varnish. A 404 is a cacheable object like any other. vcl_error is used when varnish can't fetch the object you're trying to serve, or when the vcl uses the function. You can call error yourself in vcl_fetch if the server returns a 404. -- Andreas From martin at varnish-software.com Fri Dec 2 15:37:24 2011 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Fri, 2 Dec 2011 16:37:24 +0100 Subject: Proposed busyobj handling changes and fix for 1068 Message-ID: Please find attached a patch that reworks the busyobj handling code somewhat, and also fixes bug 1068. Regards, Martin Blix Grydeland -- Martin Blix Grydeland Varnish Software AS -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rework-busyobj-handling.patch Type: text/x-patch Size: 8202 bytes Desc: not available URL: From jdzstz at gmail.com Mon Dec 5 02:17:45 2011 From: jdzstz at gmail.com (jdzstz - gmail dot com) Date: Mon, 5 Dec 2011 03:17:45 +0100 Subject: Updated varnish cygwin patches to 3.0.2 varnish version Message-ID: I have updated varnish packages in Cygwin (Windows) plataform to version 3.0.2 You can install it executing cygwin setup.exe (http://cygwin.com/setup.exe) and selecting "varnish" package in selection list at categories "Net" or "Web" 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.2-cygwin_makefiles.patch - Changes that fixes varnishtest problems (timeouts and path problems): https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.2-cygwin_varnishtest.patch - Changes that allows windows paths for some varnish directories: https://www.varnish-cache.org/trac/attachment/wiki/VarnishOnCygwinWindows/varnish-3.0.2-cygwin_windows_path.patch Almost all changes are written to be platform independent, so patched code can be compiled at both cygwin and linux. There are some problems with vtc varnishtest files, that doesn't allow using #ifdef macro but some vmod paths changes at cygwin. Regards, Jorge From perbu at varnish-software.com Mon Dec 5 10:34:48 2011 From: perbu at varnish-software.com (Per Buer) Date: Mon, 5 Dec 2011 11:34:48 +0100 Subject: name changes for the upcoming 4.0 Message-ID: Hi. At some point we'll make a 4.0 release and I'll thought I'll raise a suggestion. This is mostly based on feedback from people that are new to Varnish. A few of the names we've chosen are pretty?uninformative. The good thing is that this forces people to read the docs. On the flip side it doesn't convey anything at all about what the function actually does and so the functionality here is mostly out of the reach of most of the users. There are several ways of addressing this. Some more involved than others. One very simple way would be a simple rename. 1) grace The Squid people call this stale-while-revalidate which I think is an OK name. It tells us a lot more than what grace does. 2) saint mode I think the squid people (I know, that sounds weird) has something that roughly matches. They call this stale-if-error. While not completely accurate it is not bad. We might also consider something like "blacklist-from-server". 3) keep Today, grace is set in vcl_fetch also. I think it would make sense to change this to something like keep-past-ttl. stale-while-revalidate/grace would still be set in vcl_recv. This also makes sense for the upcoming IMS against backend. One forth and not related issue is "ban". We've already renamed this once. Most people seem to get?anchored to some perception that this has to do with banning someone from getting content. My best suggestion for a new name would be "purge-filter". Tollefs suggestion is "invalidate" which might cover it better. What do you think? -- Per Buer, Varnish Software Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer Varnish makes websites fly! Whitepapers?| Video?| Twitter From geoff at uplex.de Mon Dec 5 11:23:52 2011 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 05 Dec 2011 12:23:52 +0100 Subject: name changes for the upcoming 4.0 In-Reply-To: References: Message-ID: <4EDCA9C8.2030300@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/ 5/11 11:34 AM, Per Buer wrote: > > 1) grace > > The Squid people call this stale-while-revalidate which I think is an > OK name. It tells us a lot more than what grace does. > > 3) keep > > Today, grace is set in vcl_fetch also. I think it would make sense to > change this to something like keep-past-ttl. > stale-while-revalidate/grace would still be set in vcl_recv. This also > makes sense for the upcoming IMS against backend. "keep" has evolved through a few name changes since we first started working on IMS, originally it was "conditional_ttl", which was considered much too long, and then "cond_ttl", which was still too long. I certainly see the value of names that describe themselves well, at the price of length (after all, I've spent a lot of time as a Java developer). But the Unix-y culture around Varnish tends to favor much shorter names, at the price of being more opaque. The long names in Java are not much of a problem when you're using an IDE with code completion. No such luck if you're hacking VCL in vi. Best, Geoff - -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJO3KnHAAoJEOUwvh9pJNURKmsQAIIQVS6BQwBJOpHCQiy/x0Z8 CoK0SvnYHtjmqcWRivT8Fg0409U+fOZaOfzFVVHCaleEUDsTcpcvpSxVjfZaXRsh Rd4ARdewGgSC3qGIPVWGLegFEfEHBy3U86VaESZ7IOdv2uTJvQBBFWM/ccSJXObU rqS+dk/iPk+HmJhw3F5yvH4tLfELjIhYq/7fvY8Od6BCmJLGG47bfNeoN0ckEXV9 MtgjlsETBQaWxzhD4FGyseAlsIhSZ2gxeeGI4bjauZJJorqQ648G7RU0zy1EFZF/ /1J8Dn+KFF5WVJkBLaRWIUmYK3DEyZtSzIDcPYt8l7/KguGDCtXUrmHWEoQMUAoh PS97pF0Gr+mil/Rg7XUvvphR+ApKkXuOPvuFrZQkHrDEMcRiIRfb+4WqxmZIDIif dkLaF7NRPmvCIQeryrItgaFBK9IKFtDyjqver1/Wil2GJOng3gyECCaNVcgVfrGm 6WLCiCwlWRr8BisX98bGL3A6m8/rOS1NgMXLAdW94z5awSDaUbyG85F/KWMRhDmR 5YTi40QFMxfViU80lQ0782c2R3d13cXUz9HSBdHfWhFilJQaxSy8hWn6mII7WMSx T1zTYCX7zxYAwNrmc5w60qyvx0FGmqWYibJd4Gn5pEAQ95alpJ5FWLpubeqcx/vb k0hFzK66iNZW1QZBV/fN =fVNW -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Mon Dec 5 12:35:48 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 Dec 2011 12:35:48 +0000 Subject: Varnish 3.1 becoming 4.0 instead (?) Message-ID: <78132.1323088548@critter.freebsd.dk> I've been mildly disciplined for not keeping the -dev mailing list in the loop, and that's perfectly true: I have not. I have no other excuse than I felt like I was talking into an empty room, but I am assured now that the room is no longer empty so I try to make sure that IRC doesn't become CABAL and use -dev more. So a bit of catch-up is probably in order: The big ticket item right now is streaming. Martin is working furiously on that, and I'm trying to slow him down enough to make sure that streaming becomes an integral part and not some bolt-on feature. After streaming backend-If-Modified-Since (Geoffs patches) are next in the line. The thinking until now was that we would try to release Varnish 3.1 with both of these as default-off features, and make them default-on feautures in 4.0 However, as we work the code a couple of details and one 500 pound gorilla has materialized, and I am now leaning towards skipping the 3.1 step and going directly for 4.0. The gorilla is vcl_error{} which I am increasingly convinced was a bad idea to begin with. The only reason why we added vcl_error{} was to avoid every vcl_fetch{} having to have to start with: if (beresp.status == 503) { /* do something */ } But with streaming, you can only detect failures to fetch the headers, once you have started to receive the body, you have committed to a reply to the client, and it cannot be uncommitted. That makes vcl_error{} basically pointless with streaming on. The way I think it will look in 4.0 is that failures to fetch the reponse-headers from the backend, will be reported as a 503 reponse in vcl_fetch{}, from where a restart will be possible. If you are streaming, and the body fails, you won't hear about it at VCL level, there will be nothing we can do about it. If you are not streaming, and the body fetch fails, you will see a 503 in vcl_deliver{}. That leaves the other part of what we use vcl_error for today: synthetic responses. I thought I had a good idea for "synthetic responses from everywhere" last year, but it transpired to be a tar-pit of special-casing, so I abandonned that idea. My thinking now is that functionality can and should move to vcl_deliver{} where it rightfully belongs, with all other responses to the client, and doing it (only) there enables us to provide a much more sane and usable access to the response body. Some sort of VCL syntax for "go to vcl_reponse and deliver response=X" will be needed, and I think it will simply be return (response(812)); which leaves the responsibility for synthesizing headers and body entirely to vcl_deliver{}. So if we do streaming in 3.1 as planned, I'll have to find some way to hack up vcl_error{} to still work as we are used to, and I'm increasingly finding that more trouble than it is worth and leaning more and more towards the 4.0 option where we can do away with vcl_error{} and avoid all the complications. This email represents your chance to come up with really good arguments for why we should not simply skip 3.1 It is also your chance to remind us what other VCL syntax/semantics affecting changes should do/have promised for 4.0. In either case, we are probably looking at a alpha-release with streaming in jan/early-feb, but you will be able to play with -trunk before that. At a more detailed level, Martin and I are trying to pave the road to streaming by shuffling things around, and the cheat-sheat on that looks like this: Everything related to backend fetch goes into busyobj. including htc & (new) workspace for bereq/beresp The new workspace means that we will have three workspaces in total: sess->ws holds req.* ws->ws holds resp.* busyobj->ws holds bereq.* and beresp.* Eventually sess->ws should only exist when sessions do not wait, and then worker->ws can then be eliminated and sess->ws contain both req.* and resp.* (Hopefully in 4.0) Client->body is be dealt with (FetchHdr() before fetcher-thread is spawned. Busyobj must be refcounted, since client->deliver may be much slower than worker->fetch. Busyobj will be malloced, and two strategies for caching free ones will be $param selectable: Either we cache a single free busyobj (in a static variable, under lock), which will work well for high hit-rates. Or we cache one per worker thread in wrk->nbusyobj, without locking, which will be good for low hit-rates. Stats counters will allow us to monitor the situation and improve this policy. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Mon Dec 5 12:38:29 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 Dec 2011 12:38:29 +0000 Subject: name changes for the upcoming 4.0 In-Reply-To: Your message of "Mon, 05 Dec 2011 12:23:52 +0100." <4EDCA9C8.2030300@uplex.de> Message-ID: <78164.1323088709@critter.freebsd.dk> In message <4EDCA9C8.2030300 at uplex.de>, Geoff Simmons writes: >> 1) grace >> >> The Squid people call this stale-while-revalidate which I think is an >> OK name. It tells us a lot more than what grace does. >> >> 3) keep I'd tend to say that I think 'grace' and 'keep' are pretty spot on, but that 'saint' was more of a joke than a serious bid, but we simply couldn't come up with anything better at the time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From perbu at varnish-software.com Mon Dec 5 12:45:03 2011 From: perbu at varnish-software.com (Per Buer) Date: Mon, 5 Dec 2011 13:45:03 +0100 Subject: name changes for the upcoming 4.0 In-Reply-To: <78164.1323088709@critter.freebsd.dk> References: <4EDCA9C8.2030300@uplex.de> <78164.1323088709@critter.freebsd.dk> Message-ID: On Mon, Dec 5, 2011 at 1:38 PM, Poul-Henning Kamp wrote: > > In message <4EDCA9C8.2030300 at uplex.de>, Geoff Simmons writes: > > >> 1) grace > >> > >> The Squid people call this stale-while-revalidate which I think is an > >> OK name. It tells us a lot more than what grace does. > >> > >> 3) keep > > I'd tend to say that I think 'grace' and 'keep' are pretty spot on, > but that 'saint' was more of a joke than a serious bid, but we > simply couldn't come up with anything better at the time. For _us_ it makes perfect sense. But for someone who isn't familiar with the concept "grace" doesn't carry much meaning. Being graceful is something that is rather hard to say no to. Serving content that is stale however, is something quite a lot of people would object to and I think it should be better reflected in the naming. -- Per Buer Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer Varnish makes websites fly! From phk at phk.freebsd.dk Mon Dec 5 13:24:31 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 Dec 2011 13:24:31 +0000 Subject: name changes for the upcoming 4.0 In-Reply-To: Your message of "Mon, 05 Dec 2011 13:45:03 +0100." Message-ID: <7669.1323091471@critter.freebsd.dk> In message , Per Buer writes: >For _us_ it makes perfect sense. But for someone who isn't familiar >with the concept "grace" doesn't carry much meaning. I think a lot of people are familiar with this usage of grace, for instance in the phrase "There, but for the grace of god, go I" etc. -- 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 mattias at nucleus.be Mon Dec 5 13:35:23 2011 From: mattias at nucleus.be (Mattias Geniar) Date: Mon, 5 Dec 2011 14:35:23 +0100 Subject: name changes for the upcoming 4.0 In-Reply-To: <7669.1323091471@critter.freebsd.dk> References: Your message of "Mon, 05 Dec 2011 13:45:03 +0100." <7669.1323091471@critter.freebsd.dk> Message-ID: <18834F5BEC10824891FB8B22AC821A5A01C6D675@nucleus-srv01.Nucleus.local> > >For _us_ it makes perfect sense. But for someone who isn't familiar > >with the concept "grace" doesn't carry much meaning. > > I think a lot of people are familiar with this usage of grace, for > instance in the phrase "There, but for the grace of god, go I" etc. Yes, if your native language is English. Even though most IT'ers have very good understanding of the English language, a more declarative naming can definitely come in handy here. Both "grace", "keep", "saint mode" and even "ban" can mean a ton of different things if you're not a native American/Englishman. Plus, using (parts of) the naming convention of Squid could allow people to translate their current configs to Varnish more easily. The downside is people need to change their VCL -again- after a major version change. Mattias From geoff at uplex.de Mon Dec 5 14:32:54 2011 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 05 Dec 2011 15:32:54 +0100 Subject: name changes for the upcoming 4.0 In-Reply-To: <7669.1323091471@critter.freebsd.dk> References: <7669.1323091471@critter.freebsd.dk> Message-ID: <4EDCD616.9090003@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/ 5/11 02:24 PM, Poul-Henning Kamp wrote: > > I think a lot of people are familiar with this usage of grace, for > instance in the phrase "There, but for the grace of god, go I" etc. If someone manages to draw the inference from "There but for the grace of god go I" to "serve when stale if backends are unhealthy or sessions are busy waiting", they should win some kind of prize. Per's point being, I think, that however appropriate the name sounds once you've understood it, it's not possible to understand it in the first place without consulting the docs. On the other hand, it's not at all clear that renaming "grace" to something like "serve_when_stale_if_ ..." and so forth makes Varnish any easier. Best, Geoff - -- ** * * UPLEX - Nils Goroll Systemoptimierung Schwanenwik 24 22087 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJO3NYWAAoJEOUwvh9pJNURNbUQAJXDCOdQOjXqNS5d8x+yfQnf +CAimDWkTU5WlJm6i+Hg8K70CvGzbBZjGvi1GXBjEa0QPA+ftA8dxVhtUrk3dFin OfLpFuqwRK6prxY4WEWN6VGnjMiPZt3P2gz9yGyCJo+EpOL4EUdVHS79ZUpM1aZy 5mRSUsaoENvQx47YDfutiuN4SPB/wy3/D1o09bUWYXhOcE8GkZmFcI5cOAboCAo1 fsC7LAP/1Ph8jIVjU7W3sJt1sOx49ztxKMreT/mvD/9UucgwPiTFCjMnNsjwofKc UoRf0bvgFaGn7SkAK5YXhBLUyBmu0s0+L5VdFvhU91fIwQPW8fP+BS6Qg713lY5d 5haRwIKTFd+BRADJstSD0cERADtsP1chDwPoApZwUWbP4GojKJO0nd+oi+Sd5z5G E+PgiD0gishhB1ColYnBBIn1dWk2kZc0cT5QL5KUL7Fu/Vuum4yq8G2HS2wcyLZW YrEO2cMnwaD736HfzZThnFDJi8zX7ab1jd3H6aX7p4YizO5DKO/RrOP8AGK6IyS/ yI1ZQ1Ley0Iq/p4gngnSkR8/7ajDKCg/l6qnTUR2VOz7K8/n5u7F9gWK7X+Sh4My xW46wgzxxEGnqsKgsCaKn2ykqXqAn09u2EeQJgPpvHMonHMx6ItkUnYYyAnlqKOx l6fxuST8XAcIynLQK+Ws =HYCv -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Mon Dec 5 15:10:23 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 Dec 2011 15:10:23 +0000 Subject: name changes for the upcoming 4.0 In-Reply-To: Your message of "Mon, 05 Dec 2011 15:32:54 +0100." <4EDCD616.9090003@uplex.de> Message-ID: <56265.1323097823@critter.freebsd.dk> In message <4EDCD616.9090003 at uplex.de>, Geoff Simmons writes: >Per's point being, I think, that however appropriate the name sounds >once you've understood it, it's not possible to understand it in the >first place without consulting the docs. And the disadvantage of that would be ? :-) -- 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 kacperw at online.no Mon Dec 5 17:05:55 2011 From: kacperw at online.no (Kacper Wysocki) Date: Mon, 5 Dec 2011 18:05:55 +0100 Subject: name changes for the upcoming 4.0 In-Reply-To: <56265.1323097823@critter.freebsd.dk> References: <4EDCD616.9090003@uplex.de> <56265.1323097823@critter.freebsd.dk> Message-ID: On Mon, Dec 5, 2011 at 4:10 PM, Poul-Henning Kamp wrote: > In message <4EDCD616.9090003 at uplex.de>, Geoff Simmons writes: > >>Per's point being, I think, that however appropriate the name sounds >>once you've understood it, it's not possible to understand it in the >>first place without consulting the docs. > > And the disadvantage of that would be ? ? :-) not altogether apparent... presumably you would have to consult the docs regardless. >> On the other hand, it's not at all clear that renaming "grace" to >> something like "serve_when_stale_if_ ..." and so forth makes Varnish any >> easier. I am pretty sure it wouldn't, and has the (big imho) impact of breaking all previous scripts for dubious gains. It is true, both grace and saint are rather opaque concepts, but that doesn't mean we should map them to squid's rather opaque and verbose concepts, over for example akamai's terminology. -K From l.rieder at gmail.com Wed Dec 7 17:20:56 2011 From: l.rieder at gmail.com (Lukas Rieder) Date: Wed, 7 Dec 2011 18:20:56 +0100 Subject: Dynamic backend selection for ESI fragments Message-ID: <000F1378F7D242DC8045F131B7539A90@gmail.com> Hello, I am using Varnish as an ESI backend, and therefore I've stumbled upon one constraint. Varnish backends must be known at configuration time. I have not found a possibility to create a backend "on the fly" or let a DNS server decide about backends. The problem is the following: I use Varnish for caching and resolving ESI fragments with absolute URLs. This works well for all defined backends. But the problem in my project is, that new services are being added or removed all the time. Now it would be amazing if I could find a way, how to resolve ESI fragments dynamically through a DNS server. I know that there is a good reason why ESI fragments are bound to the available backends. It would be a security issue to allow ESI fragments point everywhere. But imagine a setup with a DNS server who manages the reachable services and rejects to resolve requests for unknown hosts. At the moment I am running the following workaround: 1) The ESI fragment defines a relative path i.e.: 2) Varnish forwards requests with urls matching /fragments/ to Nginx (the `proxy` backend in the vcl). Here is the key part of this configuration: sub vcl_recv { if (req.url ~ "^/fragments/([a-z0-9.-]+)/?(.*)$") { set req.http.Host = regsub(req.url, "^/fragments/([a-z0-9.-]+)/?(.*)$", "\1"); set req.url = regsub(req.url, "^/fragments/([a-z0-9.-]+)/?(.*)$", "/\2"); set req.backend = proxy; } else { set req.backend = default; } } 3) Nginx resolves the request through our own DNS server. The DNS server only resolves known hosts and does not forward DNS requests. This approach works for now as a proof of concept, but there is a lot of overhead. Thank you for reading. Please tell me your thoughts. Or maybe you know how to write a VMOD that can control backend selection. I have never written a VMOD so far, and unfortunately I do not know much about the backend selection internals. But with some help, I'd be willing to implement a VMOD (and release it as open source for sure). Lukas Rieder -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Dec 8 07:53:05 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 Dec 2011 07:53:05 +0000 Subject: busyobj caching Message-ID: <84221.1323330785@critter.freebsd.dk> As you've noticed if you are reading commit mails, Martin and I are busy moving all the backend fetch related stuff into a the busyobj structure. Right now we offer to $param selectable options for memory management of the busyobj, and I would like to get your input & experience with this detail. In one more, we cache a busyobj per worker thread, this is for all practical purposes the same thing we had before this change. The other option is to use a single slot global cache, which saves a bunch of memory in worker threads at the cost of malloc-trafic, locking and lock contention. For a site with high hitrates, it may be an advantage to switch to the single slot global cache by setting busyobj_worker_cache=false as this will reduce the memory footprint. The question in my mind, is what every everybody else needs. On one hand, a single malloc/free per backend fetch is not a really big deal performance wise, on the other hand, having a slightly larger cache than a single entry might be beneficial. Before I pour any more time into this, I'd like to get some real-world feedback, so if anybody can measure any difference by changing the busyobj_worker_cache param, I'd like to hear about it. This is not a high-priority project, but if you have the chance... -- 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 tfheen at varnish-software.com Thu Dec 8 12:03:12 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Thu, 08 Dec 2011 13:03:12 +0100 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: <78132.1323088548@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 05 Dec 2011 12:35:48 +0000") References: <78132.1323088548@critter.freebsd.dk> Message-ID: <87ty5bmfsv.fsf@qurzaw.varnish-software.com> ]] Poul-Henning Kamp Hi, > The only reason why we added vcl_error{} was to avoid every vcl_fetch{} > having to have to start with: > > if (beresp.status == 503) { > /* do something */ > } > > But with streaming, you can only detect failures to fetch the > headers, once you have started to receive the body, you have committed > to a reply to the client, and it cannot be uncommitted. > > That makes vcl_error{} basically pointless with streaming on. I'd call it ?less useful?, not useless, since quite often the problem is that your backend is overloaded and not able to give us an answer in a reasonable amount of time. Still something we should see if we can fix, though. > The way I think it will look in 4.0 is that failures to fetch > the reponse-headers from the backend, will be reported as > a 503 reponse in vcl_fetch{}, from where a restart will > be possible. As long as you can detect whether a 503 is internally generated or not, that's fine. > If you are streaming, and the body fails, you won't hear about it > at VCL level, there will be nothing we can do about it. Reasonable. [...] > So if we do streaming in 3.1 as planned, I'll have to find some way > to hack up vcl_error{} to still work as we are used to, and I'm > increasingly finding that more trouble than it is worth and leaning > more and more towards the 4.0 option where we can do away with > vcl_error{} and avoid all the complications. I don't think the 3.1 vs 4.0 naming is particularly important, but I know you feel much stronger about that than I do. > The new workspace means that we will have three workspaces > in total: > sess->ws holds req.* > ws->ws holds resp.* > busyobj->ws holds bereq.* and beresp.* Does this mean the lifetime of the workspaces are the same as the lifetime of those objects too? > Eventually sess->ws should only exist when sessions do not > wait, and then worker->ws can then be eliminated and sess->ws > contain both req.* and resp.* (Hopefully in 4.0) Won't sess->ws always exist (and probably be where most vmods will store their data) or do you actually mean what you wrote? Cheers, -- Tollef Fog Heen Technical lead, Varnish Software t: +47 21 98 92 64 From phk at phk.freebsd.dk Fri Dec 9 08:48:57 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 09 Dec 2011 08:48:57 +0000 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: Your message of "Thu, 08 Dec 2011 13:03:12 +0100." <87ty5bmfsv.fsf@qurzaw.varnish-software.com> Message-ID: <3629.1323420537@critter.freebsd.dk> In message <87ty5bmfsv.fsf at qurzaw.varnish-software.com>, Tollef Fog Heen writes : >As long as you can detect whether a 503 is internally generated or not, >that's fine. That is an interesting idea, but why would that be important ? >I don't think the 3.1 vs 4.0 naming is particularly important, but I >know you feel much stronger about that than I do. I think we owe the users to clearly mark when we muck about with VCL syntax. If consensus is that 3.1 is sufficient warning, then fine by me. >> Eventually sess->ws should only exist when sessions do not >> wait, and then worker->ws can then be eliminated and sess->ws >> contain both req.* and resp.* (Hopefully in 4.0) > >Won't sess->ws always exist (and probably be where most vmods will store >their data) or do you actually mean what you wrote? I usually mean what I write, but I may not have thought it through before I wrote it :-) My reasoning for the above is that large sites have very high numbers of sessions waiting to see if the client will send more requests and we need to reduce the memory pressure of that. This is not a trivial change by any means, amongst other things a trivial implementations opens several DoS vulnerabilities, so unless I get hit by a really fast inspiratron, this will be somewhere past 4.0 -- 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 tfheen at varnish-software.com Fri Dec 9 13:26:54 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Fri, 09 Dec 2011 14:26:54 +0100 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: <3629.1323420537@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 09 Dec 2011 08:48:57 +0000") References: <3629.1323420537@critter.freebsd.dk> Message-ID: <8762hpc1up.fsf@qurzaw.varnish-software.com> ]] "Poul-Henning Kamp" > In message <87ty5bmfsv.fsf at qurzaw.varnish-software.com>, Tollef Fog Heen writes > : > > >As long as you can detect whether a 503 is internally generated or not, > >that's fine. > > That is an interesting idea, but why would that be important ? It's really part of a somewhat larger problem which currently is to figure out why you ended up in vcl_error. Was it because of a backend timeout? Backend giving ECONNREFUSED? Something else? We don't know, and it might be important to know, either because we want to log it or we want to handle different errors in different ways. So, if you know where an error comes from, you have more information and that's useful. > >I don't think the 3.1 vs 4.0 naming is particularly important, but I > >know you feel much stronger about that than I do. > > I think we owe the users to clearly mark when we muck about with > VCL syntax. If consensus is that 3.1 is sufficient warning, then > fine by me. To the extent historical precedent matters, we did the obj ? beresp change for vcl_fetch in 2.0 ? 2.1. In my head, we don't break stuff in 3.0.x (but we can add bits), we can break between 3.0 and 3.1. The distinction isn't particularly important to me, we are in no risk of running out of integers. > >> Eventually sess->ws should only exist when sessions do not > >> wait, and then worker->ws can then be eliminated and sess->ws > >> contain both req.* and resp.* (Hopefully in 4.0) > > > >Won't sess->ws always exist (and probably be where most vmods will store > >their data) or do you actually mean what you wrote? > > I usually mean what I write, but I may not have thought it through before > I wrote it :-) > > My reasoning for the above is that large sites have very high numbers > of sessions waiting to see if the client will send more requests and > we need to reduce the memory pressure of that. Oh, I think I might have misunderstood what you meant, then. I understood what you wrote to be that sess->ws would go away when a client would wait for a backend fetch for instance, and that did not make any sense at all. (If you go to vcl_hit, you can't use req.* in vcl_deliver would be one of the fallouts.) Dropping or resetting sess->ws between each request would be fine with me. -- Tollef Fog Heen Technical lead, Varnish Software t: +47 21 98 92 64 From phk at phk.freebsd.dk Fri Dec 9 16:12:43 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 09 Dec 2011 16:12:43 +0000 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: Your message of "Fri, 09 Dec 2011 14:26:54 +0100." <8762hpc1up.fsf@qurzaw.varnish-software.com> Message-ID: <5973.1323447163@critter.freebsd.dk> In message <8762hpc1up.fsf at qurzaw.varnish-software.com>, Tollef Fog Heen writes : >> >As long as you can detect whether a 503 is internally generated or not, >> >that's fine. >> >> That is an interesting idea, but why would that be important ? > >It's really part of a somewhat larger problem which currently is to >figure out why you ended up in vcl_error. Right, yes, that's an old wish too. So far I have resisted inventing a bunch of internal numbers (7xx?) because I fear they would leak into the internet, but suggestions are welcome. It is also not obvious to me how many different values we would need to communicate. Suggestions, as always, welcome. >The distinction isn't particularly important to me, we are in no risk of >running out of integers. Tell that to the FreeBSD ports people who saw autocrap shit itself when FreeBSD went to 10.0 :-) -- 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 varnish-dev at iamnafets.com Thu Dec 15 00:21:18 2011 From: varnish-dev at iamnafets.com (Stefan Mai) Date: Wed, 14 Dec 2011 16:21:18 -0800 Subject: ESI Support for Message-ID: Devs, Is there any work being done on adding support for additional ESI constructs (such as esi:vars)? If not, would the core devs be willing to consider a possible patch (from me) adding support for a few additional constructs (as well as updated documentation)? I'd like to add this functionality but I want to also make sure it has the possibility of making it into upstream if the quality is up to snuff. Either way, thank you for a quality piece of software (that has saved us loads of time) and for any direction you can give me! Thanks, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From iamnafets at gmail.com Thu Dec 15 09:13:31 2011 From: iamnafets at gmail.com (Stefan Mai) Date: Thu, 15 Dec 2011 01:13:31 -0800 Subject: ESI Support for In-Reply-To: References: Message-ID: Is there any work being done on adding support for additional ESI constructs (such as esi:vars)? If not, would the core devs be willing to consider a possible patch (from me) adding support for a few additional constructs (as well as updated documentation)? I'd like to add this functionality but I want to also make sure it has the possibility of making it into upstream if the quality is up to snuff. Either way, thank you for a quality piece of software (that has saved us loads of time) and for any direction you can give me! -- Thanks, Stefan Mai (stefan.mai at iamnafets.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Dec 15 09:26:15 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 15 Dec 2011 09:26:15 +0000 Subject: ESI Support for In-Reply-To: Your message of "Thu, 15 Dec 2011 01:13:31 PST." Message-ID: <70533.1323941175@critter.freebsd.dk> In message , Stefan Mai writes: >Is there any work being done on adding support for additional ESI >constructs (such as esi:vars)? If not, would the core devs be willing to >consider a possible patch (from me) adding support for a few additional >constructs (as well as updated documentation)? I'd like to add this >functionality but I want to also make sure it has the possibility of making >it into upstream if the quality is up to snuff. Good patches are always welcome :-) I have no objections to esi:vars on any grounds of principle, but last I looked, which was basically when we added ESI in the first place, I saw a number of implementation details which caused be to put it outside the boundary of our ESI implementation. Since then the ESI parser was rewritten with extension of the ESI feature-set in mind, but I didn't revisit esi:vars specifically. It's probably a good idea, if you try to write an outline of how you want to tackle the implementation and pass it by -dev first, so that you don't spend a lot of time on stuff we can answer or head down a wrong turn without us knowing. Other than that: Go for it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From tfheen at varnish-software.com Thu Dec 15 09:47:47 2011 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Thu, 15 Dec 2011 10:47:47 +0100 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: <5973.1323447163@critter.freebsd.dk> References: <8762hpc1up.fsf@qurzaw.varnish-software.com> <5973.1323447163@critter.freebsd.dk> Message-ID: <20111215094747.GD11804@err.no> ]] Poul-Henning Kamp > In message <8762hpc1up.fsf at qurzaw.varnish-software.com>, Tollef Fog Heen writes > : > > >> >As long as you can detect whether a 503 is internally generated or not, > >> >that's fine. > >> > >> That is an interesting idea, but why would that be important ? > > > >It's really part of a somewhat larger problem which currently is to > >figure out why you ended up in vcl_error. > > Right, yes, that's an old wish too. > > So far I have resisted inventing a bunch of internal numbers (7xx?) > because I fear they would leak into the internet, but suggestions > are welcome. It is also not obvious to me how many different values > we would need to communicate. I like strings, and we can use a error.reason or error.code or a similar variable rather than inventing new status codes that, as you point out, is likely to leak. > >The distinction isn't particularly important to me, we are in no risk of > >running out of integers. > > Tell that to the FreeBSD ports people who saw autocrap shit itself when > FreeBSD went to 10.0 :-) Ouch. :-) But now you've fixed it, so we should be good for at least up to 100, right? ;-) Cheers, -- Tollef Fog Heen Technical lead, Varnish Software t: +47 21 98 92 64 From martin at varnish-software.com Thu Dec 15 15:36:51 2011 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 15 Dec 2011 16:36:51 +0100 Subject: Streaming part 1 (separate fetch thread, no multi-client) Message-ID: Hi Poul-Henning & varnish-dev, Please find attached a series of patches implementing the background fetch thread streaming. Multi-client streaming is coming later. Any comments appreciated. Regards, Martin Blix Grydeland -- Martin Blix Grydeland Varnish Software AS -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-task-scheduling-bits.patch Type: text/x-patch Size: 6239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Make-FetchBody-take-a-busyobj-struct-as-parameter-in.patch Type: text/x-patch Size: 2864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-a-configurable-through-parameter-stream_maxchunk.patch Type: text/x-patch Size: 2154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Don-t-free-the-object-store-when-fetch-fails-and-str.patch Type: text/x-patch Size: 1239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-a-condvar-to-struct-vbo.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Add-stream-data-synchronization-functions-to-cache_b.patch Type: text/x-patch Size: 3054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Rework-RES_StreamPoll-to-use-the-VBO_StreamData-and-.patch Type: text/x-patch Size: 4771 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Add-VBO_StreamStopped-and-VBO_StreamWait-thread-sync.patch Type: text/x-patch Size: 2731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Use-background-thread-fetching-when-streaming.patch Type: text/x-patch Size: 9743 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Add-a-couple-of-streaming-test-cases.patch Type: text/x-patch Size: 2271 bytes Desc: not available URL: From kacperw at online.no Thu Dec 15 16:06:06 2011 From: kacperw at online.no (Kacper Wysocki) Date: Thu, 15 Dec 2011 17:06:06 +0100 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: <78132.1323088548@critter.freebsd.dk> References: <78132.1323088548@critter.freebsd.dk> Message-ID: On Mon, Dec 5, 2011 at 1:35 PM, Poul-Henning Kamp wrote: > > I've been mildly disciplined for not keeping the -dev mailing list > in the loop, and that's perfectly true: I have not. tsk tsk What you are asking here elicits a response in me, and I'm sure in many others on this list, however it is hard enough to articulate and that may be why the list is silent on this issue. [snip .. on streaming..] > The thinking until now was that we would try to release Varnish 3.1 > with both of these as default-off features, and make them default-on > feautures in 4.0 Well, there has been quite a lot of VCL breakage in Varnish over the years, 2.0 -> 2.1 -> 3.0 has not been entirely painless, despite this I'm pretty sure streaming support has a big thumbs up from most of us, and the features gained have outweighed other considerations. > However, as we work the code a couple of details and one 500 pound > gorilla has materialized [snip] > The only reason why we added vcl_error{} was to avoid every vcl_fetch{} > having to have to start with: > > ? ? ? ?if (beresp.status == 503) { > ? ? ? ? ? ? ? ?/* do something */ > ? ? ? ?} > But with streaming, you can only detect failures to fetch the > headers, once you have started to receive the body, you have committed > to a reply to the client, and it cannot be uncommitted. But the reply to the client may fail or hit an exception at any point, both from the source side of the data (backend timeout) and the sink side (client timeout), and being able to do something in VCL on these conditions is gold. > That makes vcl_error{} basically pointless with streaming on. [snip] > The way I think it will look in 4.0 is that failures to fetch > the reponse-headers from the backend, will be reported as > a 503 reponse in vcl_fetch{}, from where a restart will > be possible. > > If you are streaming, and the body fails, you won't hear about it > at VCL level, there will be nothing we can do about it. > If you are not streaming, and the body fetch fails, you will > see a 503 in vcl_deliver{}. > [snip] > ? ? ? ?return (response(812)); This may just be language aesthetics, but this is, how do we say it, fugly. As far as I can understand the problem it's that the introduction of streaming makes it real hard to do a callback? There are some use cases for vcl_error are not being considered here. vcl_error is not just "deliver $some synthetic" but, and this is the main kicker, it's an exception mechanism. Even Tollef's proposed solution of using identifiers instead of status codes is not ideal. The big advantage of vcl_error is that you can call it from the rest of the code and also be sure you land there when an error occurs in the request flow. > So if we do streaming in 3.1 as planned, I'll have to find some way > to hack up vcl_error{} to still work as we are used to, and I'm > increasingly finding that more trouble than it is worth and leaning > more and more towards the 4.0 option where we can do away with > vcl_error{} and avoid all the complications. > > This email represents your chance to come up with really good > arguments for why we should not simply skip 3.1 Hopefully I've articulated some arguments for keeping vcl_error that don't just involve the standard gripes with losing vcl compatability. -K From phk at phk.freebsd.dk Fri Dec 16 21:07:49 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 16 Dec 2011 21:07:49 +0000 Subject: Varnish 3.1 becoming 4.0 instead (?) In-Reply-To: Your message of "Thu, 15 Dec 2011 17:06:06 +0100." Message-ID: <81391.1324069669@critter.freebsd.dk> In message , Kacper Wysocki writes: >But the reply to the client may fail or hit an exception at any point, >both from the source side of the data (backend timeout) and the sink >side (client timeout), and being able to do something in VCL on these >conditions is gold. What would you do ? The half-baked reponse being half-sent to the client cannot be recovered or salvaged in any way ? > As far as I can understand the problem it's that the introduction of >streaming makes it real hard to do a callback? It's more that there is nothing the call-back can do, the damage is done and there's nothing sensible we can do, but a cleanup. >There are some use cases for vcl_error are not being considered here. They are considered, but I may not have explained it well enough: Instead of vcl_error{}, you will use vcl_deliver{}, and in vcl_deliver{} you can build synthetic responses. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Dec 22 15:38:24 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 22 Dec 2011 15:38:24 +0000 Subject: so, yeah, about keeping you in the loop... Message-ID: <51097.1324568304@critter.freebsd.dk> I'm still trying to get used to using the -dev list more: I'm not quite sure if there were any consensus on the 3.1/4.0 naming issue, that one's still sort of open. Arthur raised a point long time ago, which I have been ignoring for far too long, but I've decided to tackle it now: Varnish doesn't have a "struct req", but only a "struct sess". Together with the session workspace and other stuff, that means that we have a lot of memory sitting idle in the "waiter" in the hope that the client sends us another request. Fixing that will be major surgery, but fortunately, it is almost entirely mechanical in the form of s/sp->foo/sp->req->foo/ substitutions. I've been prototyping this massive text-editing exercise locally and it seems like we can trivially get down to 512 bytes of memory per session waiting for more requests. One of the preparations for this and other changes, is that I have tired of writing memory pool managers, and have started to write the memory pool manager to manage all pools. This gives us a consistent view of these pools, with parameters and statistics we can hopefully draw benefits from. A pool has a low and high watermarks and a idle-timeout. A dedicated per pool thread will preallocate/discard items to keep the pool inside the watermarks. The tricky thing about these pools is that they must be able to allocate items of changing size: If you decide you need a larger workspace or more HTTP headers, that should be an on-the-fly change not requiring a restart. I think I have this covered, but we'll see. In the end I think the memory situation will be: N workerpools which each have: a bunch of worker threads a memory pool of "struct sess" a (smaller) memory pool of "struct req" Co-allocated with workspace for req/resp A mempool for backend-connections "vbc" A mempool for busy objects "busyobj" Co-allocated with workspace for bereq/beresp (busyobj is the pivot for talking to the backend) Stand by for some turbulence... Ohh, and Merry X-mas everybody! -- 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 brad at comstyle.com Fri Dec 23 14:49:12 2011 From: brad at comstyle.com (Brad) Date: Fri, 23 Dec 2011 09:49:12 -0500 Subject: [PATCH] Enable kqueue() support on OpenBSD. Message-ID: <20111223144912.GA16802@rox.home.comstyle.com> The following diff fixes the autoconf script to properly detect the presence of kqueue() on OpenBSD. diff --git a/configure.ac b/configure.ac index 8404de4..425d925 100644 --- a/configure.ac +++ b/configure.ac @@ -335,7 +335,7 @@ AC_ARG_ENABLE(kqueue, if test "$enable_kqueue" = yes; then case $target in - *-*-freebsd* | *-*-darwin9* | *-*-darwin11* | *-*-netbsd* ) + *-*-freebsd* | *-*-darwin9* | *-*-darwin11* | *-*-netbsd* | *-*-openbsd*) AC_CHECK_FUNCS([kqueue]) ;; *-*-bsd*) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From phk at phk.freebsd.dk Sun Dec 25 10:27:38 2011 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 25 Dec 2011 10:27:38 +0000 Subject: struct sess -> struct req move cheat-script Message-ID: <62293.1324808858@critter.freebsd.dk> Those of you developing VMODS, may be able to use this small shell-script to edit your files to match the new field locations: ------------------------------------------------------------------ #!/bin/sh for w in \ xid restarts esi_level disable_esi hash_ vary_ digest \ doclose exp cur_method handling sendbody wantbody \ err_ director vcl req_bodybytes ws_req t_resp \ htc client_identity ws http do find . ../../lib/libvmod_std -name '*.[ch]' -print | sed ' ' | while read a do if grep "[^e]sp->$w" $a ; then echo "$a" sed -i "" "s/\([^e]\)sp->$w/\1sp->req->$w/g" $a fi done done ------------------------------------------------------------------ -- 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 kalerparamvir at gmail.com Wed Dec 28 16:10:59 2011 From: kalerparamvir at gmail.com (paramvir kaler) Date: Wed, 28 Dec 2011 21:40:59 +0530 Subject: Upgrading from 2.1.5 to 3 Message-ID: Hi, I am facing a lot of problems with .vcl file after upgrading. Can anyone make the changes in .vcl file for me and make it compatible with varnish 3 ? Regards, Paramvir Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: