Re: sendfile changes
In message [EMAIL PROTECTED], =?ISO-8859-1?Q?Andreas_R =F8sdal?= writes: Hello, I have a question about a recent change done in SVN trunk: http://varnish.projects.linpro.no/changeset/1417 Make the sendfile threshold inifinity for now, we have evidence of sendfile not doing it's job in a number of operating system (-versions ?) What does not doing it's job mean here? Sending corrupt or incomplete data? One, the other or even Both, depending on your kernel. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: sendfile changes
In message [EMAIL PROTECTED], =?ISO-8859-1?Q?Andreas_R =F8sdal?= writes: On Sun, 13 May 2007, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], =?ISO-8859-1?Q?Andreas_R =F8sdal?= writes: Hello, I have a question about a recent change done in SVN trunk: http://varnish.projects.linpro.no/changeset/1417 Make the sendfile threshold inifinity for now, we have evidence of sendfile not doing it's job in a number of operating system (-versions ?) What does not doing it's job mean here? Sending corrupt or incomplete data? One, the other or even Both, depending on your kernel. Yes, I've seen both. What is the best workaround for this problem? Should I install the varnish from SVN trunk? Just set the parameter sendfile_threshold to -1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: question marks in the url
In message [EMAIL PROTECTED], Bria n Ott writes: We have urls: http://.yyy.com/test.jpg?tsp=11301981 the tsp gets updated when the picture is updated, its a timestamp. this way the user doesnt have to refresh their browser to see new pictures. varnish doesnt cache urls with ? in them, it appears. Varnish doesn't care about '?', but if you have cookies it will not cache. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Error
In message [EMAIL PROTECTED], sure ndar p writes: Hi, When i compile the code,i got this error Expected positive indentation. what is the actual error it is? file and line information, please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Varnish Style Guide
In message [EMAIL PROTECTED], Luke M acpherson writes: Is there any documentation of code style for varnish? I did see an early post on naming conventions, but the code base doesn't actually reflect that early description any more, and some of the conventions I've not been able to reverse-engineer (I find the capitalization strategy particularly confusing). The starting point is FreeBSD's style(9) manual page, and yes, the capitalization is not consistent. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Support Cache-Control no-cache/private as per RFC2616 ?
In message [EMAIL PROTECTED], =?iso-8859-1?Q?Dag-Erling_Sm=F8rg rav?= writes: The closest there is to a formal description of what Varnish is and how it should behave is the Edge Architecture Specification, which unfortunately is far less impressive than its title. ESI is indeed not impressive, but it is also aimed at a very narrow market which Varnish is not (3rd party but non-adverserial caching) The only truly precise way to characterize varnish, IMO, is A webserver that uses HTTP to get at its content. That description on the other hand, is so general as to be almost without meaning. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Support Cache-Control no-cache/private as per RFC2616 ?
In message [EMAIL PROTECTED], Mark Nottingha m writes: On 2007/11/21, at 4:54 AM, Poul-Henning Kamp wrote: The only truly precise way to characterize varnish, IMO, is A webserver that uses HTTP to get at its content. This is a good characterisation. It would probably be more correct to say gateway than webserver, but most casual readers won't know what that means. Well, I specifically use webserver because Varnish should be RFC2616 compliant as one, seen from the clients side. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: development efforts on the Solaris side.
In message [EMAIL PROTECTED], Theo Schlossnagle writes: Hi guys, I'd really like to be able to contribute some of the improvements we've made to varnish back. Is there a way I can get access to commit. I'd be happy to stay in my own branch. My current patch set is unwieldy and I'm very tempted to just start my own repos... That, of course, seems silly. I've fixed up (removed) some of the gccism in favor or more portability (#include over -include). I've fixed a few bugs, made the VCC line a but smarter and more accepting of non gcc compiler, I've added a portfs acceptor and built a storage_umem allocator facility that rides on Solaris' excellent libumem (highly scalable allocator) which we also ported to run on Linux and FreeBSD (and Mac OS X): https://labs.omniti.com/trac/portableumem Next steps? Can you mail me a link to the patch ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching issue
Is this FAQ fodder ?
In message [EMAIL PROTECTED], =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=
writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
You could try the following in vcl_recv:
if (req.http.accept-encoding) {
set req.http.accept-encoding =3D regsub(
req.http.accept-encoding,
gzip, *, gzip,);
}
to get rid of the space(s), but it is not guaranteed to get all cases.
Alternatively, the more brutal:
if (req.http.accept-encoding ~ gzip) {
set req.http.accept-encoding =3D gzip;
} else {
unset req.http.accept-encoding;
}
Will get the desired effect in all cases, provided your backend does
not attempt deflate as fallback.
A slightly more complex solution, to cover all bases without losing
functionality:
set req.http.accept-encoding =3D regsub(req.http.accept-encoding,
^ *gzip, *deflate *$, gzip,deflate);
set req.http.accept-encoding =3D regsub(req.http.accept-encoding,
^ *deflate, *gzip *$, gzip,deflate);
This should take care of 99% of cases; I don't know of any browser that
supports only one of the two, or supports anything *but* those two.
However, Apache only supports gzip, so Poul-Henning's solution is
sufficient in this case.
DES
--=20
Dag-Erling Sm=C3=B8rgrav
Senior Software Developer
Linpro AS - www.linpro.no
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish consuming too much memory?
i'm wondering how varnish determines how much memory it should consume... It uses all memory it can for caching. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Move re test method into libvcl
In message [EMAIL PROTECTED], Paul Nasrat w
rites:
The attached patch against trunk moves and renames the re_test
method into vcc_string.c so libvcl could be used outside of varnishd.
-int
-VRT_re_test(struct vsb *sb, const char *re, int sub)
-{
Your patch breaks the convention that compiled code only calls VRT_*
functions, you need to keep a VRT_re_test() wrapper around for that
reason.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Upload Buffering and x-sendfile
In message [EMAIL PROTECTED], Trey Long writ es: Does varnish support upload (and download) buffering? Since varnish handles all of the traffic going to and from my host I was wondering if it buffered the client when they were uploading a large post body or downloading a large portion of HTML. Downloading: yes, we buffer. Uploading: no, we don't. Does varnish support x-sendfile type responses? Not at present, but it sounds like it could be useful, I'll add it to the post-2.0 ideas list. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: mmap'd file vs. swap
In message [EMAIL PROTECTED], Brian Smith writes: My understanding is that Varnish uses a mmap'd file, but it doesn't re-use the file's contents when it is restarted. Correct. Why does Varnish use a mmap'd file instead of just using regular virtual memory (swap) directly? For many small reasons, none of which are particularly good. You can use regular VM by enabling the malloc storage method and various people report good success with that. I would think that the operating system would be more eager to write the data to the mmap'd file than it would be to write to swap; on a system where the hot cache entries can be stored on disk, it would seem that the swap-based method would be superior. Well, it's slightly more complex than that, we mmap with the MAP_NOSYNC flag so it should be about a wash. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Mapping VCL variables to internal variables
In message [EMAIL PROTECTED], Charles Curley writes:
I'd like to set a variable in VCL, and then use it in a modification
of Varnish. Having added to req.hash with something like:
sub vcl_hash
{
if (req.http.Accept-Encoding ~ gzip) {
set req.hash +=3D gzip;
} else if (req.http.Accept-Encoding ~ deflate) {
set req.hash +=3D deflate;
}
}
where do I find that in Varnish itself?
See cache_center.c::cnt_lookup() [search for VCL_hash_method(sp);],
and cache_hash.c::HSH_Copy(), HSH_Compare() and HSH_Lookup().
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: about big flv files
In message [EMAIL PROTECTED], chen xiaoyong writes: Hey guys, I'm thinking about big flv files in varnishd. Now,many web sites support video, Typically, these files more than 5M. There is no intrinsic limit on object size in varnish, but it is not particular geared towards such use. The major stumbling block is that Varnish will fetch the entire file from the backend before starting transmission to the client. I don't konw what's better .. split file in function fetch_straight ? or do nothing , set up tcp parameters? I'm not sure I understand what you're trying to say here ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: HTCP Purger
In message [EMAIL PROTECTED], Artur Bergman writes: On Jun 23, 2008, at 1:26 AM, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Artur Bergman writes: I have written an multicast HTCP purger, essentially a perl script that listens to HTCP purges and then purges from the local varnish. So this is only for HTCP CLR requests ? Yes We should probably integrate support for that in Varnish (after 2.0 is out the door!) Awww, that is no fun :), would you take ifdefed patches? Sure. I suggest we add your perl script to the wiki somewhere, as an interrim workaround. Can I get a commit bit and commit it into the tools directory? I hate having code on a wiki. I'd really prefer to not put temporary tools in the source tree, because that way it gets an official part of the release and all that jazz. How long is it anyway ? Can you mail it to me ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish version question
In message [EMAIL PROTECTED], Olivier Beau writes: - Which version of varnish is good for production ? Hi Olivier, We are getting very close to a 2.0 release, so right now the best code we have is the trunk version from subversion. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Monitoring varnish
Hi Paul, I have no problems with providing likns on the wiki page if you suggest some text. Poul-Henning In message [EMAIL PROTECTED], Paul Millar writes: Hi all, Just to introduce myself, I'm working on a project called MonAMI. It does monitoring: aiming to be plumbing between the thing(s) you want to monitor and the monitoring system itself. More details here: http://monami.sourceforge.net/ A little while ago, someone asked for a plugin for Varnish, which turned out to be very simple to implement. I noticed the wiki page has a few links for monitoring (under Performance page). I have a few questions: would it be appropriate to add a link to MonAMI? would anyone be interested in checking whether the plugin is gathering all the correct information and presenting it correctly? For the second part, it would be really good to get feedback from the Varnish developers as I don't run Varnish myself beyond a simple toy setup, (just to verify the plugin works correctly). Cheers, Paul. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: n_smf_large so large -- varnish-dev Digest, Vol 28, Issue 1
In message [EMAIL PROTECTED], chen xiaoyong writes: I found that there are reasons for this phenomenon because it is negative. Not just n_smf_large, including n_smf_frag have this phenomenon too. Perhaps some code of storage_file.c should be some more stringent This is a know problem, and basically we decided that perfect statistics were not as important as fast speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
In message [EMAIL PROTECTED], Theo Schlossnagle writes: http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3071.diff OK, I've picked the obvious stuff out. Various questions about the rest: Doesn't Solaris have fcntl(F_SETLK) as mandated by POSIX ? flock() is not a standardized API, and I havn't seen a system yet which supports it, which doesn't also have fcntl(F_SETLK), so I would rather not mess up the source with a pointless check. Do you know for sure that sendfile on Solaris has no reference to the relevant parts of the file when it returns ? Otherwise it is not safe to use. Why is the extra include of sys/statvfs.h necessary in storage_file.c ? Is there a reason to name the shared object .so instead of .o or is it just cosmetics ? In cache_acceptor.c, please implement the -pass function which does the port_send() call. Why the initialization in mgt_child.c ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
In message [EMAIL PROTECTED], Theo Schlossnagle writes: Next pass: http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3080.diff You still have the err.h compat stuff, that's not necessary any more, I removed the two uses of err(). Why is the tcp.c patch necessay ? You have not answered my questions about .so and sendfile ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
Sorry for the comment at the end of my prevous email, got your emails in reverse order here :-) Doesn't Solaris have fcntl(F_SETLK) as mandated by POSIX ? Ah, good catch. That wasn't a patch for Solaris. It was for Linux. We've run into some issues with flock being more reliable than fcntl on Linux under high concurrency environments. We're not even remotely close to concurrency, so I'd prefer to stick with fcntl until we see any actual problems. Is there a reason to name the shared object .so instead of .o or is it just cosmetics ? The Sun Studio toolchain barfs on the .o. It knows better [...] Ok, fair enough. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: waitpid EINTR issue in varnishd ( testcases)
I have committed the EINTR patch and, I hope, fixed the two testcases, please check this and send me your latest solaris patch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Bug in 1.1.2: Multiple headers stripped (oops)
Hi Adrian,
Good catch.
I created a ticket (#292, now closed) for this because we number
our regression tests by ticket number.
Fixed in #3110.
Poul-Henning
I found the reason why I hit this bug, but I need some tips to
understand how to debug what's happening in the VCL code. First, I'll
explain the bug:
1) My default.vcl is configured to strip the Cookie header in
vcl_recv like this:
sub vcl_recv {
if(req.http.Cookie) {
remove req.http.Cookie;
lookup;
}
}
2) The Connection header sent from the client browser specified that
the TE header should be stripped, and was so marked in position 13
of http_DoConnection::hp-hdf, indicating that header at index 13
should be skipped when headers are copied into the backend request.
3) The VCL code ran to strip the cookie header, removed it, and
shifted the other elements in the array UP one position. The Host
header followed TE at position/index 14, and became position/index 13.
4) The code for copying/morphing the client request to the backend
ran, and skipped position/index 13, which was the Host header.
5) Varnish kindly noticed that there was no Host header present in
the backend connection, and added one of it's own using the IP
address of the backend server as the content of that header.
6) The incorrect document was fetched for the backend because the
Host header was not correct.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: please revise document or code
done. http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching section *How it should work* set obj.ttl = 1w; maybe changed to set obj.ttl = 7d; or in function static double TimeUnit(struct tokenlist *tl) add w Id -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Bug : Assert error in exp_timer() | Child not responding to ping, killing it.
Hi Benjamin, I'll look at it.
Just wanted to point this out in the mean time:
if (req.url ~ ttl=) {
if (req.url ~ ttl=001) { set obj.ttl=3600s; }
if (req.url ~ ttl=002) { set obj.ttl=7200s; }
if (req.url ~ ttl=003) { set obj.ttl=10800s; }
if (req.url ~ ttl=006) { set obj.ttl=21600s; }
if (req.url ~ ttl=009) { set obj.ttl=32400s; }
if (req.url ~ ttl=012) { set obj.ttl=43200s; }
if (req.url ~ ttl=015) { set obj.ttl=54000s; }
if (req.url ~ ttl=018) { set obj.ttl=64800s; }
if (req.url ~ ttl=021) { set obj.ttl=75600s; }
if (req.url ~ ttl=024) { set obj.ttl=86400s; }
if (req.url ~ ttl=096) { set obj.ttl=345600s; }
if (req.url ~ ttl=168) { set obj.ttl=604800s; }
if (req.url ~ ttl=672) { set obj.ttl=2419200s; }
VCL supports other units of time than seconds, so for
increased readability, you could write:
set obj.ttl = 1h;
set obj.ttl = 2h;
...
set obj.ttl = 1d;
...
set obj.ttl = 1w;
set obj.ttl = 4w;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@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.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Bug: Child not responding to ping, killing it.
In message 494a2cb6.2010...@octopuce.fr, Benjamin Sonntag writes: I continue to investigate this problem. It seems that varnish is really keeping ESTABLISHED connexions to the backend for a verryve verry verrry long time : Varnish does not close backend connections, it leaves them open until the backend times them out. How you TCP connections get out of sync between varnish host and backend host I have no idea... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: What's the best way to give feedback for future Varnish features?
In message 4a05e1020903111417w2c175418rd9bcf7a3aef10...@mail.gmail.com, Cloud e Porteus writes: Our testing with Varnish is going great, but the features around ESI that haven't been implemented are going to make things a little bit harder than I had hoped. I was reading the PostTwoShoppingList and saw a request (please tell us which!) after more ESI features, but I'm not sure how to voice my preference. Get a wiki login[1], edit the page. [1] They are free and we happily give them away, but you have to ask so we kan keep spammers away. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: accept_fd_holdoff second/millisecond confusion
Fixed, thanks! Poul-Henning In message 180e6a10903201237y1e86bc00vdd7c7b473a996...@mail.gmail.com, Eden L i writes: Hi all, We ran into a situation where our backend held connections open for so long that we ran into the open file limit. After clearing up the backend and ensuring, varnish never came back and we had to restart it in order for it to start relaying connections again. Flipping on debug mode shows the error Too many open files when accept(2)ing. Sleeping. which should sleep for 50 milliseconds (according to param.show). Instead it seems to be sleeping for 50*1000 *seconds* (13 hours). Looking at the code, it appears that this is either a doc bug or a code bug. I was able to fix the root issue with this patch: --- a/varnish-2.0.1/bin/varnishd/cache_acceptor.c 2008-10-17 11:59:49.0 -0700 +++ b/varnish-2.0.1/bin/varnishd/cache_acceptor.c 2009-03-20 12:16:15.0 -0700 @@ -228,7 +228,7 @@ case EMFILE: VSL(SLT_Debug, ls-sock, Too many open files when accept(2)ing. Sleeping.); - TIM_sleep(params-accept_fd_holdoff * 1000.0); + TIM_sleep(params-accept_fd_holdoff * 0.001); break; default: VSL(SLT_Debug, ls-sock, Is this the right fix? Should I create a ticket in trac for this? We're getting around it now by setting the max open file limit and listen_depth appropriately so that varnish never gets to this point, but it'd be nice if this was fixed in case we ever accidentally get here again. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Huge number for N struct vbe_conn
In message 4a05e1020905200849s3c79f8e3n498b659341e2f...@mail.gmail.com, Cloud e Porteus writes: The vbe_conn is flickering between 0-2 and 18446744073709551615. See varnishstat below. Any ideas what might cause this? Yes, it is an unlocked counter, and you had a race updating it: 18446744073709551615 - 2^64 = -1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: VCL compiler coverage test FAILED
In message 48eba6130906011847x6bea3956nc8951455dfcba...@mail.gmail.com, Beau Burrier writes: ## v1 VCL compilation failed (as expected) ### v1 CLI STATUS 200 v1 VCL compilation got 200 expected 106 TEST FILE: ././tests/v00017.vtc TEST DESCRIPTION: VCL compiler coverage test: vcc_acl.c FAIL: ./tests/v00017.vtc Can you try to run that test by hand with a -v flag ? cd .../bin/varnishtest ./varnishtest -v tests/v00017.vtc -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Handling Dynamic Backend Redirects
In message 4a305b14.7080...@caringo.com, Mike Melson writes: Is there anyway to catch follow a 301 redirect from a backend server to a host that has NOT been defined as a backend in varnish? No. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Backend polling not working
In message 4aded57c.3020...@upfrontsystems.co.za, Izak Burger writes: Hello again, I've discussed this issue on zope-dev. The agreement seems to be that there is some ambiguity in the HTTP1.1 specification, but that the general accepted interpretation is that if the other end closes the connection you should close your end as well (it signals a timeout). There is also no browser implementation out there that does half-closing (except where SSL is involved). None that I know of anyway. I wasn't quite sure which way to interpret the text originally so I did it the way that was most convenient for the code. I'll change it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: bug in esi:include handling (with patch)
In message 19203.62532.605771.461...@bio-iisrv1.bio.ic.ac.uk, Bob MacCallum w rites: Oh, well, at least great minds think alike. Are includes like this supposed to work: esi:include src=http://some.other.site/stuff; / It only works if you have a backend defined for that server. Look at bin/varnistest/tests/e6.vtc for an example. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: HSH_Lookup entered multiply - why could that happen?
In message 4b1ffa7d.3020...@schokola.de, Nils Goroll writes: Hi, what I get is this (URL removed to protect the innocent): 48 VCL_call c recv lookup 48 VCL_call c hash hash 48 Debugc 24115201202978841 8d6278 on waiting list 8b72e0 ##URL## What happens here is that another client/thread holds this object busy while it is being fetched from the backend. Once the object is marked unbusy, the waiting threads are relased, and calls hash again. I'm not quite sure you you keep hitting it so many times, it smells like som weird situation where the object takes a long time to fetch, has no cacheability, but does not get marked pass in vcl_fetch ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: scheduling off the waiting list
In message 4b39210f.7080...@schokola.de, Nils Goroll writes: So basically there are two different scenarios when hsh_rush is called. * Trigger delivery of an object which just got unbusied * and trigger delivery of more sessions which did not fire in the first round The basic point here is that we do not want to unleash 500 waiting sessions when the object is unbusied, so we release a few, and when they are done they each release a few etc. Sort of inspired by TCP-slowstart, but not half as advanced. I'm not entirely happy with how this works in practice, but within the current reach, I have no better ideas. Grace mode helps a lot, if you can use it. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r4480 - trunk/varnish-cache/bin/varnishncsa
In message d38199ba-78a0-4c7a-a26a-a24d070b6...@develooper.com, =?iso-8859-1? Q?Ask_Bj=F8rn_Hansen?= writes: On Feb 1, 2010, at 1:35, Anders Nordby wrote: I must object to this change, as I use varnishncsa -b extensively to pull out reports on missed objects being fetch from the backends too often. Please revert this change, as varnishncsa -b has its use. I don't know why it was removed or if there's a good alternative, but I've found the -b option very useful, too. Well, the code to implement it full was never there, and people were reporting core dumps because of it, so we figured we would make the non-support for -b explicit, until the code could be written. There are no objections to supporting it, it's just code to be written by somebody... (nudge, nudge, wink, wink...) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Literal ip4/6 addresses in VCL
In message 4b93b0ab.4080...@schokola.de, Nils Goroll writes: My main question is if they should be tokenized as CSTRs or rather as new tokens, e.g. of token type IP (not to be confused with variable type IP). The syntax for this is already decided, just not implemented: set client.ip = IP(req.http.x-forwarded-for); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Literal ip4/6 addresses in VCL
In message 4b93b6ea.9010...@schokola.de, Nils Goroll writes: The syntax for this is already decided, just not implemented: set client.ip = IP(req.http.x-forwarded-for); Thank you for pointing this out, so I am going to implement this syntax for the case where runtime conversion is needed. Do you have an opinion regarding the suggestion for the VCL compile time case? There should not be two different syntaxes, the above should be used in both cases. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
