From varnish-bugs at projects.linpro.no Thu Apr 2 09:12:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 02 Apr 2009 09:12:39 -0000 Subject: [Varnish] #467: prevent percent-aspects of munin plugin from scaling In-Reply-To: <050.a304b631f86c5a94e2698d09ae1dfbe2@projects.linpro.no> References: <050.a304b631f86c5a94e2698d09ae1dfbe2@projects.linpro.no> Message-ID: <059.5ebc3b471c0e970b49849e2d761f6e06@projects.linpro.no> #467: prevent percent-aspects of munin plugin from scaling -------------------------+-------------------------------------------------- Reporter: anti | Owner: kristian Type: enhancement | Status: closed Priority: normal | Milestone: Component: munin | Version: trunk Severity: trivial | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => wontfix Comment: The problem with this approach is that many of the percentage-based values might not vary very much. Specially hit-rate, which often dwells in the range of 98-99%, but a variation from 99% hit rate to 96% hit rate is still a 400% increase in backend traffic. These seemingly small variation would be next to impossible to spot on a graph always ranging from 0 to 100%. That being said, you can override almost all variables the plugin sends, see http://munin.projects.linpro.no/wiki/faq#Q:CanIsetoroverridethecriticalandwarninglevelsorotherparametersforaplugin Also: I'm currently re-implementing a munin-plugin for Varnish increase the usability (fewer but better graphs), and concerns like these is beeing re-evaluated with the context of this new plugin. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 2 15:36:06 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 02 Apr 2009 15:36:06 -0000 Subject: [Varnish] #481: Retain information about backends post-vbe_conn destruction for use in VCL Message-ID: <049.3a22865f178967f450d91c73791f29b2@projects.linpro.no> #481: Retain information about backends post-vbe_conn destruction for use in VCL -------------------------+-------------------------------------------------- Reporter: mbm | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: VCL backend -------------------------+-------------------------------------------------- In the VCL "sub fetch {}" function, it's often useful to get information about which backend served the request if a director of some sort is being used. While the vbe_conn is available, this is is in sp->vbe->backend->vcl_name and the information about IPs and ports is in the sp->vbe->backend->ipv4 or ipv6 sockaddr*. Unfortunately by the time the VCL fetch is called, the vbe_conn has been freed, and so sp->vbe is NULL. I've attached a patch (including a new varnishtest testcase) for bereq.backend (which gives the vcl_name element of the backend structure) and bereq.backend_ip (which gives the IP). I should probably have done a bereq.backend_port too - but I didn't need it for our situation and I couldn't work out how to look at the TCL. This isn't as clean as I'd hoped, as in order to make it available to the session you need cache_backend.h available in cache_fetch.c, but possibly it's a starting place, and I think it's useful functionality to have. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 2 15:54:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 02 Apr 2009 15:54:58 -0000 Subject: [Varnish] #481: Retain information about backends post-vbe_conn destruction for use in VCL In-Reply-To: <049.3a22865f178967f450d91c73791f29b2@projects.linpro.no> References: <049.3a22865f178967f450d91c73791f29b2@projects.linpro.no> Message-ID: <058.da4553129eba8421d1aa5515fa6c1542@projects.linpro.no> #481: Retain information about backends post-vbe_conn destruction for use in VCL -------------------------+-------------------------------------------------- Reporter: mbm | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: VCL backend | -------------------------+-------------------------------------------------- Comment (by mbm): It occurs to me to mention that this was against 2.0.3 (as 2.0.4 wasn't out when I was looking at this a few days ago). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 3 23:52:21 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 03 Apr 2009 23:52:21 -0000 Subject: [Varnish] #482: Polling broken on Solaris? Message-ID: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- I don't know how to best describe this so if you need more data, just let me know. OS: Solaris 10, latest patches applied as of March 02, 2009 \ Compiler: Sun Studio 12 The problem is that after installing varnish 2.0.4 we saw a massive increase in 503 errors. After changing the code to return different error codes for the places where varnishd sets the 503 by force internally I could track the problem down to the function `cnt_fetch` in `bin/varnishd/cache_center.c`. Further investigation led me the function `Fetch` in `bin/varnishd/cache_fetch.c`. Our problem is always triggered in line 384 thereof. I suspect the real source is in `HTC_Rx` but neither my programming skills nor my debugging skills did allow me to get any further. While trying to reproduce the problem so I could present you with a solid test case, I found that running the tests provided with `varnishtest` will sometimes run through wihtout any problems and sometimes will fail with {{{ Assert error in http_rxchar(), vtc_http.c line 343: Condition(i > 0) not true. Abort (core dumped) }}} A very relyable way to reproduce this here is to run `r00345.vtc` a couple of times. I never needed more than three runs to get to the core dump. I also found that the behaviour is not related to any specific URL. On the live website I'd get an 503 once but after manually reloading the page in the browser it load just fine. So as a temporary fix I changed the code in `cache_center.c` like this (starting from line 400): {{{ // if (i) { // sp->err_code = 503; // sp->step = STP_ERROR; // VBE_free_bereq(&sp->bereq); // HSH_Drop(sp); // AZ(sp->obj); // return (0); // } // // RFC2616_cache_policy(sp, sp->obj->http); /* XXX -> VCL */ // // sp->err_code = http_GetStatus(sp->obj->http); // VCL_fetch_method(sp); if (i) { sp->handling = VCL_RET_RESTART; } else { RFC2616_cache_policy(sp, sp->obj->http); sp->err_code = http_GetStatus(sp->obj->http); VCL_fetch_method(sp); } }}} This will restart the request and fixes 99% of our problem. The last 1% are cases where we run into "max restarts reached", probably because of hitting the same problem more than 4 times in a row. As said initially: I don't know how to better describe the problem, if you've got any pointers as to how to provide better information, just let me know. I can even provide access to the "live thing" and a development environment on Solaris if need be. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 3 23:53:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 03 Apr 2009 23:53:20 -0000 Subject: [Varnish] #482: Polling broken on Solaris? In-Reply-To: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> References: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> Message-ID: <063.a054cdd22248dadc96f27ee2e9aa2f45@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by whocares): Darn. Component should have been "varnishd" not "build". Sorry for that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Apr 4 17:42:13 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 04 Apr 2009 17:42:13 -0000 Subject: [Varnish] #483: Varnishstat should show the number of healthy / sick backends Message-ID: <049.5a5863373a5c2f76f618144a19240833@projects.linpro.no> #483: Varnishstat should show the number of healthy / sick backends -------------------+-------------------------------------------------------- Reporter: rts | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Hi, With varnishstat, I don't seem to be able to monitor how many of my backends are healthy. For example: [root at serverd ~]# varnishstat -1 |grep -i backend backend_conn 130195 0.45 Backend connections success backend_unhealthy 0 0.00 Backend connections not attempted backend_busy 0 0.00 Backend connections too many backend_fail 0 0.00 Backend connections failures backend_reuse 0 0.00 Backend connections reuses backend_recycle 0 0.00 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_backend 4 . N backends backend_req 130008 0.45 Backend requests made [root at serverd ~]# This says I've four backends, but it's not showing anywhere that 1 of my 4 backends is sick. Is this information available so that it can be added to Zabbix / Nagios? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 5 15:18:12 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 05 Apr 2009 15:18:12 -0000 Subject: [Varnish] #484: Dum5apr2009 Message-ID: <054.9c88df66a8ddab6a297d9c8640909761@projects.linpro.no> #484: Dum5apr2009 ----------------------+----------------------------------------------------- Reporter: R.Daniel | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- Dum5aprilie2009 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 6 12:39:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 06 Apr 2009 12:39:14 -0000 Subject: [Varnish] #455: Make HTTP_HDR_MAX a ./configure option In-Reply-To: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> References: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no> Message-ID: <063.3ecb98d4c8f78de6287030f181aabcfd@projects.linpro.no> #455: Make HTTP_HDR_MAX a ./configure option -------------------------+-------------------------------------------------- Reporter: whocares | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: max headers | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [4030]) Make HTTP_HDR_MAX_VAL a configure option Thanks to "whocares" in the bts. Fixes #455 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 7 09:09:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Apr 2009 09:09:16 -0000 Subject: [Varnish] #485: Virtualhost logging for varnishncsa Message-ID: <052.ad49d79f82c60083d4971a3f23a8564c@projects.linpro.no> #485: Virtualhost logging for varnishncsa ---------------------------------------------------------+------------------ Reporter: rhalff | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: varnishncsa, virtual hosts, apache, logging | ---------------------------------------------------------+------------------ Hi, I've changed the varnishncsa sourcecode to support virtualhost logging. I know in the TODO of varnishncsa there is a future wish for "Log in any format one wants", but I can imagine that would need a total rewrite and takes some time. So in the meantime I have a request to add the virtualhost logging as a commandline option. I've added a -v flag enabling virtualhost style logging In this case the logformat looks like: $ varnishncsa -v www.test.nl 111.222.333.44 - - [03/Apr/2009:11:41:57 +0200] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5)" Notice the 'www.test.nl' being logged. This is the equivalent of this kind apache logging: http://httpd.apache.org/docs/2.0/vhosts/mass.html#simple : LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon http://httpd.apache.org/docs/2.0/vhosts/mass.html#simple.rewrite : LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon So this adds the Host part to the normal kind of logging ncsa is doing. Taken that this is a very common way to log virtual hosts I would say the -v option is not just some hack to suit my own needs, I think it is usefull for others also. Without this I am not able to use awstats the way we used it when we where not using varnish. Attached you will find the diff against the current trunk. Greetings, Rob Halff -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 8 09:20:44 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Apr 2009 09:20:44 -0000 Subject: [Varnish] #482: Polling broken on Solaris? In-Reply-To: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> References: <054.052dec7f4afd1cb39cf1d864e8451457@projects.linpro.no> Message-ID: <063.362cf607c7e1ff4a33f9708cf63a7f1b@projects.linpro.no> #482: Polling broken on Solaris? ----------------------+----------------------------------------------------- Reporter: whocares | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * owner: => phk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 9 20:06:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 09 Apr 2009 20:06:02 -0000 Subject: [Varnish] #486: link failure with --as-needed Message-ID: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> #486: link failure with --as-needed --------------------------+------------------------------------------------- Reporter: thilobangert | Type: enhancement Status: new | Priority: low Milestone: | Component: build Version: 2.0 | Severity: minor Keywords: | --------------------------+------------------------------------------------- when building varnish with the --as-needed linker option (LDFLAGS="-Wl ,--as-needed") the build process fails with the following error: {{{ i686-pc-linux-gnu-gcc -O2 -march=i686 -pipe -Wl,--as-needed -o .libs/varnishadm varnishadm.o ../../lib/libvarnish/.libs/libvarnish.so ../../lib/libvarnishcompat/.libs/libvarnishcompat.so -lpthread -lnsl ../../lib/libvarnish/.libs/libvarnish.so: undefined reference to `strlcpy' }}} for more info about linking with --as-needed refert to http://www.gentoo.org/proj/en/qa/asneeded.xml -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 14 09:04:08 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 14 Apr 2009 09:04:08 -0000 Subject: [Varnish] #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 Message-ID: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am running Varnish trunk/4032 in FreeBSD/amd64 7.1-RELEASE. When starting it, I very quickly crashes: {{{ Child (30533) Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159: Condition(ws->f + b2 <= ws->e) not true. thread = (cache-worker)sp = 0x806173008 { fd = 28, id = 28, xid = 803364164, client = 81.167.162.75:4097, step = STP_FETCH, handling = fetch, err_code = 200, err_reason = (null), ws = 0x806173070 { id = "sess", {s,f,r,e} = {0x806173800,,+697,0x0,+16384}, }, worker = 0x7ffffedf72c0 { }, vcl = { srcname = { "input", "Default", }, }, }, Child cleanup complete }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 15 06:54:19 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 15 Apr 2009 06:54:19 -0000 Subject: [Varnish] #488: child process restart with "Missing errorhandling code in sma_alloc()" error Message-ID: <054.386047a0e4bbadb3775f5bff7b9e6a68@projects.linpro.no> #488: child process restart with "Missing errorhandling code in sma_alloc()" error ----------------------+----------------------------------------------------- Reporter: flyincat | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: storage_malloc.c restart ----------------------+----------------------------------------------------- I'm running with varnish 2.0.4, as I found that my varnish restart the child process every few hours(or minutes). Meanwhile I got this error in /var/log/message.My cache server now get just 400-500req/s at the peak. {{{ Apr 15 06:05:34 varnish /srv/vcache[9292]: Child (9293) died signal=6 Apr 15 06:05:34 varnish /srv/vcache[9292]: Child (9293) Panic message: Missing errorhandling code in sma_alloc(), storage_malloc.c line 79: Condition((sma->s.ptr) != 0) not true. errno = 12 (Cannot allocate memory) thread = (cache-worker)sp = 0x71a42004 { fd = 4218, id = 4218, xid = 2057707839, client = 116.30.99.238:12844, step = STP_LOOKUP, handling = hash, ws = 0x71a4204c { id = "sess", {s,f,r,e} = {0x71a42534,,+672,(nil),+16384}, }, worker = 0x1f5f30d8 { }, vcl = { srcname = { "input", "Default", }, }, }, }}} BTW: I started varnish by {{{ /usr/varnish/sbin/varnishd -n /srv/vcache -f /usr/varnish/etc/varnish/default.vcl -a 10.10.10.25:80 -s malloc,3328M -u www -w2,51200,30 -T 127.0.0.1:3500 -p client_http11 on -p thread_pools 4 -p lru_interval 3600 -p obj_workspace 10240 -h classic,19997 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 16 12:31:47 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 16 Apr 2009 12:31:47 -0000 Subject: [Varnish] #489: Assert error in BAN_CheckObject() Message-ID: <053.65e8f271d563b39373a0dceafa2381f0@projects.linpro.no> #489: Assert error in BAN_CheckObject() ---------------------+------------------------------------------------------ Reporter: waschtl | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: major Keywords: | ---------------------+------------------------------------------------------ The following problem has been observed in r3965, as well as r4033: Periodically, at irregular intervals, varnish on a production server will issue the following error, and restart. As you know, this causes varnish to lose the cache, and subsequently the website is not very usable for several minutes afterwards. {{{ Apr 15 22:41:49 varnishd[11662]: Child (11663) died signal=6 Apr 15 22:41:49 varnishd[11662]: Child (11663) Panic message: Assert error in BAN_CheckObject(), cache_ban.c line 423: Condition((o->ban) != NULL) not true. thread = (cache-worker)sp = 0x2aaaf504b008 { fd = 9, id = 9, xid = 1986591368, client = 127.0.0.1:44680, step = STP_LOOKUP, handling = hash, ws = 0x2aaaf504b070 { id = "sess", {s,f,r,e} = {0x2aaaf504b800,,+297,(nil),+16384}, }, worker = 0x4600a430 { }, vcl = { srcname = { "input", "Default", }, }, }, Apr 15 22:41:49 varnishd[11662]: Child cleanup complete Apr 15 22:41:49 varnishd[11662]: child (20389) Started Apr 15 22:41:49 varnishd[11662]: Child (20389) said Closed fds: 4 5 6 9 10 12 13 Apr 15 22:41:49 varnishd[11662]: Child (20389) said Child starts Apr 15 22:41:49 varnishd[11662]: Child (20389) said managed to mmap 1073741824 bytes of 1073741824 Apr 15 22:41:49 varnishd[11662]: Child (20389) said Ready }}} This was previously also observed at the following times: {{{ * r3965 Mar 10 06:21:27 Mar 18 10:37:45 Mar 28 07:59:44 Mar 28 11:52:40 Mar 30 16:41:45 Apr 1 11:41:25 Apr 6 09:47:34 Apr 6 15:29:26 Apr 6 21:10:02 Apr 7 10:50:43 Apr 7 22:05:46 Apr 9 06:56:42 Apr 9 13:16:57 Apr 9 19:53:26 * update to r4033 Apr 15 22:41:49 }}} Varnish is serving a plone website using pound for loadbalancing. The website serves up to 80,000 GET-requests per hour. Varnish is running on a dual-quad-core machine using Intel E5420 processors @2.5 GHz with 16 GB RAM, where varnish has a 1 GB cache. If you need further specifics to debug the problem, I will gladly provide them. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 16 18:36:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 16 Apr 2009 18:36:56 -0000 Subject: [Varnish] #490: Hash based director Message-ID: <053.ca02c4e0130bdbcc5df982693505b980@projects.linpro.no> #490: Hash based director -------------------------+-------------------------------------------------- Reporter: fredrik | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- This is a suggestion for an enhancement on directors. Currently there are only round robin and random directors in varnish. The suggestion is to add a hash director witch can direct traffic to a each server based on the url, so each backend only get their portion of the traffic. This makes it possible to have 3 backend servers where they together makes up a cache pool. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 16 18:44:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 16 Apr 2009 18:44:26 -0000 Subject: [Varnish] #490: Hash based director In-Reply-To: <053.ca02c4e0130bdbcc5df982693505b980@projects.linpro.no> References: <053.ca02c4e0130bdbcc5df982693505b980@projects.linpro.no> Message-ID: <062.a106f036005891d973462a1b80de036a@projects.linpro.no> #490: Hash based director -------------------------+-------------------------------------------------- Reporter: fredrik | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => invalid Comment: This is already listed at: http://varnish.projects.linpro.no/wiki/PostTwoShoppingList#a2.Hashdirector -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 20 02:44:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 20 Apr 2009 02:44:43 -0000 Subject: [Varnish] #488: child process restart with "Missing errorhandling code in sma_alloc()" error In-Reply-To: <054.386047a0e4bbadb3775f5bff7b9e6a68@projects.linpro.no> References: <054.386047a0e4bbadb3775f5bff7b9e6a68@projects.linpro.no> Message-ID: <063.5af5797a9a444c5c0910182f8468105d@projects.linpro.no> #488: child process restart with "Missing errorhandling code in sma_alloc()" error --------------------------------------+------------------------------------- Reporter: flyincat | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: storage_malloc.c restart | --------------------------------------+------------------------------------- Comment (by flyincat): after I changed some parameters of the start command, the situation had some change. This info shows frequently. {{{ Child (29274) Panic message: Missing errorhandling code in sma_alloc(), storage_malloc.c line 79: Condition((sma->s.ptr) != 0) not true. errno = 12 (Cannot allocate memory) thread = (cache-worker)sp = 0xa9f1b004 { fd = 4345, id = 4345, xid = 694019220, client = 125.220.153.163:50203, step = STP_FETCH, handling = fetch, ws = 0xa9f1b04c { id = "sess", {s,f,r,e} = {0xa9f1b534,,+404,(nil),+16384}, }, worker = 0x475ff0d8 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x1b9f2000 { refcnt = 1, xid = 694019220, ws = 0x1b9f2018 { id = "obj", {s,f,r,e} = {0x1b9f21ec,,+236,(nil),+11796}, }, http = { ws = 0x1b9f2018 { id = "obj", {s,f,r,e} = {0x1b9f21ec,,+236,(nil),+11796}, }, hd = { "Cache- Control: private", "Content-Type: application/zip", "Server: Microsoft-IIS/6.0", "X-Powered-By: ASP.NET", "X }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 20 12:38:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 20 Apr 2009 12:38:57 -0000 Subject: [Varnish] #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 In-Reply-To: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> References: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> Message-ID: <061.1fc1fa4628daa6d3e6e6ad402c3514a4@projects.linpro.no> #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): I get this backtrace when hooking gdb to the child process: {{{ Program received signal SIGABRT, Aborted. [Switching to Thread 0x806207c00 (LWP 100696)] 0x0000000800d298bc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000800d298bc in thr_kill () from /lib/libc.so.7 #1 0x0000000800db8a0b in abort () from /lib/libc.so.7 #2 0x000000000041ff92 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:317 #3 0x000000000042a45e in WS_Reserve (ws=0x7ffffa1d1788, bytes=16384) at cache_ws.c:159 #4 0x000000000041e55e in HTC_Init (htc=0x7ffffa1d1758, ws=0x7ffffa1d1788, fd=Variable "fd" is not available. ) at cache_httpconn.c:92 #5 0x0000000000418582 in FetchHdr (sp=0x806980008) at cache_fetch.c:369 #6 0x0000000000410f9f in cnt_fetch (sp=0x806980008) at cache_center.c:403 #7 0x0000000000412617 in CNT_Session (sp=0x806980008) at steps.h:41 #8 0x0000000000421c21 in wrk_do_cnt_sess (w=0x7ffffa1d12c0, priv=Variable "priv" is not available. ) at cache_pool.c:456 #9 0x0000000000420f17 in wrk_thread_real (qp=0x800f277e0, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:351 #10 0x0000000800ab0a27 in pthread_getprio () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffa1d2000: Bad address. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 20 13:12:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 20 Apr 2009 13:12:10 -0000 Subject: [Varnish] #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 In-Reply-To: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> References: <052.5745bc31c6e53077077706427ebbd00d@projects.linpro.no> Message-ID: <061.0b59dd957d6d15252064a6b2979732b5@projects.linpro.no> #487: Varnish crashes on Panic message: Missing errorhandling code in WS_Reserve(), cache_ws.c line 159 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by anders): Further info from the backtrace: {{{ (gdb) frame 5 #5 0x0000000000418582 in FetchHdr (sp=0x806980008) at cache_fetch.c:369 369 HTC_Init(sp->wrk->htc, sp->wrk->ws, vc->fd); (gdb) print sp->wrk->ws $1 = {{magic = 905626964, id = 0x43eaa2 "wrk", s = 0x7ffffa1c7260 "X-Varnish: 1311546835", f = 0x7ffffa1cb431 "", r = 0x0, e = 0x7ffffa1cf260 "", overflow = 0}} (gdb) print *sp->wrk->ws $2 = {magic = 905626964, id = 0x43eaa2 "wrk", s = 0x7ffffa1c7260 "X-Varnish: 1311546835", f = 0x7ffffa1cb431 "", r = 0x0, e = 0x7ffffa1cf260 "", overflow = 0} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 21 14:49:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 21 Apr 2009 14:49:56 -0000 Subject: [Varnish] #491: Crash in 2.0.4 Message-ID: <049.380185abc8ca16a6d9ca861023e16bf3@projects.linpro.no> #491: Crash in 2.0.4 --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Keywords: --------------------+------------------------------------------------------- {{{ Panic message: Assert error in WS_Release(), cache_ws.c line 170: Condition(bytes <= ws->e - ws->f) not true. thread = (cache-worker)sp = 0x7f4ff0277008 { fd = 1043, id = 1043, xid = 1662105498, client = 208.68.167.134:35521, step = STP_FETCH, handling = error, err_code = 200, err_reason = (null), ws = 0x7f4ff0277078 { id = "sess", {s,f,r,e} = {0x7f4ff0277808,,+3354,(nil),+32768}, }, worker = 0x7f52e9083be0 { }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f6d71a0b000 { refcnt = 1, xid = 1662105498, ws = 0x7f6d71a0b028 { id = "obj", {s,f,r,e} = {0x7f6d71a0b358,,+327,+3240,+3240}, }, http = { ws = 0x7f6d71a0b028 { id = "obj", {s,f,r,e} = {0x7f6d71a0b358,,+327,+3240,+3240}, }, hd = { "Date: Tue, 21 Apr 2009 10:01:29 GMT", "Server: Apache", "Content-language: en", "X-Served-By-Backend: }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 22 03:12:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 22 Apr 2009 03:12:10 -0000 Subject: [Varnish] #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance Message-ID: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance -------------------------+-------------------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: cache_acceptor_epoll.c cache_waiter_epoll.c performance linux epoll -------------------------+-------------------------------------------------- Hi. I have made major changes in cache_acceptor_epoll.c / cache_waiter_epoll.c in order for those to look more alike kqueue's version. These changes can make a Linux box achieve a much better performance than one running the unpatched (original) Varnish 2.0.4 or even trunk r4034. The previous versions of cache_waiter_epoll.c have this police of "checking for timeouts only each 60 seconds". This is problematic because if you want to set a smaller amount of idle timeout it will not be respected most of the time. Also the default (5s) idle timeout (sess_timeout) isn't respected using this approach. This scenario can cause your server to run out of Varnish's open file descriptors limit (hard limited in shmlog.c, at line 85, to 65536 or 0x10000 in hexa). In order to not running into this limitation I have changed the entire cache_waiter_epoll.c to take care of sess_timeout(ed) sockets more frequently, each 100ms (just like cache_waiter_kqueue.c), and in a smarter way, not doing a FOR_EACH in the session list each time we check for timeouts, but checking for timeouts only in the older entries, what should be ok, since the newer sessions are more likely to do not expire so early (once again, just like cache_waiter_kqueue.c). What should be different (and better) with this patch: - Sustained performance. We do not have the cost of doing a FOR_EACH sessions each time we check for timeouted sockets. This new approach is cheaper and do not impact the performance. In older versions this routine of checking all sessions could degrade the performance badly. I have seen degradation in order of reducing the capacity of handling new requests by 50% during that 1 or 2 seconds the older versions spent each 60s. This one do not suffer from that any more. - Respecting sess_timeout. Since the previous versions only checks for idle timeout each 60 seconds, the configured sess_timeout could not be respected in most cases. This version checks sess_timeout(ed) connections each 100ms, in a smarter and cheaper way, ensuring to respect the desired idle timeout and keeping the open sockets number as low as possible. - Not running out of open fds limitation (SO's or Varnish's, wich came first) so soon. - Handles more than just one session event per iteration. This version can handle up to 100 session activities per event loop for each epoll_wait() syscall. - Uses Edge-Trigger (EPOLLET) for internal (pipe) session passing. - Uses one-shot (EPOLLONESHOT) for handling session activities. Regards, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 22 03:21:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 22 Apr 2009 03:21:34 -0000 Subject: [Varnish] #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance In-Reply-To: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> References: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> Message-ID: <062.407f68d6e17e0e05b5a9402e5786d048@projects.linpro.no> #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance ---------------------------------------------------------------------------------+ Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: cache_acceptor_epoll.c cache_waiter_epoll.c performance linux epoll | ---------------------------------------------------------------------------------+ Comment (by stockrt): Posting the description of changes again due to bad formatting: What should be different (and better) with this patch: - Sustained performance. We do not have the cost of doing a FOR_EACH sessions each time we check for timeouted sockets. This new approach is cheaper and do not impact the performance. In older versions this routine of checking all sessions could degrade the performance badly. I have seen degradation in order of reducing the capacity of handling new requests by 50% during that 1 or 2 seconds the older versions spent each 60s. This one do not suffer from that any more. - Respecting sess_timeout. Since the previous versions only checks for idle timeout each 60 seconds, the configured sess_timeout could not be respected in most cases. This version checks sess_timeout(ed) connections each 100ms, in a smarter and cheaper way, ensuring to respect the desired idle timeout and keeping the open sockets number as low as possible. - Not running out of open fds limitation (SO's or Varnish's, wich came first) so soon. - Handles more than just one session event per iteration. This version can handle up to 100 session activities per event loop for each epoll_wait() syscall. - Uses Edge-Trigger (EPOLLET) for internal (pipe) session passing. - Uses one-shot (EPOLLONESHOT) for handling session activities. Regards, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 04:22:14 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 04:22:14 -0000 Subject: [Varnish] #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance In-Reply-To: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> References: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> Message-ID: <062.3742b27a3be7015926f7e9136ebcaeb2@projects.linpro.no> #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance ---------------------------------------------------------------------------------+ Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: cache_acceptor_epoll.c cache_waiter_epoll.c performance linux epoll | ---------------------------------------------------------------------------------+ Comment (by stockrt): Hi, I have made some changes and uploaded the new files. The important ones are the patches, for release 2.0.4 and trunk r4034, the others are just the entire files (acceptor/waiter for epoll and cache.h) if someone want them this way. Regards, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 06:09:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 06:09:26 -0000 Subject: [Varnish] #493: sgdfjgh Message-ID: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> #493: sgdfjgh -------------------------------+-------------------------------------------- Reporter: 1987618girl | Type: defect Status: new | Priority: normal Milestone: After Varnish 2.1 | Component: build Version: trunk | Severity: normal Keywords: | -------------------------------+-------------------------------------------- nbfgmh, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 06:09:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 06:09:50 -0000 Subject: [Varnish] #493: sgdfjgh In-Reply-To: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> References: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> Message-ID: <066.d4a87ba759e4acd122e9c852a174524e@projects.linpro.no> #493: sgdfjgh -------------------------+-------------------------------------------------- Reporter: 1987618girl | Owner: Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by 1987618girl): sdgdfjhg -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 06:10:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 06:10:20 -0000 Subject: [Varnish] #493: sgdfjgh In-Reply-To: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> References: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> Message-ID: <066.2c8935c6ccecf262c4e9d5509450046a@projects.linpro.no> #493: sgdfjgh -------------------------+-------------------------------------------------- Reporter: 1987618girl | Owner: Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by 1987618girl): Replying to [comment:1 1987618girl]: > sdgdfjhg fdshgfkh -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 06:10:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 06:10:57 -0000 Subject: [Varnish] #493: sgdfjgh In-Reply-To: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> References: <057.a96f9760da6bb40e84281a4789d2b971@projects.linpro.no> Message-ID: <066.18b5d2389c4c8200d637e76a951f6fd7@projects.linpro.no> #493: sgdfjgh -------------------------+-------------------------------------------------- Reporter: 1987618girl | Owner: Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by 1987618girl): sdghfj -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 06:29:58 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 06:29:58 -0000 Subject: [Varnish] #465: regsub seems no use in sub_recv as a hash key In-Reply-To: <054.718ef071bbedab1d4b361c82b70a7e9e@projects.linpro.no> References: <054.718ef071bbedab1d4b361c82b70a7e9e@projects.linpro.no> Message-ID: <063.dc4d49b7cad09ab40c0822120712693b@projects.linpro.no> #465: regsub seems no use in sub_recv as a hash key --------------------------+------------------------------------------------- Reporter: flyincat | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: hash req.url | --------------------------+------------------------------------------------- Changes (by 1987618girl): * status: closed => reopened * resolution: worksforme => Comment: ujygkhu;.kj fdhgfhgfjghkjhjl == ==[][www.baidu.com] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 06:36:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 06:36:16 -0000 Subject: [Varnish] #225: VCL: Allow "Expires" time to be easily specified / calculated In-Reply-To: <055.0cde52996ac6ba2ef45b86c02b1cf8be@projects.linpro.no> References: <055.0cde52996ac6ba2ef45b86c02b1cf8be@projects.linpro.no> Message-ID: <064.7e3a9d52873930154c3ceb58bd37c161@projects.linpro.no> #225: VCL: Allow "Expires" time to be easily specified / calculated -------------------------+-------------------------------------------------- Reporter: cyberduck | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by 1987618girl): b .hg -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 11:36:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 11:36:54 -0000 Subject: [Varnish] #493: varnish-tools/regress broken Message-ID: <051.8b028e6dd7e5c51c90ba0cc07d3f50ad@projects.linpro.no> #493: varnish-tools/regress broken -------------------+-------------------------------------------------------- Reporter: bolav | Type: defect Status: new | Priority: normal Milestone: | Component: regress Version: 2.0 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- varnish-tools/regress is broken. Old vcl-format, and depends on Rolling(2)... output, which is old. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 17:38:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 17:38:26 -0000 Subject: [Varnish] #494: When backend server continues a header line with \n\t rather than \r\n\t remove only removes first line of header Message-ID: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no> #494: When backend server continues a header line with \n\t rather than \r\n\t remove only removes first line of header ----------------------+----------------------------------------------------- Reporter: lrowe | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- This seems to be the result of a bug in Zope 2.10.7 that has been fixed in svn. The headers from Zope look like thisL {{{ $ curl --header "Accept-Encoding: gzip" --include http://127.0.0.1:8080/www/qt-in-use HTTP/1.1 200 OK Server: Zope/(Zope 2.10.7-final, python 2.4.6, darwin) ZServer/1.1 Plone/3.2.2 Date: Thu, 23 Apr 2009 17:31:18 GMT Content-Length: 7375 Content-Language: en Content-Encoding: gzip Expires: Mon, 26 Apr 1999 17:31:17 GMT Vary: Accept-Encoding, Accept-Encoding Last-Modified: Tue, 10 Mar 2009 13:17:11 GMT X-Caching-Rule-Id: plone-content-types Cache-Control: max-age=0, s-maxage=86400, must-revalidate, proxy- revalidate Content-Type: text/html;charset=utf-8 X-Header-Set-Id: cache-in-proxy-24-hours Set-Cookie: I18N_LANGUAGE="en"; Path=/ }}} Note that Vary here is "Accept-Encoding,\n\tAccept-Encoding" The headers from Varnish look like this: {{{ $ curl --header "Accept-Encoding: gzip" --include http://127.0.0.1:8000 /qt-in-use HTTP/1.1 200 OK Server: Zope/(Zope 2.10.7-final, python 2.4.6, darwin) ZServer/1.1 Plone/3.2.2 Content-Language: en Content-Encoding: gzip Accept-Encoding Last-Modified: Tue, 10 Mar 2009 13:17:11 GMT X-Caching-Rule-Id: plone-content-types Content-Type: text/html;charset=utf-8 X-Header-Set-Id: cache-in-proxy-24-hours Content-Length: 7367 Vary: Accept-Encoding,Accept-Language Date: Thu, 23 Apr 2009 17:33:32 GMT X-Varnish: 192199513 192199510 Via: 1.1 varnish Connection: keep-alive X-Varnish-Age: 1679 Age: 0 Cache-Control: max-age=300, s-maxage=0, must-revalidate, proxy-revalidate }}} VCL: {{{ backend default { .host = "127.0.0.1"; .port = "8080"; } # Do NOT add localhost to the purce acl list # All requests to varnish from external users # will appear from localhost (from nginx and haproxy). acl purge { "localhost"; } sub vcl_recv { # This url will always reply 200 whenever varnish is running if (req.request == "GET" && req.url ~ "/varnish-ping") { error 200 "OK"; } # XXX for local testing set req.url = "/VirtualHostBase/http/127.0.0.1:8000/www/VirtualHostRoot" req.url; # Instead of lookup do purge_url to be sure we purge all the different varys if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } purge_url(req.url); error 200 "Purged"; } # # Normalize Accept headers, to vary on Accept-Encoding,Accept-Language # if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|png|gif|swf|pdf|gz|tgz|bz2|tbz|zip)$" || req.url ~ "/image_[^/]*$") { # No point in compressing these remove req.http.Accept-Encoding; } elsif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } else { remove req.http.Accept-Encoding; } } # We only care about the language in the I18N_LANGUAGE cookie if (req.http.Cookie ~ "(^|.*; )I18N_LANGUAGE=") { set req.http.Accept-Language = regsub(req.http.Cookie, "(^|.*; )I18N_LANGUAGE=([^;]*)(; .*|$)", "\2"); # XXX need to work out the proper way to match " here, e.g. "en" set req.http.Accept-Language = regsub(req.http.Accept-Language, "^.(.*).$", "\1"); } else { set req.http.Accept-Language = "en"; } # # Normalize Cookies # if (req.http.Cookie) { set req.http.X-Original-Cookie = req.http.Cookie; # Removing cookies from certain file types if (req.request == "GET" && (req.url ~ "\.(gif|jpg|swf|css|js|png|pdf)$" || req.url ~ "/image_[^/]*$")) { remove req.http.Cookie; } else { # Simplify tokenization set req.http.Cookie = "; " req.http.Cookie; # Remove I18N_LANGUAGE, osas and google analytics cookies set req.http.Cookie = regsuball(req.http.Cookie, "; (I18N_LANGUAGE|osas_id|__utm.)=[^;]*", ""); # Finally remove cookie header if it is now empty if (!req.http.Cookie ~ "[^ ;]") { remove req.http.Cookie; } else { # Remove the leading delimiter set req.http.Cookie = regsub(req.http.Cookie, "^; ", ""); } } } set req.grace = 360s; } sub restore_language { # Put back the I18N_LANGUAGE cookie we removed earlier (%22 is ") if (req.http.Cookie) { set bereq.http.Cookie = req.http.Cookie "; I18N_LANGUAGE=%22" req.http .Accept-Language "%22"; } else { set bereq.http.Cookie = "I18N_LANGUAGE=%22" req.http.Accept-Language "%22"; } } sub vcl_miss { call restore_language; } sub vcl_pass { call restore_language; } sub vcl_hit { } sub vcl_fetch { # Ref. #22479 if (obj.status == 302 && obj.http.Location ~ "^http://www.qtsoftware.com/acl_users") { set obj.http.X-Accel-Redirect = "/error404"; set obj.status = 200; remove obj.http.Location; deliver; } # Removing cookies from certain file types if (req.request == "GET" && (req.url ~ "\.(gif|jpg|swf|css|js|png|pdf)$" || req.url ~ "/image_[^/]*$")) { remove obj.http.set-cookie; } elsif (obj.http.Vary || obj.http.X-Header-Set-Id == "cache-hack- for-24-hours") { # There is some weirdness deep in ZPublisher that needs working around set obj.http.Vary = "Accept-Encoding,Accept-Language"; } set req.grace = 360s; # # Disable client side caching # set obj.http.cache-control = "max-age=0, s-maxage=0, must-revalidate"; } sub vcl_deliver { if (resp.http.Age) { # By definition we have a fresh object set resp.http.X-Varnish-Age = resp.http.Age; set resp.http.Age = "0"; } # rewrite s-maxage so intermediary proxies don't use it if (resp.http.Cache-Control ~ "s-maxage") { set resp.http.Cache-Control = regsub(resp.http.Cache-Control, "s-maxage=[0-9]+", "s-maxage=0"); } # rewrite maxage we at least cache for 5 minutes if (resp.http.Cache-Control ~ "max-age=0") { set resp.http.Cache-Control = regsub(resp.http.Cache-Control, "max- age=0", "max-age=300"); remove resp.http.Expires; } } }}} Varnishlog: {{{ 10 SessionOpen c 127.0.0.1 59535 127.0.0.1:8000 10 ReqStart c 127.0.0.1 59535 1479748637 10 RxRequest c GET 10 RxURL c /qt-in-use 10 RxProtocol c HTTP/1.1 10 RxHeader c Host: 127.0.0.1:8000 10 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 10 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 RxHeader c Accept-Language: no,an;q=0.8,en-gb;q=0.5,en;q=0.3 10 RxHeader c Accept-Encoding: gzip,deflate 10 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 RxHeader c Keep-Alive: 300 10 RxHeader c Connection: keep-alive 10 RxHeader c Referer: http://127.0.0.1:8000/products 10 RxHeader c Cookie: __utma=96992031.3070035466335688000.1240418157.1240493161.1240506194.4; __utmc=96992031; __utmz=96992031.1240489309.2.2.utmcsr=localhost:8000|utmccn=(referral)|utmcmd=referral|utmcct=/; osas_id=124041815941677170; I18N_LANGUAGE="en"; __utmb=969920 10 RxHeader c Pragma: no-cache 10 RxHeader c Cache-Control: no-cache 10 VCL_call c recv 10 VCL_return c lookup 10 VCL_call c hash 10 VCL_return c hash 10 VCL_call c miss 10 VCL_return c fetch 11 BackendOpen b default 127.0.0.1 59536 127.0.0.1 8080 10 Backend c 11 default default 11 TxRequest b GET 11 TxURL b /VirtualHostBase/http/127.0.0.1:8000/www/VirtualHostRoot/qt-in-use 11 TxProtocol b HTTP/1.1 11 TxHeader b Host: 127.0.0.1:8000 11 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 11 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 11 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 11 TxHeader b Referer: http://127.0.0.1:8000/products 11 TxHeader b Pragma: no-cache 11 TxHeader b Accept-Encoding: gzip 11 TxHeader b Accept-Language: en 11 TxHeader b X-Original-Cookie: __utma=96992031.3070035466335688000.1240418157.1240493161.1240506194.4; __utmc=96992031; __utmz=96992031.1240489309.2.2.utmcsr=localhost:8000|utmccn=(referral)|utmcmd=referral|utmcct=/; osas_id=124041815941677170; I18N_LANGUAGE="en"; __ 11 TxHeader b X-Varnish: 1479748637 11 TxHeader b X-Forwarded-For: 127.0.0.1 11 TxHeader b Cookie: I18N_LANGUAGE="en" 11 RxProtocol b HTTP/1.1 11 RxStatus b 200 11 RxResponse b OK 11 RxHeader b Server: Zope/(Zope 2.10.7-final, python 2.4.6, darwin) ZServer/1.1 Plone/3.2.2 11 RxHeader b Date: Thu, 23 Apr 2009 17:37:16 GMT 11 RxHeader b Content-Length: 7367 11 RxHeader b Content-Language: en 11 RxHeader b Content-Encoding: gzip 11 RxHeader b Expires: Mon, 26 Apr 1999 17:37:16 GMT 11 RxHeader b Vary: Accept-Encoding, 11 RxHeader b Accept-Encoding 11 RxHeader b Last-Modified: Tue, 10 Mar 2009 13:17:11 GMT 11 RxHeader b X-Caching-Rule-Id: plone-content-types 11 RxHeader b Cache-Control: max-age=0, s-maxage=86400, must- revalidate, proxy-revalidate 11 RxHeader b Content-Type: text/html;charset=utf-8 11 RxHeader b X-Header-Set-Id: cache-in-proxy-24-hours 10 ObjProtocol c HTTP/1.1 10 ObjStatus c 200 10 ObjResponse c OK 10 ObjHeader c Server: Zope/(Zope 2.10.7-final, python 2.4.6, darwin) ZServer/1.1 Plone/3.2.2 10 ObjHeader c Date: Thu, 23 Apr 2009 17:37:16 GMT 10 ObjHeader c Content-Language: en 10 ObjHeader c Content-Encoding: gzip 10 ObjHeader c Expires: Mon, 26 Apr 1999 17:37:16 GMT 10 ObjHeader c Vary: Accept-Encoding, 10 ObjHeader c Accept-Encoding 10 ObjHeader c Last-Modified: Tue, 10 Mar 2009 13:17:11 GMT 10 ObjHeader c X-Caching-Rule-Id: plone-content-types 10 ObjHeader c Cache-Control: max-age=0, s-maxage=86400, must- revalidate, proxy-revalidate 10 ObjHeader c Content-Type: text/html;charset=utf-8 10 ObjHeader c X-Header-Set-Id: cache-in-proxy-24-hours 11 BackendReuse b default 10 TTL c 1479748637 RFC 86400 1240508236 0 0 86400 0 10 VCL_call c fetch 10 VCL_return c deliver 10 Length c 7367 10 VCL_call c deliver 10 VCL_return c deliver 10 TxProtocol c HTTP/1.1 10 TxStatus c 200 10 TxResponse c OK 10 TxHeader c Server: Zope/(Zope 2.10.7-final, python 2.4.6, darwin) ZServer/1.1 Plone/3.2.2 10 TxHeader c Content-Language: en 10 TxHeader c Content-Encoding: gzip 10 TxHeader c Accept-Encoding 10 TxHeader c Last-Modified: Tue, 10 Mar 2009 13:17:11 GMT 10 TxHeader c X-Caching-Rule-Id: plone-content-types 10 TxHeader c Content-Type: text/html;charset=utf-8 10 TxHeader c X-Header-Set-Id: cache-in-proxy-24-hours 10 TxHeader c Content-Length: 7367 10 TxHeader c Vary: Accept-Encoding,Accept-Language 10 TxHeader c Date: Thu, 23 Apr 2009 17:37:16 GMT 10 TxHeader c X-Varnish: 1479748637 10 TxHeader c Via: 1.1 varnish 10 TxHeader c Connection: keep-alive 10 TxHeader c X-Varnish-Age: 0 10 TxHeader c Age: 0 10 TxHeader c Cache-Control: max-age=300, s-maxage=0, must- revalidate, proxy-revalidate 10 ReqEnd c 1479748637 1240508236.245735884 1240508236.643460035 0.000218868 0.397611141 0.000113010 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 17:41:38 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 17:41:38 -0000 Subject: [Varnish] #494: When backend server continues a header line with \n\t rather than \r\n\t remove only removes first line of header In-Reply-To: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no> References: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no> Message-ID: <060.a0ee12e5eb3b07c350426a3f171e6747@projects.linpro.no> #494: When backend server continues a header line with \n\t rather than \r\n\t remove only removes first line of header ----------------------+----------------------------------------------------- Reporter: lrowe | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by lrowe): Actually, it's not the remove as such but this set: {{{ set obj.http.Vary = "Accept-Encoding,Accept-Language"; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 23 22:21:21 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Apr 2009 22:21:21 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition Message-ID: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition -------------------+-------------------------------------------------------- Reporter: cra | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- When Varnish talks to a backend that uses HTTP/1.0 (no connection keep- alives) it relies on the backend to close the connection. Similarly when Varnish sends the 'Connection: closed' header to the backend it only waits for the backend to close the connection. In both cases while the connection to the backend is still open Varnish may try to reuse it. If the reuse happens it will most likely result in a 503 error to the client (depending on how the backend server handles it, I guess). Varnish should be smart enough to not try to reuse a connection that by RFC standards will be closed, and/or there should be way to configure Varnish to not reuse backend connections. The suggested [http://varnish.projects.linpro.no/wiki/VCLExamplePipe pipe backend fix] and [http://varnish.projects.linpro.no/ticket/451 related ticket] are relevant to this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 05:07:53 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 05:07:53 -0000 Subject: =?utf-8?b?W1Zhcm5pc2hdICM0OTY6IOaJjQ==?= Message-ID: <061.8f5f41f6d0b243505a4ac7780f2c9208@projects.linpro.no> #496: ? -----------------------------+---------------------------------------------- Reporter: 1987618girl1234 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+---------------------------------------------- ??vkjh -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 05:08:25 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 05:08:25 -0000 Subject: =?utf-8?b?UmU6IFtWYXJuaXNoXSAjNDk2OiDmiY0=?= In-Reply-To: <061.8f5f41f6d0b243505a4ac7780f2c9208@projects.linpro.no> References: <061.8f5f41f6d0b243505a4ac7780f2c9208@projects.linpro.no> Message-ID: <070.212163811c5985d2fd500b82ade354f0@projects.linpro.no> #496: ? -----------------------------+---------------------------------------------- Reporter: 1987618girl1234 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------------+---------------------------------------------- Comment (by 1987618girl1234): ???? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 14:01:43 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 14:01:43 -0000 Subject: [Varnish] #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance In-Reply-To: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> References: <053.23d7ccb9ad554347cf82b8ea488d042f@projects.linpro.no> Message-ID: <062.ee4724adb854ff526f52e4d5a7396c12@projects.linpro.no> #492: cache_waiter_epoll.c / cache_acceptor_epoll.c entire rewritten for Linux boxes better performance ---------------------------------------------------------------------------------+ Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: cache_acceptor_epoll.c cache_waiter_epoll.c performance linux epoll | ---------------------------------------------------------------------------------+ Comment (by rafaelumann): We worked on this after the following ticket: http://varnish.projects.linpro.no/ticket/235 This patch implements all that we thought of performance improvements for varnish epoll acceptor. We are running with this patch for a few days and its going much better. We are getting close to use all our hardware resources with maximum varnish performance. Br, Rafael Umann -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 14:28:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 14:28:31 -0000 Subject: [Varnish] #497: Overflow in vrt_assemble_string Message-ID: <049.847132ee3febe8582d3836b3958e1025@projects.linpro.no> #497: Overflow in vrt_assemble_string --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- If you run out of workspace in vrt_assemble_string this isn't caught until after the memory allocation is done. WS_Reserve(0) reserves all the space left, not necessarily how much you need. If this happen there is an assertion that gets called after the byte modification is made. When we add error handling code to the out of memory situation, WS_Reserve(0) should probably be removed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 21:09:27 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 21:09:27 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.201d73e449ac436fbbd026b77dfbb358@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by whocares): Could this be the cause for #482, too? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 22:40:03 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 22:40:03 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.72bd1b3a08a72c4b4c16728763d1c381@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by cra2): If it is the same as #482 you can try the attached patch in a testing env and see if it solves it. The patch may break other things, but it solves the problem I was having. The other work-around I came up with is to have a round-robin director with the same backend duplicated ~50 times. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 24 22:49:29 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Apr 2009 22:49:29 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.074c878766036afcd4bf9f1f67ce89e2@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by cra2): Oh, BTW my terminology was wrong. The patch makes Varnish /always/ recycle (or never reuse) a backend connection. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Apr 25 05:33:57 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 25 Apr 2009 05:33:57 -0000 Subject: [Varnish] #498: khj Message-ID: <061.428d5e3947bd9124b9ad36522c6c4c8f@projects.linpro.no> #498: khj ---------------------------------+------------------------------------------ Reporter: 1987618girl1234 | Type: enhancement Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: build Version: trunk | Severity: normal Keywords: xfjfg | ---------------------------------+------------------------------------------ dfjftgk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 26 02:43:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 26 Apr 2009 02:43:24 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.4b6d0eb2cf6abd0c5c7fe86c13d2176d@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by victori): Thanks for the ticket, this solves my problem! I was also using the 50 retry director hack to get it to work correctly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 26 04:51:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 26 Apr 2009 04:51:31 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.d82c620b56be836b17d9ec3235391ad5@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by victori): Actually no it did not. I tried the patch and setting pipe to close connection. Still get back-end failures. At this point I don't know what to do to avoid 503s. Varnish really needs internal retries for issues like these. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 26 09:11:02 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 26 Apr 2009 09:11:02 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.bb06032a7528e30b7bcf1fc8f7eec92d@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by whocares): Try my patch from #482. While this doesn't really solve the problem it does retry at least 4 times or whatever you've configured as retry-value on startup / via telnet. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 26 14:59:23 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 26 Apr 2009 14:59:23 -0000 Subject: =?utf-8?b?W1Zhcm5pc2hdICM0OTg6IOWwj+WcsOaWueingei/h+S7mOasvg==?= =?utf-8?b?6K6h5YiS?= Message-ID: <057.61cd15b7576663914a94c88645c873c1@projects.linpro.no> #498: ????????? -------------------------+-------------------------------------------------- Reporter: girl1987618 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------------------------------------- ???? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 26 19:12:22 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 26 Apr 2009 19:12:22 -0000 Subject: [Varnish] #498: Segfault with weird headers Message-ID: <049.e9dbdcb6dd080620bdd3978021a51f81@projects.linpro.no> #498: Segfault with weird headers --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- {{{ gdb) bt #0 0x00007f3e1ac83095 in raise () from /lib/libc.so.6 #1 0x00007f3e1ac84af0 in abort () from /lib/libc.so.6 #2 0x0000000000420e3e in pan_ic (func=0x44e85e "Tcheck", file=0x44e870 "cache.h", line=647, cond=0x44e865 "(t.b) != 0", err=0, xxx=0) at cache_panic.c:317 #3 0x000000000041ba49 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:647 #4 0x000000000041bb00 in http_findhdr (hp=0x7f26c24d00b8, l=13, hdr=0x664f71 "Cache-Control:") at cache_http.c:155 #5 0x000000000041bc6f in http_GetHdr (hp=0x7f26c24d00b8, hdr=0x664f71 "Cache-Control:", ptr=0x7f158d546978) at cache_http.c:177 #6 0x000000000041bd54 in http_GetHdrField (hp=0x7f26c24d00b8, hdr=0x664f70 "\016Cache-Control:", field=0x458722 "s-maxage", ptr=0x7f158d546a38) at cache_http.c:206 #7 0x0000000000437fc8 in RFC2616_Ttl (sp=0x7f132e829008, hp=0x7f26c24d00b8, obj=0x7f26c24d0000) at rfc2616.c:95 #8 0x000000000043845a in RFC2616_cache_policy (sp=0x7f132e829008, hp=0x7f26c24d00b8) at rfc2616.c:199 #9 0x00000000004128de in cnt_fetch (sp=0x7f132e829008) at cache_center.c:409 #10 0x000000000041480c in CNT_Session (sp=0x7f132e829008) at steps.h:41 #11 0x00000000004226f9 in wrk_do_cnt_sess (w=0x7f158d54ec00, priv=0x7f132e829008) at cache_pool.c:398 #12 0x0000000000422143 in wrk_thread (priv=0x7f3e1a90a2e0) at cache_pool.c:310 #13 0x00007f3e1b4533f7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f3e1ad28b3d in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) up #1 0x00007f3e1ac84af0 in abort () from /lib/libc.so.6 (gdb) up #2 0x0000000000420e3e in pan_ic (func=0x44e85e "Tcheck", file=0x44e870 "cache.h", line=647, cond=0x44e865 "(t.b) != 0", err=0, xxx=0) at cache_panic.c:317 317 abort(); (gdb) up #3 0x000000000041ba49 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:647 647 AN(t.b); (gdb) p t.b $1 = 0x0 (gdb) p t.e $2 = 0x0 (gdb) up #4 0x000000000041bb00 in http_findhdr (hp=0x7f26c24d00b8, l=13, hdr=0x664f71 "Cache-Control:") at cache_http.c:155 155 Tcheck(hp->hd[u]); (gdb) p u $3 = 7 (gdb) p hp $4 = (const struct http *) 0x7f26c24d00b8 (gdb) p hp->hd $5 = {{b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b = 0x7f26c24d0358 "HTTP/1.1", e = 0x7f26c24d0360 ""}, { b = 0x7f26c24d0361 "301", e = 0x7f26c24d0364 ""}, {b = 0x7f26c24d0365 "Moved Permanently", e = 0x7f26c24d0376 ""}, {b = 0x7f26c24d0377 "Date: Fri, 24 Apr 2009 23:41:03 GMT", e = 0x7f26c24d039a ""}, {b = 0x7f26c24d039b "Server: Apache", e = 0x7f26c24d03a9 ""}, {b = 0x0, e = 0x0}, {b = 0x7f26c24d03aa "Content-Type: text/html", e = 0x7f26c24d03c1 ""}, { b = 0x7f26c24d03c2 "Content-Length: 0", e = 0x7f26c24d03d3 ""}, {b = 0x0, e = 0x0} } (gdb) p hp->hd[u] $6 = {b = 0x0, e = 0x0} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 26 19:15:10 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 26 Apr 2009 19:15:10 -0000 Subject: [Varnish] #498: Segfault with weird headers In-Reply-To: <049.e9dbdcb6dd080620bdd3978021a51f81@projects.linpro.no> References: <049.e9dbdcb6dd080620bdd3978021a51f81@projects.linpro.no> Message-ID: <058.20e0e01aa322e40a143bbd1d468f0bed@projects.linpro.no> #498: Segfault with weird headers --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ $7 = {magic = 847584578, refcnt = 1, xid = 347701207, objhead = 0x7f12bb2eb280, objstore = 0x7f12bb2eb348, objexp = 0x0, ws_o = {{magic = 905626964, id = 0x44e169 "obj", s = 0x7f26c24d0358 "HTTP/1.1", f = 0x7f26c24d03d4 "%R\234a5?w?\006Ht\032|t\002(\030\032vLc?\n?;?K{\004?1?,\033\034\016???6?\ae?\021??\202ySV\212?UN?)%?\033JeF=?IB?`i?\026?}:\207\205n\004?\" Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 00:50:59 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 00:50:59 -0000 Subject: [Varnish] #499: Request for Wiki Editing Bits Message-ID: <053.dae7d56026acda7b3ebeaa95ba406e21@projects.linpro.no> #499: Request for Wiki Editing Bits ---------------------+------------------------------------------------------ Reporter: ekarulf | Type: task Status: new | Priority: normal Milestone: | Component: website Version: | Severity: normal Keywords: wiki | ---------------------+------------------------------------------------------ Hi All, My name is Erik Karulf. I was wondering if I could get commit bits to edit the wiki. Thanks! -Erik -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 01:37:54 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 01:37:54 -0000 Subject: [Varnish] #500: fhfgkh Message-ID: <060.4b774ddf773ca84f866c50e388bb2628@projects.linpro.no> #500: fhfgkh ---------------------------------+------------------------------------------ Reporter: 1987618girl546 | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: nagios Version: 1.1.2 | Severity: major Keywords: vjhg | ---------------------------------+------------------------------------------ fjhgl,kj -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 01:38:12 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 01:38:12 -0000 Subject: [Varnish] #500: fhfgkh In-Reply-To: <060.4b774ddf773ca84f866c50e388bb2628@projects.linpro.no> References: <060.4b774ddf773ca84f866c50e388bb2628@projects.linpro.no> Message-ID: <069.b7a6fdf00c3d19c09de789a26e99f6c9@projects.linpro.no> #500: fhfgkh ----------------------------+----------------------------------------------- Reporter: 1987618girl546 | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: nagios | Version: 1.1.2 Severity: major | Resolution: Keywords: vjhg | ----------------------------+----------------------------------------------- Comment (by 1987618girl546): fhgfk,jhg -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 08:36:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 08:36:39 -0000 Subject: [Varnish] #500: Problem ACL in purge mode. Message-ID: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> #500: Problem ACL in purge mode. -----------------------+---------------------------------------------------- Reporter: ajlozanob | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: 2.0 Severity: major | Keywords: Purge acl -----------------------+---------------------------------------------------- I'm discover that i can purge my varnish from any external ip, meanwhile i generate an acl: acl purge { "127.0.0.1"/32; } And in recv sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } lookup; } /.../ Varnishd version is: [root at tomcat varnish]# varnishd -V varnishd (varnish-2.0.3) Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 08:43:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 08:43:16 -0000 Subject: [Varnish] #499: Request for Wiki Editing Bits In-Reply-To: <053.dae7d56026acda7b3ebeaa95ba406e21@projects.linpro.no> References: <053.dae7d56026acda7b3ebeaa95ba406e21@projects.linpro.no> Message-ID: <062.23ffc27dfdb7bcf1369042902069d16a@projects.linpro.no> #499: Request for Wiki Editing Bits ---------------------+------------------------------------------------------ Reporter: ekarulf | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: website | Version: Severity: normal | Resolution: fixed Keywords: wiki | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: granted. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 09:28:56 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 09:28:56 -0000 Subject: [Varnish] #500: Problem ACL in purge mode. In-Reply-To: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> References: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> Message-ID: <064.c05b070affeff922dff259b2031fdab8@projects.linpro.no> #500: Problem ACL in purge mode. -----------------------+---------------------------------------------------- Reporter: ajlozanob | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: Purge acl | -----------------------+---------------------------------------------------- Comment (by phk): Can you find the acl records in the varnishlog output, and paste them here ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 10:32:24 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 10:32:24 -0000 Subject: [Varnish] #494: When backend server continues a header line with \n\t rather than \r\n\t remove only removes first line of header In-Reply-To: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no> References: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no> Message-ID: <060.2f97e76d3d5cbf76e17566a3e15d2646@projects.linpro.no> #494: When backend server continues a header line with \n\t rather than \r\n\t remove only removes first line of header ----------------------+----------------------------------------------------- Reporter: lrowe | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4036]) Implement HTTP continuation lines. Fixes #494 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 20:32:00 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 20:32:00 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.ee5c8e39e8bb1d85615c1a3a5118ba85@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by victori): I have tried the patch, it just hides the problem, the response is still a "503" vcl_error response but the headers come back as 200. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 27 22:21:22 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Apr 2009 22:21:22 -0000 Subject: [Varnish] #498: Segfault with weird headers In-Reply-To: <049.e9dbdcb6dd080620bdd3978021a51f81@projects.linpro.no> References: <049.e9dbdcb6dd080620bdd3978021a51f81@projects.linpro.no> Message-ID: <058.278810b2e7c033aec26b54b54ae9df8c@projects.linpro.no> #498: Segfault with weird headers --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * status: new => closed * resolution: => fixed Comment: "fixed" by r4038 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 03:07:22 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 03:07:22 -0000 Subject: [Varnish] #501: eyrt Message-ID: <062.f1894fc0bcd312eeeb03d7da37c75562@projects.linpro.no> #501: eyrt ---------------------------------+------------------------------------------ Reporter: 1987618girl11235 | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: build Version: 1.1.1 | Severity: normal Keywords: dhfg | ---------------------------------+------------------------------------------ dfjygl -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:33:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:33:20 -0000 Subject: [Varnish] #486: link failure with --as-needed In-Reply-To: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> References: <058.d70a70c32653edc76f2ec065e1582409@projects.linpro.no> Message-ID: <067.dc7c3583b6902c177427476443777dd8@projects.linpro.no> #486: link failure with --as-needed --------------------------+------------------------------------------------- Reporter: thilobangert | Owner: Type: enhancement | Status: closed Priority: low | Milestone: Component: build | Version: 2.0 Severity: minor | Resolution: fixed Keywords: | --------------------------+------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4039]) Reorder libraries add "-Wl,--as-needed" to EXTRA_DEVELOPER_CFLAGS to try to prevent future unordering. Fixes #486 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:40:05 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:40:05 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.c67aafd8a99f13a1b2d195a7e400ad0b@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): Can you get me a tcpdump of the communication between varnish and the backend ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:43:01 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:43:01 -0000 Subject: [Varnish] #493: varnish-tools/regress broken In-Reply-To: <051.8b028e6dd7e5c51c90ba0cc07d3f50ad@projects.linpro.no> References: <051.8b028e6dd7e5c51c90ba0cc07d3f50ad@projects.linpro.no> Message-ID: <060.2ef6cc27afc7cde6fb05c11952119ff1@projects.linpro.no> #493: varnish-tools/regress broken ---------------------+------------------------------------------------------ Reporter: bolav | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: regress | Version: 2.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by phk): Unless somebody has good reasons not to, I move that we delete varnish- tools/regress, varnish-cache/bin/varnishtest has overtaken it for all I know. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:51:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:51:42 -0000 Subject: [Varnish] #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: In-Reply-To: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> References: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> Message-ID: <058.b8130c906e5bd6ffdf995198646ba1b6@projects.linpro.no> #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This has been overtaken by other changes in the hashing sector. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:53:34 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:53:34 -0000 Subject: [Varnish] #351: v00017.vtc, v00018.vtc and v00019.vtc fails on ppc64 In-Reply-To: <052.7fe3ddde6383eb256ea1dc9d51dfe8dc@projects.linpro.no> References: <052.7fe3ddde6383eb256ea1dc9d51dfe8dc@projects.linpro.no> Message-ID: <061.90381734fbe7ade12205e0afab0e951e@projects.linpro.no> #351: v00017.vtc, v00018.vtc and v00019.vtc fails on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Belived to be fixed by new acl code, otherwise, please reopen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:54:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:54:20 -0000 Subject: [Varnish] #360: Cannot create temp file on startup In-Reply-To: <052.b5fd53604abc3f624eff0e699d9d04b0@projects.linpro.no> References: <052.b5fd53604abc3f624eff0e699d9d04b0@projects.linpro.no> Message-ID: <061.bb04f9d063bf48dc48c089c43e123b84@projects.linpro.no> #360: Cannot create temp file on startup ----------------------+----------------------------------------------------- Reporter: ltning | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Tried to reproduce, could not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:55:42 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:55:42 -0000 Subject: [Varnish] #383: Unexplained vcl behaivior maybe header related to header modify In-Reply-To: <056.d969776f70d684566868c4d4abb7abaf@projects.linpro.no> References: <056.d969776f70d684566868c4d4abb7abaf@projects.linpro.no> Message-ID: <065.85969da0deed33ffe5fa4a6cc645452e@projects.linpro.no> #383: Unexplained vcl behaivior maybe header related to header modify ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: vcl header | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:56:15 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:56:15 -0000 Subject: [Varnish] #379: The varnish have no response most of the time , is it the bug? In-Reply-To: <051.87655e50bc8fca878e4c18f54c9f6ca6@projects.linpro.no> References: <051.87655e50bc8fca878e4c18f54c9f6ca6@projects.linpro.no> Message-ID: <060.8546ec593980b3ab40969efe1236e809@projects.linpro.no> #379: The varnish have no response most of the time ,is it the bug? --------------------+------------------------------------------------------- Reporter: Ajian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 08:57:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 08:57:16 -0000 Subject: [Varnish] #424: test c00014 failure on RHEL 4u7 build In-Reply-To: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> References: <049.c42052280a772ce3031bd3231b85beca@projects.linpro.no> Message-ID: <058.04508513afc6f350439a8d3d12f7fdb8@projects.linpro.no> #424: test c00014 failure on RHEL 4u7 build --------------------+------------------------------------------------------- Reporter: kwy | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Belived fixed, otherwise reopen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 14:20:50 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 14:20:50 -0000 Subject: [Varnish] #500: Problem ACL in purge mode. In-Reply-To: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> References: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> Message-ID: <064.378705c0d8e69616c0eba537a9b25ff6@projects.linpro.no> #500: Problem ACL in purge mode. -----------------------+---------------------------------------------------- Reporter: ajlozanob | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: Purge acl | -----------------------+---------------------------------------------------- Comment (by ajlozanob): i'm retry it, and i can't reproduce it, perhaps any sintax error in vcl before get it ok. telnet answer HTTP/1.1 405 Not allowed. Server: Varnish Retry-After: 0 Content-Type: text/html; charset=utf-8 Content-Length: 2969 Date: Tue, 28 Apr 2009 14:18:00 GMT X-Varnish: 522485195 Age: 0 Via: 1.1 varnish Connection: close X-Provider: GrupoGesfor X-Cache: MISS Varnishlog text 11 RxRequest c PURGE 11 RxURL c / 11 RxProtocol c HTTP/1.0 11 RxHeader c Host: www.xxx.xx 11 VCL_call c recv 11 VCL_acl c NO_MATCH purge 0 Debug - "VCL_error(405, Not allowed.)" 11 VCL_return c error 11 VCL_call c error 11 VCL_return c deliver 11 Length c 2969 11 VCL_call c deliver 11 VCL_return c deliver 11 TxProtocol c HTTP/1.1 11 TxStatus c 405 11 TxResponse c Not allowed. 11 TxHeader c Server: Varnish 11 TxHeader c Retry-After: 0 11 TxHeader c Content-Type: text/html; charset=utf-8 11 TxHeader c Content-Length: 2969 11 TxHeader c Date: Tue, 28 Apr 2009 14:16:37 GMT 11 TxHeader c X-Varnish: 522484526 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 14:21:31 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 14:21:31 -0000 Subject: [Varnish] #500: Problem ACL in purge mode. In-Reply-To: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> References: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> Message-ID: <064.42e06a0b2a030d4485c1bc8d6dc2890e@projects.linpro.no> #500: Problem ACL in purge mode. -----------------------+---------------------------------------------------- Reporter: ajlozanob | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: Purge acl | -----------------------+---------------------------------------------------- Comment (by ajlozanob): Please, close ticket, thnx. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 28 14:32:39 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Apr 2009 14:32:39 -0000 Subject: [Varnish] #500: Problem ACL in purge mode. In-Reply-To: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> References: <055.d17861f213de4c6619241b98ffaa51b4@projects.linpro.no> Message-ID: <064.4ceb400df5a13e1f3ad45151a4fb3a8c@projects.linpro.no> #500: Problem ACL in purge mode. -----------------------+---------------------------------------------------- Reporter: ajlozanob | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: 2.0 Severity: major | Resolution: worksforme Keywords: Purge acl | -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: OK, let us know if you see it again. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 29 03:25:51 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Apr 2009 03:25:51 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring Message-ID: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------+-------------------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: busy threads monitoring -------------------------+-------------------------------------------------- Hi! I made this patch for implementing a new varnishstat variable, called 'n_wrk_busy'. With this new variable we can now know for sure how many of our active threads are actually doing something, so the system can be better dimensioned in order to know if we are getting near the max threads utilization: if we are, we can increase the number of max threads in order to instatiate more, if the system can handle more threads, if not, go for more hardware. This is good in the cases when we configure thread_pool_min == thread_pool_max and do not have to know how many of the threads are actually used for something. I believe the same applies when we have thread_pool_min == 1 and thread_pool_max == MAX_WISHED. In this case we can know how many threads are idle (waiting for thread_pool_timeout to expire) and how many are actually working. This is good for monitoring and I hope this can help someone else to know what is happening under the hood a little better. Best regards, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 29 03:49:32 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Apr 2009 03:49:32 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring In-Reply-To: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> References: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> Message-ID: <062.dae99b61abc0e5b297e55e195f2947a9@projects.linpro.no> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------------------+-------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: busy threads monitoring | -------------------------------------+-------------------------------------- Comment (by stockrt): I am not sure if this initialisation of 'n_wrk_busy = 0' is required. I can see that in r4040 (post 2.0.4 release) when we declare a new stats variable, there is a field that seems to be the initial value. This does not exist for 2.0.4 release. So, this needs checks in my patches: VSL_stats->n_wrk_busy = 0; I also can see that sometimes variables are not initialised in 2.0.4 release, but I prefer to publish my code the way I place it here, initialising this var. If you thing it is better not, please remove these extra lines. Regards, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 29 09:18:03 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Apr 2009 09:18:03 -0000 Subject: [Varnish] #444: allow to handle non-GET req in vcl_miss In-Reply-To: <052.421175f448383bd901fcccf9d81bf397@projects.linpro.no> References: <052.421175f448383bd901fcccf9d81bf397@projects.linpro.no> Message-ID: <061.54b4f41a3b06ed756605cf38b7e312da@projects.linpro.no> #444: allow to handle non-GET req in vcl_miss -------------------------+-------------------------------------------------- Reporter: hajile | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4042]) Previously, we forced the request to "GET" on all fetches for cache and this prevented users from implementing "purge on POST" semantics by looking up the POST requests and ditching the object found. Now we only overwrite the request with "GET" if it is a HEAD, (the internal "wantbody" flag tells hos how the response should be composed.) The testcase shold probably be elevated to VCL example, with suitable footnotes about URL sanitizing etc. Fixes #444 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 29 09:51:20 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Apr 2009 09:51:20 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring In-Reply-To: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> References: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> Message-ID: <062.4c06f96b362d34053e2f2aaddfaba88b@projects.linpro.no> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------------------+-------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: busy threads monitoring | -------------------------------------+-------------------------------------- Comment (by phk): The reason we do not have that variable presently, is that it will quite soon become useless if it is not properly locked. Properly locking it is not trivial. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 29 17:11:26 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Apr 2009 17:11:26 -0000 Subject: [Varnish] #495: HTTP/1.0 or 'Connection: closed' backend race condition In-Reply-To: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> References: <049.ef605108ffb6a27a8a69ad285c7e044f@projects.linpro.no> Message-ID: <058.01bae416b1bb2516e73b8e26e0245533@projects.linpro.no> #495: HTTP/1.0 or 'Connection: closed' backend race condition --------------------+------------------------------------------------------- Reporter: cra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by cra3): I'm not 100% sure it's related, but after I applied the 'noreuse' patch I still had some 'Backend Connection Failures' reported in varnishstat. It's harder to reproduce but it seemed like Varnish was not getting as far as sending anything to the backend. More testing, trial and error lead me to disable the call to TCP_Connect() (see notimeouts patch) and combined with the noreuse patch it's eliminated the connection failures in my environment. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 29 17:42:41 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Apr 2009 17:42:41 -0000 Subject: [Varnish] #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring In-Reply-To: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> References: <053.c36da4f0d6e46e7caf56d23fff2a9968@projects.linpro.no> Message-ID: <062.865ab3d5769299585d5916fb9a227e40@projects.linpro.no> #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring -------------------------------------+-------------------------------------- Reporter: stockrt | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: busy threads monitoring | -------------------------------------+-------------------------------------- Comment (by stockrt): Replying to [comment:2 phk]: > The reason we do not have that variable presently, is that it will quite soon become useless if it is not properly locked. > > Properly locking it is not trivial. ---- Yep, I just saw it with more load. Anyway, I am attaching another version, that, I believe, should be less error prone, but yet should suffer for concurrency problems. If this is not good yet (need more testing) we can forget it for a while. Thanks, Rog?rio Schneider -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 30 10:55:23 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Apr 2009 10:55:23 -0000 Subject: [Varnish] #329: Increase cli_timeout In-Reply-To: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> References: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> Message-ID: <060.a058060541017d2211318423013c8d16@projects.linpro.no> #329: Increase cli_timeout -------------------------+-------------------------------------------------- Reporter: perbu | Owner: perbu Type: defect | Status: closed Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: trivial | Resolution: fixed Keywords: cli_timeout | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [4043]) Bump the cli_timeout to 10 seconds. Fixes #329 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 30 10:57:35 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Apr 2009 10:57:35 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.06cbf44ff6e4f19c9648cafdf2ec281b@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => worksforme Comment: Time out this ticket, There seems to be no simple wayt to work around the OS limitation. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 30 11:01:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Apr 2009 11:01:28 -0000 Subject: [Varnish] #378: unresonable varnish free smf number In-Reply-To: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> References: <052.618f7be89c19415305663059b7a0e23a@projects.linpro.no> Message-ID: <061.70eb2635132fbcef0718f24a5e522496@projects.linpro.no> #378: unresonable varnish free smf number ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: blocker | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => worksforme Comment: The smf issue is caused by multiple storages in this case, as expected. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 30 11:05:16 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Apr 2009 11:05:16 -0000 Subject: [Varnish] #431: Crash in fetch In-Reply-To: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> References: <049.dbd4ec0cc992ffb0e69413326fa9fecb@projects.linpro.no> Message-ID: <058.dc7f88d786dc2e87bc401c2b52172c7a@projects.linpro.no> #431: Crash in fetch --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * status: new => closed * resolution: => fixed Comment: Duplicate of #498 and fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 30 11:08:28 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Apr 2009 11:08:28 -0000 Subject: [Varnish] #463: varnish returns no content on error 403/404 from thttpd backend In-Reply-To: <048.4491cba94f3aeda640c0f9b04ff300ad@projects.linpro.no> References: <048.4491cba94f3aeda640c0f9b04ff300ad@projects.linpro.no> Message-ID: <057.2e0ea09a3039fd2896c827f365d02ffa@projects.linpro.no> #463: varnish returns no content on error 403/404 from thttpd backend --------------------+------------------------------------------------------- Reporter: wg | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I believe this one is fixed in 2.0.3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 30 11:15:03 2009 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Apr 2009 11:15:03 -0000 Subject: [Varnish] #453: Assert error in WS_Release(), cache_ws.c line 170 In-Reply-To: <049.082c25eebb1351993cafbd750e5b4d24@projects.linpro.no> References: <049.082c25eebb1351993cafbd750e5b4d24@projects.linpro.no> Message-ID: <058.98505b13d5159c918cc93af148c903f9@projects.linpro.no> #453: Assert error in WS_Release(), cache_ws.c line 170 --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: duplicate Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * status: new => closed * resolution: => duplicate Comment: duplicate of #497 -- Ticket URL: Varnish The Varnish HTTP Accelerator