From varnish-bugs at varnish-cache.org Mon Nov 1 12:06:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Nov 2010 12:06:30 -0000 Subject: [Varnish] #795: Conditional GETs based on modification time are not honored if Last-Modified was not explicitly set In-Reply-To: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> References: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> Message-ID: <050.d7e1105d17e5798aabf3587c2db76c29@varnish-cache.org> #795: Conditional GETs based on modification time are not honored if Last- Modified was not explicitly set -----------------------+---------------------------------------------------- Reporter: runa | Type: defect Status: reopened | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by runa): * status: closed => reopened * resolution: wontfix => Comment: Weird. Is still not doing it (varnish-2.0.6) I added, in vcl_fetch: {{{ if (!obj.http.last-modified) { set obj.http.last-modified = obj.http.date; } }}} but still, I get a 200 response {{{ * About to connect() to www.sumavisos.com.ar port 80 (#0) * Trying 173.45.100.10... connected * Connected to www.sumavisos.com.ar (173.45.100.10) port 80 (#0) > GET /autos/fiat HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8n zlib/1.2.3.3 libidn/1.15 > Host: www.sumavisos.com.ar > Accept: */* > If-Modified-Since: Mon, 01 Nov 2010 12:01:44 GMT > < HTTP/1.1 200 OK < Age: 6808 < Date: Mon, 01 Nov 2010 12:02:06 GMT < Content-Length: 144232 < Content-Type: text/html; charset=utf-8 < Cache-Control: max-age=3600, s-maxage=3600 < Server: nginx/0.7.65 < Status: 200 OK < X-Runtime: 624 < ETag: "df24b4c438a1274a2cafabc96296e6f4" < last-modified: Mon, 01 Nov 2010 12:01:44 GMT < X-Varnish: 232911537 232911446 < X-Cache: HIT }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 1 21:59:59 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Nov 2010 21:59:59 -0000 Subject: [Varnish] #809: Link to documentation is not discoverable Message-ID: <043.2cd04fd0e3c9cb9226ffa118e9ba261e@varnish-cache.org> #809: Link to documentation is not discoverable ---------------------------------+------------------------------------------ Reporter: nilbus | Type: documentation Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: website Version: trunk | Severity: normal Keywords: usability | ---------------------------------+------------------------------------------ [http://www.varnish-cache.org/docs] The links to the documentation are quite difficult to find, and require reading the tiny text. You don't notice them when scanning the page, which is what most people do when looking for information. I actually went a few weeks thinking your documentation was quite pathetic, only consisting of some Quick Install guides. Let's fix this. Screenshot: [[Image(http://www.nilbus.com/pub/grabup/2010-11-01_17.40.39.png )]] Links should be on the text that describes what the link goes to, never the word "here". I also changed "a install guide" to "an install guide" and added bold text to improve scanability, for people looking for any of those three things. Suggested improvement: ---- The official documentation contains an '''install guide''', a '''tutorial''' and a '''reference'''. We're trying to keep the official documentation in sync with the code. Both are kept in the same source repository and both are available online. * Documentation for the [http://www.varnish-cache.org/docs/2.1 latest stable release] * Documentation for [http://www.varnish-cache.org/docs/trunk trunk] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:04:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:04:36 -0000 Subject: [Varnish] #646: [PATCH] Log hits only with varnishncsa In-Reply-To: <046.1ca89cd0a4e7d816edfe78b93a4b3615@varnish-cache.org> References: <046.1ca89cd0a4e7d816edfe78b93a4b3615@varnish-cache.org> Message-ID: <055.5fdce074a1f037eaa56285838d1da586@varnish-cache.org> #646: [PATCH] Log hits only with varnishncsa ------------------------+--------------------------------------------------- Reporter: bmizerany | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Resolution: fixed | Keywords: ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Old description: > I've added the ability log only cache hits with varnishncsa. > > varnishncsa -H > > This is a very useful feature when debugging and even for production > logging, of which I use both. > > I would love to see this be part of stock varnish. > > I'm very open to ideas on how to be a little more general about this. > Maybe getting -i to work; I was unable too. > > varnishncsa -i Hit > > Thoughts? New description: I've added the ability log only cache hits with varnishncsa. varnishncsa -H This is a very useful feature when debugging and even for production logging, of which I use both. I would love to see this be part of stock varnish. I'm very open to ideas on how to be a little more general about this. Maybe getting -i to work; I was unable too. varnishncsa -i Hit Thoughts? -- Comment: You can accomplish this by doing varnishncsa -o VCL_call hit in trunk now, so closing this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:06:11 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:06:11 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> Message-ID: <053.d2b7d5379e0dc37c457534ec6e0538a3@varnish-cache.org> #633: varnishncsa segfaults -------------------------+-------------------------------------------------- Reporter: victori | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * component: build => varnishncsa Old description: > OS: opensolaris snv98 > > varnishncsa segfaults after a few seconds of use. I have a suspicion it > could potentially be tied to bad requests, since the uptime varies from > run to run. > > Here is some sample output; The sample below has run less than 3 or 5 > seconds before it segfaulted. > > http://pastie.org/795632.txt New description: OS: opensolaris snv98 varnishncsa segfaults after a few seconds of use. I have a suspicion it could potentially be tied to bad requests, since the uptime varies from run to run. Here is some sample output; The sample below has run less than 3 or 5 seconds before it segfaulted. http://pastie.org/795632.txt -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:07:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:07:01 -0000 Subject: [Varnish] #685: Logging non-HTTP connections as null In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org> Message-ID: <056.1b106ab705f334ea85066e3e660303d9@varnish-cache.org> #685: Logging non-HTTP connections as null -------------------------+-------------------------------------------------- Reporter: joshdevins | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: major | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: assigned => closed * resolution: => fixed Old description: > We have a load balancer setup in front of Varnish and it is simply doing > a TCP health check against it. The resulting log lines when running > varnishncsa are just a bunch of nulls: > > - - - [23/Apr/2010:18:13:20 +0200] "(null) (null) (null)" (null) - "-" > "-" New description: We have a load balancer setup in front of Varnish and it is simply doing a TCP health check against it. The resulting log lines when running varnishncsa are just a bunch of nulls: - - - [23/Apr/2010:18:13:20 +0200] "(null) (null) (null)" (null) - "-" "-" -- Comment: This has been fixed by Martin's fixes in trunk, so closing this bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:08:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:08:40 -0000 Subject: [Varnish] #485: Virtualhost logging for varnishncsa In-Reply-To: <043.fde65ce041c93ef9119ae5492b077e39@varnish-cache.org> References: <043.fde65ce041c93ef9119ae5492b077e39@varnish-cache.org> Message-ID: <052.33d8ae3e70ff5b9f0358270211392d66@varnish-cache.org> #485: Virtualhost logging for varnishncsa ---------------------------------------------------------+------------------ Reporter: rhalff | Owner: tfheen Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishncsa, virtual hosts, apache, logging | ---------------------------------------------------------+------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [5489]) Implement custom log formats for varnishncsa Make it possible to specify log formats for varnishncsa using -F. We don't support arbitrary HTTP headers yet, and there are no docs yet either. Also missing is validation of the format when starting up, rather than on the first line of the request. Fixes #712 Fixes #485 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:08:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:08:42 -0000 Subject: [Varnish] #712: Custom varnishncsa log format In-Reply-To: <042.68735fbe2f2d3636ae319db40a720359@varnish-cache.org> References: <042.68735fbe2f2d3636ae319db40a720359@varnish-cache.org> Message-ID: <051.736cd55bd9abe31ffd2cfffd5832e3aa@varnish-cache.org> #712: Custom varnishncsa log format ---------------------+------------------------------------------------------ Reporter: quipo | Type: enhancement Status: closed | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: (In [5489]) Implement custom log formats for varnishncsa Make it possible to specify log formats for varnishncsa using -F. We don't support arbitrary HTTP headers yet, and there are no docs yet either. Also missing is validation of the format when starting up, rather than on the first line of the request. Fixes #712 Fixes #485 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:36:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:36:43 -0000 Subject: [Varnish] #809: Link to documentation is not discoverable In-Reply-To: <043.2cd04fd0e3c9cb9226ffa118e9ba261e@varnish-cache.org> References: <043.2cd04fd0e3c9cb9226ffa118e9ba261e@varnish-cache.org> Message-ID: <052.c95e02c66cbcf4ad9ddceea4a8fd216c@varnish-cache.org> #809: Link to documentation is not discoverable ---------------------------+------------------------------------------------ Reporter: nilbus | Owner: perbu Type: documentation | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: website | Version: trunk Severity: normal | Keywords: usability ---------------------------+------------------------------------------------ Changes (by tfheen): * owner: => perbu Comment: Reassigning to Per. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:48:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:48:04 -0000 Subject: [Varnish] #809: Link to documentation is not discoverable In-Reply-To: <043.2cd04fd0e3c9cb9226ffa118e9ba261e@varnish-cache.org> References: <043.2cd04fd0e3c9cb9226ffa118e9ba261e@varnish-cache.org> Message-ID: <052.7e4e881ac6ae05aba4a7810aaa8d133e@varnish-cache.org> #809: Link to documentation is not discoverable ---------------------------+------------------------------------------------ Reporter: nilbus | Owner: perbu Type: documentation | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: website | Version: trunk Severity: normal | Resolution: fixed Keywords: usability | ---------------------------+------------------------------------------------ Changes (by perbu): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:48:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:48:16 -0000 Subject: [Varnish] #678: varnishd stops accepting requests In-Reply-To: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> References: <045.83a635a19e90ae4194d495f85ae179e7@varnish-cache.org> Message-ID: <054.2894c1c92fece4334e19eef80c5922f3@varnish-cache.org> #678: varnishd stops accepting requests ----------------------------------+----------------------------------------- Reporter: ahongens | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: worksforme Keywords: hang stop responding | ----------------------------------+----------------------------------------- Changes (by tfheen): * status: reopened => closed * resolution: => worksforme Old description: > I have four balancers that ran 2.0.5 fine for months, and now I've > upgraded them to 2.1.0, and sometimes one (at random which one) seems to > hang. > > Varnishstat shows no requests coming in, and when I run varnishlog I only > see a lot of lines like this: > {{{ > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > 8045 SessionClose - dropped > 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 > }}} > I don't see anything else that is strange.. The only thing I see in my > cacti monitoring is that responses go down, and active tcp connections go > up (probably as a result). Load of the balancers prior to the problem is > a normal 0.2-0.5. > > After restaring, in my syslog I see (strange the time is off by 2 hours > though, time was 13:34, all other daemons log ok) > {{{ > Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Manager got SIGINT > Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Stopping Child > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: child (65643) Started > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Closed > fds: 4 5 6 7 11 12 14 15 > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Child > starts > Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said managed to > mmap 8589934592 bytes of 8589934592 > }}} > I cannot reproduce it. New description: I have four balancers that ran 2.0.5 fine for months, and now I've upgraded them to 2.1.0, and sometimes one (at random which one) seems to hang. Varnishstat shows no requests coming in, and when I run varnishlog I only see a lot of lines like this: {{{ 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 8045 SessionClose - dropped 8045 StatSess - (null) (null) 1271244853 0 0 0 0 0 0 0 }}} I don't see anything else that is strange.. The only thing I see in my cacti monitoring is that responses go down, and active tcp connections go up (probably as a result). Load of the balancers prior to the problem is a normal 0.2-0.5. After restaring, in my syslog I see (strange the time is off by 2 hours though, time was 13:34, all other daemons log ok) {{{ Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Manager got SIGINT Apr 14 11:34:23 nmt-nlb-04 varnishd[54351]: Stopping Child Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: child (65643) Started Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Closed fds: 4 5 6 7 11 12 14 15 Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said Child starts Apr 14 11:34:37 nmt-nlb-04 varnishd[65642]: Child (65643) said managed to mmap 8589934592 bytes of 8589934592 }}} I cannot reproduce it. -- Comment: It seems like you have more traffic than Varnish is set up to handle. Increase the number of worker threads or get a faster machine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 10:50:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 10:50:56 -0000 Subject: [Varnish] #807: varnishlog should do input validation In-Reply-To: <043.8ccc2e377b952dd35985726ef7341ac8@varnish-cache.org> References: <043.8ccc2e377b952dd35985726ef7341ac8@varnish-cache.org> Message-ID: <052.e9ba3dd9e62ce77c9dbfee5c0e240237@varnish-cache.org> #807: varnishlog should do input validation ------------------------+--------------------------------------------------- Reporter: tfheen | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- Changes (by tfheen): * owner: phk => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 11:00:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 11:00:21 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.e030dafca64bb185775e0e226720f5ce@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by tfheen): In which VCL function are you trying to read the object status? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 12:54:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 12:54:33 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.ae25110966cb696b52162c110940b266@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by David Busby): sub vcl_fetch, which I've just realised using beresp not obj, going to try that now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 12:59:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 12:59:06 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.bdb9a6349a9c3e9a174ce00a6d880e2c@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by David Busby): yes sorry, user error using beresp works fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 13:09:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 13:09:44 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.005d6d7e7d35463a83f3b76b9f82eb2d@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by David Busby): Right sorry for the suprious updates, beresp does not work it generates an issue, Panic message: Assert error in vrt_selecthttp(), cache_vrt.c line 118:#012 Condition((sp->obj) != NULL) not true.#012thread = (cache-worker)#012ident = Linux,2.6.34.7-56.fc13.i686,i686,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x806d79d: /usr/sbin/varnishd() [0x806d79d]#012 0x8076ed0: /usr/sbin/varnishd() [0x8076ed0]#012 0x8078d99: /usr/sbin/varnishd(VRT_GetHdr+0x59) [0x8078d99]#012 0x29da8f: ./vcl.1P9zoqAU.so(+0x1a8f) [0x29da8f]#012 0x80731c5: /usr/sbin/varnishd(VCL_fetch_method+0x55) [0x80731c5]#012 0x8059f70: /usr/sbin/varnishd() [0x8059f70]#012 0x805bc42: /usr/sbin/varnishd(CNT_Session+0x3c2) [0x805bc42]#012 0x806f320: /usr/sbin/varnishd() [0x806f320]#012 0x806f70a: /usr/sbin/varnishd() [0x806f70a]#012 0x806fc3e: /usr/sbin/varnishd() [0x806fc3e]#012sp = 0xaca07004 {#012 fd = 11, id = 11, xid = 269168914,#012 client = 127.0.0.1:43517,#012 step = STP_FETCH,#012 handling = deliver,#012 err_code = 500, err_reason = (null),#012 restarts = 0, esis = 0#012 ws = 0xaca0704c { #012 id = "sess",#012 {s,f,r,e} = {0xaca077dc,+536,(nil),+16384},#012 },#012 http[req] = {#012 ws = 0xaca0704c[sess]#012 "GET",#012 "/test.php",#012 "HTTP/1.1",#012 "Host: localhost:8080",#012 "User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100920 Fedora/3.6.10-1.fc13 Firefox/3.6.10",#012 "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",#012 "Accept-Language: en-us,en;q=0.5",#012 "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",#012 "Keep-Alive: 115",#012 "Connection: keep-alive",#012 "Cache-Control: max-age=0",#012 "Accept-Encoding: gzip",#012 },#012 worker = 0xac877124 {#012 ws = 0xac87723c { #012 id = "wrk",#012 {s,f,r,e} = {0xac8710d0,+296,(nil),+16384},#012 },#012 http[bereq] = {#012 ws = 0xac87723c[wrk]#012 "GET",#012 "/test.php",#012 "HTTP/1.1",#012 "Host: localhost:8080",#012 "User-Agent: Mo I'm assuming this is user error? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 13:52:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 13:52:42 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.15bb1b4c563eebf1985ec8f2705742fc@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Old description: > Error ocurred at both SVN 5430 and latest SVN 5487. > > To reproduce using httperf 0.9 and set num-calls to about 4000 and above. > This is related to the session_workspace value. With 512KB, it will > sustain/buffer 3600 requests/second. I have tested the session_workspace > value and it directly correlates to how many calls can be made per keep- > alive request before varnish asserts and restarts. Lowering the value > lowers the number of num-calls httperf will be able send without crashing > varnish. For example, using defaults, varnish can only sustain a few > hundred almost simultaneous requests from a single connection. > > If varnish can somehow not assert but check its session memory usage and > close the connection if reaching session workspace limit, it would be > ideal as compared to the case now where varnish restarts. > > {{{ > httperf --server www.myserver.com --uri / --num-conns 1 --num-calls 4000 > }}} > > Varnish startup line: > > {{{ > varnishd -f varnish_vcl.txt -a $IP:22201 -T 127.0.0.1:22201 -n /raid0 -h > critbit -smalloc,8G -p thread_pools=2 -p thread_pool_min=100 -p > thread_pool_max=500 -p thread_pool_add_delay=2 -p listen_depth=4096 -p > session_linger=50/100/150 -p lru_interval=20 -p sess_workspace=512000 > }}} > > {{{ > Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22056) died signal=6 > Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22056) Panic message: Assert > error in http_Write(), cache_http.c line 918: > Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- > worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll > Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: > varnishd(http_Write+0x293) [0x420433] 0x426fab: > varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] > 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd > [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: > /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: > /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaaac19008 { fd > = 12, id = 12, xid = 733244310, client = 209.151.227.72 56196, step = > STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), > restarts = 0, esis = 0 ws = 0x2aaaaac19080 { id = "sess", > {s,f,r,e} = {0x2aaaaac19cd8,+216,(nil),+65536}, }, http[req] = { > ws = 0x2aaaaac19080[sess] > Oct 29 06:18:57 kitty1 /raid0[21974]: child (22075) Started > Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22075) said > Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22075) said Child starts > Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22075) died signal=6 > Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22075) Panic message: Assert > error in http_Write(), cache_http.c line 918: > Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- > worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll > Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: > varnishd(http_Write+0x293) [0x420433] 0x426fab: > varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] > 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd > [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: > /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: > /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaab0af008 { fd > = 12, id = 12, xid = 227475721, client = 209.151.227.72 57424, step = > STP_DELIVER, handling = deliver, restarts = 0, esis = 0 ws = > 0x2aaaab0af080 { id = "sess", {s,f,r,e} = > {0x2aaaab0afcd8,+216,(nil),+65536}, }, http[req] = { ws = > 0x2aaaab0af080[sess] "GET", "/", "HTTP/1. > Oct 29 06:19:47 kitty1 /raid0[21974]: child (22094) Started > Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22094) said > Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22094) said Child starts > Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22094) died signal=6 > Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22094) Panic message: Assert > error in http_Write(), cache_http.c line 918: > Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- > worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll > Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: > varnishd(http_Write+0x293) [0x420433] 0x426fab: > varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] > 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd > [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: > /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: > /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaaabe8008 { fd > = 14, id = 14, xid = 170289336, client = 209.151.227.72 57483, step = > STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), > restarts = 0, esis = 0 ws = 0x2aaaaabe8080 { id = "sess", > {s,f,r,e} = {0x2aaaaabe8cd8,+216,(nil),+65536}, }, http[req] = { > ws = 0x2aaaaabe8080[sess] > Oct 29 06:19:49 kitty1 /raid0[21974]: child (22113) Started > Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22113) said > Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22113) said Child starts > Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22113) died signal=6 > Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22113) Panic message: Assert > error in http_Write(), cache_http.c line 918: > Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- > worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll > Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: > varnishd(http_Write+0x293) [0x420433] 0x426fab: > varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] > 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd > [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: > /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: > /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaab336008 { fd > = 22, id = 22, xid = 161296516, client = 209.151.227.72 57576, step = > STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), > restarts = 0, esis = 0 ws = 0x2aaaab336080 { id = "sess", > {s,f,r,e} = {0x2aaaab336cd8,+216,(nil),+65536}, }, http[req] = { > ws = 0x2aaaab336080[sess] > Oct 29 06:19:53 kitty1 /raid0[21974]: child (22132) Started > Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22132) said > Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22132) said Child starts > > }}} New description: Error ocurred at both SVN 5430 and latest SVN 5487. To reproduce using httperf 0.9 and set num-calls to about 4000 and above. This is related to the session_workspace value. With 512KB, it will sustain/buffer 3600 requests/second. I have tested the session_workspace value and it directly correlates to how many calls can be made per keep- alive request before varnish asserts and restarts. Lowering the value lowers the number of num-calls httperf will be able send without crashing varnish. For example, using defaults, varnish can only sustain a few hundred almost simultaneous requests from a single connection. If varnish can somehow not assert but check its session memory usage and close the connection if reaching session workspace limit, it would be ideal as compared to the case now where varnish restarts. {{{ httperf --server www.myserver.com --uri / --num-conns 1 --num-calls 4000 }}} Varnish startup line: {{{ varnishd -f varnish_vcl.txt -a $IP:22201 -T 127.0.0.1:22201 -n /raid0 -h critbit -smalloc,8G -p thread_pools=2 -p thread_pool_min=100 -p thread_pool_max=500 -p thread_pool_add_delay=2 -p listen_depth=4096 -p session_linger=50/100/150 -p lru_interval=20 -p sess_workspace=512000 }}} {{{ Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22056) died signal=6 Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22056) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache-worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaaac19008 { fd = 12, id = 12, xid = 733244310, client = 209.151.227.72 56196, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaac19080 { id = "sess", {s,f,r,e} = {0x2aaaaac19cd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaaac19080[sess] Oct 29 06:18:57 kitty1 /raid0[21974]: child (22075) Started Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22075) said Oct 29 06:18:57 kitty1 /raid0[21974]: Child (22075) said Child starts Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22075) died signal=6 Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22075) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaab0af008 { fd = 12, id = 12, xid = 227475721, client = 209.151.227.72 57424, step = STP_DELIVER, handling = deliver, restarts = 0, esis = 0 ws = 0x2aaaab0af080 { id = "sess", {s,f,r,e} = {0x2aaaab0afcd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaab0af080[sess] "GET", "/", "HTTP/1. Oct 29 06:19:47 kitty1 /raid0[21974]: child (22094) Started Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22094) said Oct 29 06:19:47 kitty1 /raid0[21974]: Child (22094) said Child starts Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22094) died signal=6 Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22094) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaaabe8008 { fd = 14, id = 14, xid = 170289336, client = 209.151.227.72 57483, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaabe8080 { id = "sess", {s,f,r,e} = {0x2aaaaabe8cd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaaabe8080[sess] Oct 29 06:19:49 kitty1 /raid0[21974]: child (22113) Started Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22113) said Oct 29 06:19:49 kitty1 /raid0[21974]: Child (22113) said Child starts Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22113) died signal=6 Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22113) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424a46: varnishd [0x424a46] 0x420433: varnishd(http_Write+0x293) [0x420433] 0x426fab: varnishd(RES_WriteObj+0x12b) [0x426fab] 0x413b7a: varnishd [0x413b7a] 0x4148e9: varnishd(CNT_Session+0x369) [0x4148e9] 0x426e08: varnishd [0x426e08] 0x4260f7: varnishd [0x4260f7] 0x2b5a67c2173d: /lib64/libpthread.so.0 [0x2b5a67c2173d] 0x2b5a683a5d1d: /lib64/libc.so.6(clone+0x6d) [0x2b5a683a5d1d] sp = 0x2aaaab336008 { fd = 22, id = 22, xid = 161296516, client = 209.151.227.72 57576, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaab336080 { id = "sess", {s,f,r,e} = {0x2aaaab336cd8,+216,(nil),+65536}, }, http[req] = { ws = 0x2aaaab336080[sess] Oct 29 06:19:53 kitty1 /raid0[21974]: child (22132) Started Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22132) said Oct 29 06:19:53 kitty1 /raid0[21974]: Child (22132) said Child starts }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 14:06:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 14:06:16 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.a87b2197e825350f0782545cf1ebb023@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | 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: (In [5491]) If requests come in fast enough on a single connection, typically when running synthetic benchmarks, we need to reset the worker threads workspace between requests, or we will eventually run out. This is an embarrasingly old bug. Fixes: #808 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 15:03:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 15:03:18 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.1968ec0791e3946d33d2854a16f82145@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by diego): * status: closed => reopened * resolution: fixed => Comment: Just tested svn 5491 build and it is still asserting. {{{ Nov 2 14:56:52 kitty1 /raid0[27780]: Child (27991) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424ad6: pan_ic+b6 0x4204c3: http_Write+293 0x42703b: RES_WriteObj+12b 0x413c0a: cnt_deliver+19a 0x414979: CNT_Session+369 0x426e98: wrk_do_cnt_sess+b8 0x426187: wrk_thread_real+337 0x2ad189ee873d: _end+2ad189882565 0x2ad18a66cd1d: _end+2ad18a006b45 sp = 0x2aaaef802008 { fd = 12, id = 12, xid = 1337525629, client = 111.151.227.72 5546, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaef802080 { id = "sess", {s,f,r,e} = {0x2aaaef802cd8,+216,(nil),+512000}, }, http[req] = { ws = 0x2aaaef802080[sess] "GET", "/", "HTTP/1.1", "User-Agent: httperf/0.9.0", "X-Forwarded-For: 111.151.227.72", "host: w Nov 2 14:56:52 kitty1 /raid0[27780]: child (28202) Started Nov 2 14:56:52 kitty1 /raid0[27780]: Child (28202) said Nov 2 14:56:52 kitty1 /raid0[27780]: Child (28202) said Child starts Nov 2 14:57:00 kitty1 /raid0[27780]: Child (28202) died signal=6 Nov 2 14:57:00 kitty1 /raid0[27780]: Child (28202) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424ad6: pan_ic+b6 0x4204c3: http_Write+293 0x42703b: RES_WriteObj+12b 0x413c0a: cnt_deliver+19a 0x414979: CNT_Session+369 0x426e98: wrk_do_cnt_sess+b8 0x426187: wrk_thread_real+337 0x2ad189ee873d: _end+2ad189882565 0x2ad18a66cd1d: _end+2ad18a006b45 sp = 0x2aaaeee80008 { fd = 22, id = 22, xid = 220588095, client = 111.151.227.72 5844, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaeee80080 { id = "sess", {s,f,r,e} = {0x2aaaeee80cd8,+216,(nil),+512000}, }, http[req] = { ws = 0x2aaaeee80080[sess] "GET", "/", "HTTP/1.1", "User-Agent: httperf/0.9.0", "X-Forwarded-For: 111.151.227.72", "host: ww Nov 2 14:57:00 kitty1 /raid0[27780]: child (28411) Started Nov 2 14:57:00 kitty1 /raid0[27780]: Child (28411) said Nov 2 14:57:00 kitty1 /raid0[27780]: Child (28411) said Child starts Nov 2 14:57:14 kitty1 /raid0[27780]: Child (28411) died signal=6 Nov 2 14:57:14 kitty1 /raid0[27780]: Child (28411) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache- worker) ident = Linux,2.6.18-164.11.1.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424ad6: pan_ic+b6 0x4204c3: http_Write+293 0x42703b: RES_WriteObj+12b 0x413c0a: cnt_deliver+19a 0x414979: CNT_Session+369 0x426e98: wrk_do_cnt_sess+b8 0x426187: wrk_thread_real+337 0x2ad189ee873d: _end+2ad189882565 0x2ad18a66cd1d: _end+2ad18a006b45 sp = 0x2aaaee880008 { fd = 14, id = 14, xid = 68105016, client = 111.151.227.72 6253, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaee880080 { id = "sess", {s,f,r,e} = {0x2aaaee880cd8,+216,(nil),+512000}, }, http[req] = { ws = 0x2aaaee880080[sess] "GET", "/", "HTTP/1.1", "User-Agent: httperf/0.9.0", "X-Forwarded-For: 111.151.227.72", "host: www Nov 2 14:57:14 kitty1 /raid0[27780]: child (28620) Started Nov 2 14:57:14 kitty1 /raid0[27780]: Child (28620) said Nov 2 14:57:14 kitty1 /raid0[27780]: Child (28620) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 15:27:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 15:27:44 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.90256671a15d57169924a1da809cef27@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by phk): Are you 100% sure you have the fix in ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 2 15:55:38 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Nov 2010 15:55:38 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.32c1c9a2031243bb9146c22914778816@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by diego): I removed the running varnishd from /usr/local/sbin. Rechecked out a new trunk from svn 5491, compiled and manually copied the compiled binary to /usr/local/sbin. [root at kitty1 install]# varnishd -V varnishd (varnish-trunk SVN 5491) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS I even checked the 5491 commit file to make sure the change you made is there. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 07:13:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 07:13:28 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.da37c444e019c6defb8a2676a350cf7b@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by tfheen): Can you please include the exact VCL snippet you are using? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 08:16:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 08:16:40 -0000 Subject: [Varnish] #803: If-Modified-Since + pass hangs until backend closes connection In-Reply-To: <040.bbd3b8a33f6f2406383a7ea691fa094b@varnish-cache.org> References: <040.bbd3b8a33f6f2406383a7ea691fa094b@varnish-cache.org> Message-ID: <049.80fd87ce095827c459fcd94f4519918c@varnish-cache.org> #803: If-Modified-Since + pass hangs until backend closes connection --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment(by tfheen): (In [5493]) Merge r5478: Special case beresp status 1xx, 204 and 304, they have no body. (r5477 is a requirement for this fix) Fixes: #803 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 09:06:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 09:06:21 -0000 Subject: [Varnish] #796: ban lurker deadlock in varnish 2.1.3 In-Reply-To: <047.daacaf2481cbc4cc522f124139b268c4@varnish-cache.org> References: <047.daacaf2481cbc4cc522f124139b268c4@varnish-cache.org> Message-ID: <056.ced77188b3ca854803ce2cbd8e122ddf@varnish-cache.org> #796: ban lurker deadlock in varnish 2.1.3 ---------------------------------+------------------------------------------ Reporter: ryan.krebs | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: ban lurker deadlock | ---------------------------------+------------------------------------------ Comment(by tfheen): (In [5495]) Merge r5432: Fix lock-order inversion in ban lurker thread There is a potential lock-order inversion between a worker thread and the ban-lurker and there is nothing we can do about it: They come from opposite ends of the world. Resolve this by using a TryLock in the ban-lurker and abandon the attempt if we fail to get the lock. Fixes: #796 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 09:50:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 09:50:40 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.48025edc35cf8b1745edd534bd675d6c@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by David Busby): The following is current what is being tested: {{{ sub vcl_fetch { /* if internal server error encountered set grace to 60s and restart, this should keep serving old content untill the backend is returned to service, you may want to include other codes on a per application basis (403/503 in drupal for example) */ if( beresp.status == 500 ){ if(req.restarts < 4){ set beresp.grace = 60s; C{ syslog(LOG_ERR, "Spurious response from backend: xid %s request %s %s \"%s\" %d \"%s\" \"%s\"", VRT_r_req_xid(sp), VRT_r_req_request(sp), VRT_GetHdr(sp, HDR_REQ, "\005host:"), VRT_r_req_url(sp), VRT_r_beresp_status(sp), VRT_r_beresp_response(sp), VRT_GetHdr(sp, HDR_OBJ, "\011Location:")); }C restart; } ... }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 09:52:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 09:52:36 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.ba7fd7a0203fd9506bdbaa0b9d6a3280@varnish-cache.org> #802: Assert error in VRT_r_obj_status() -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Keywords: VRT_r_obj_status -------------------------+-------------------------------------------------- Comment(by David Busby): This is the code to recreate the original reported issues {{{ if(req.restarts < 4){ set beresp.grace = 60s; C{ syslog(LOG_ERR, "Spurious response from backend: xid %s request %s %s \"%s\" %d \"%s\" \"%s\"", VRT_r_req_xid(sp), VRT_r_req_request(sp), VRT_GetHdr(sp, HDR_REQ, "\005host:"), VRT_r_req_url(sp), VRT_r_obj_status(sp), VRT_r_obj_response(sp), VRT_GetHdr(sp, HDR_OBJ, "\011Location:")); }C restart; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 10:35:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 10:35:32 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.28e98fdd4a2889e5dc877d46b3838c2c@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by phk): Can I get you to run varnishd by hand, with the -d option, so we get the full debug output ? Can you reproduce with the default VCL code, or only with your custom VCL ? Can you capture the varnishlog output for one of these transactions with your custom VCL ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 10:49:54 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 10:49:54 -0000 Subject: [Varnish] #804: Invalid command line option in varnishtest.1 In-Reply-To: <047.028f94ba444956a6d18d2c68d6b4ba1b@varnish-cache.org> References: <047.028f94ba444956a6d18d2c68d6b4ba1b@varnish-cache.org> Message-ID: <056.493bb3374f7e0ca3a6dd5c85abad5bf9@varnish-cache.org> #804: Invalid command line option in varnishtest.1 -------------------------+-------------------------------------------------- Reporter: bonetruck2 | Type: documentation Status: closed | Priority: low Milestone: | Component: documentation Version: 2.1.4 | Severity: minor Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5496]) Remove documentation of no longer existant -L option. Fixes: #804 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 17:29:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 17:29:20 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.d95ce86ae821c5cc4167ffe6e28c5084@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by diego): Conclusion: the 5491 commit does resolve the above bug report. I have isolated my end of the problem and it is ridiculous, almost ludicrous. To make sure it wasn't this one machine acting up I tested the new SVN builds on 8 almost identical servers. Out of the 8, 2 are using a 3.0ghz old Intel XEON chip in hyperthreading mode.The other 6 are using 3.2ghz same generation Intel Xeon Chip in hyperthreading mode. Everything else is the same: bios, os, ram, hd, etc. The 6 servers are running perfectly under load testing. For whatever god knows what, the 2 servers running the 3.0ghz chips are asserting at the same point using httperf regardless of amount of times I remove all instances of libvar*, varnish*, and re-compile/re-install. This is much more than coincidence and and I don't know what to make of it. Hardware bug? Whatever the case, I'm taking these 2 duds offline. Sorry for wasting your time on this witch hunt. I still can't believe what I found. Here is the debug output with -d option from those 2 screw-ups just for fun. {{{ Child (13102) died signal=6 Child (13102) Panic message: Assert error in http_Write(), cache_http.c line 918: Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true. thread = (cache-worker) ident = Linux,2.6.18-194.17.4.el5,x86_64,-smalloc,-hcritbit,epoll Backtrace: 0x424ad6: pan_ic+b6 0x4204c3: http_Write+293 0x42703b: RES_WriteObj+12b 0x413c0a: cnt_deliver+19a 0x414979: CNT_Session+369 0x426e98: wrk_do_cnt_sess+b8 0x426187: wrk_thread_real+337 0x2ac420a5173d: _end+2ac4203eb565 0x2ac4211d5f6d: _end+2ac420b6fd95 sp = 0x2aaaee480008 { fd = 20, id = 20, xid = 477739414, client = 111.151.227.72 27870, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaee480080 { id = "sess", {s,f,r,e} = {0x2aaaee480cd8,+216,(nil),+512000}, }, http[req] = { ws = 0x2aaaee480080[sess] "GET", "/", "HTTP/1.1", "User-Agent: httperf/0.9.0", "X-Forwarded-For: 111.151.227.72", "host: www.myserver.net", "Accept-Encoding: gzip", }, worker = 0x2aaaaef04e60 { ws = 0x2aaaaef04fd0 { overflow id = "wrk", {s,f,r,e} = {0x2aaaaee85e10,+512000,(nil),+512000}, }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x2aaaab11c800 { xid = 477735378, ws = 0x2aaaab11c820 { id = "obj", {s,f,r,e} = {0x2aaaab11ca38,+352,(nil),+360}, }, http[obj] = { ws = 0x2aaaab11c820[obj] "HTTP/1.1", "OK", "Content-Encoding: gzip", "Vary: Accept-Encoding", "Date: Wed, 03 Nov 2010 15:42:30 GMT", "Server: LiteSpeed", "Keep-Alive: timeout=5, max=100", "Cache-Control: public,max-age=300", "Last-Modified: Wed, 03 Nov 2010 15:42:30 GMT", "Content-Type: text/html; charset=UTF-8", "Content-Length: 5793", }, len = 5793, store = { 5793 { 1f 8b 08 00 00 00 00 00 02 03 d5 3c 6b 73 db b6 |........... Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 17:41:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 17:41:36 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.9e31429f9fa55ba49bbc3c552552f5d9@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by phk): Uhm, I wouldn't blame hardware (yet), this bug could be highly sensitive to scheduling, so different numbers of cores/HTT or clockfrequency could make it more or less likely to happen. So I would really still like if you could tell me the answers to the questions above... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 18:06:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 18:06:01 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.f3e499dccf961a2057462d93dbdf6477@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment(by diego): Not a hardware issue. Final finding and this is a compile/install/-v version confusion issue. Using lsof on the running varnishd I was able to track down the problem. On those 2 servers that had issues they had out-dated (dated oct,2010) varnishd binary in the .libs folder within /usr/local/sbin. I did not even realize the compiled varnishd is just a link to load .libs/varnishd. Make install never works for me due to "rst2man" dependency so I just opted to manually copy the binary over to /usr/local/sbin not realizing the real binary is in the .libs folder. After removing those old binaries and copying over new ones, the asserts went away. But why is "varnishd -V" showing the current build version when it might be linked to the old binary? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 3 18:40:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Nov 2010 18:40:34 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.d2e7ebcff91aca5f9167c0c32cc44e35@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: Ok, Cool, thanks a lot for taking the time to nail this down. I'll close the ticket again then. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 4 07:56:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Nov 2010 07:56:30 -0000 Subject: [Varnish] #802: Assert error in VRT_r_obj_status() In-Reply-To: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> References: <048.afbc985f16dc884570f0b345a90c7b35@varnish-cache.org> Message-ID: <057.51453ae35b19835486602d331851a1f5@varnish-cache.org> #802: Assert error in VRT_r_obj_status() ------------------------------+--------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishd | Version: 2.1.4 Severity: minor | Resolution: invalid Keywords: VRT_r_obj_status | ------------------------------+--------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: There is no obj object in vcl_fetch, but you are using VRT_r_obj_status(sp), VRT_r_obj_response as well as fetching from HDR_OBJ rather than HDR_BERESP. That won't work, use VRT_r_beresp_status and its friends. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 4 10:13:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Nov 2010 10:13:33 -0000 Subject: [Varnish] #806: invalid Content-Length results in hang and then 503 In-Reply-To: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> References: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> Message-ID: <053.8ea15a01f0d0a641beec37136ea34733@varnish-cache.org> #806: invalid Content-Length results in hang and then 503 ----------------------+----------------------------------------------------- Reporter: amorton | 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: (In [5503]) We have to check the magic status before other length indications, otherwise we cannot pass a 304 with a Content-Length. (RFC2616 p33 4.4) Fixes: #806 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 4 10:41:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Nov 2010 10:41:14 -0000 Subject: [Varnish] #795: Conditional GETs based on modification time are not honored if Last-Modified was not explicitly set In-Reply-To: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> References: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> Message-ID: <050.c577ebc4484f391ee48d23810ab9fd65@varnish-cache.org> #795: Conditional GETs based on modification time are not honored if Last- Modified was not explicitly set ---------------------+------------------------------------------------------ Reporter: runa | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by phk): * status: reopened => closed * resolution: => fixed Comment: (In [5505]) Change how we do If-Modified-Since on objects without a Last- Modified header. Until now, we have not allowed IMS on objects without LM header but after due consideration of our role as web-server, that restriction is found too hard: Varnish will, by definition, not find and object which is not valid, so we can trust the time we put it into the cache to be the LM date. But we can not synthesize a LM header based on this, as this would allow down-stream client-side caches to make unwarranted decisions (see RFC2616 13.3.4 p88) Fixes: #795 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 4 10:50:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Nov 2010 10:50:19 -0000 Subject: [Varnish] #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request In-Reply-To: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> References: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> Message-ID: <058.3cd65bb85cfe12dc3fd3e2d12b9f7fba@varnish-cache.org> #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request --------------------------+------------------------------------------------- Reporter: jim.robinson | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.1.3 Severity: normal | Keywords: http_range_support byte range set --------------------------+------------------------------------------------- Changes (by phk): * owner: => phk Old description: > Varnish 2.1.3 byte range support fails to work when handed a set of > ranges. > > The HTTP 1.1 specification, section "14.35.1 Byte Ranges" specifies > that > > {{{ > "A byte range operation MAY specify a single range of bytes, > or a set of ranges within a single entity." > }}} > > Given a simple VCL of: > > {{{ > backend default { > .host = "127.0.0.1"; > .port = "80"; > } > }}} > > where the backend is an Apache 2.2.14 server, we can start up varnishd > on port 4040 and activate range support: > > {{{ > $ sudo /usr/local/varnish/2.1.3/sbin/varnishd -d -P /var/run/varnish.pid > -a localhost:4040 -f /usr/local/varnish/2.1.3/etc/varnish/test.vcl -u > nobody -g nobody -s malloc,10M > > storage_malloc: max size 10 MB. > Using old SHMFILE > Varnish on Darwin,9.8.0,i386,-smalloc,-hcritbit > 200 193 > ----------------------------- > Varnish HTTP accelerator CLI. > ----------------------------- > Type 'help' for command list. > Type 'quit' to close CLI session. > Type 'start' to launch worker process. > > start > child (69026) Started > 200 0 > > param.set http_range_support on > 200 0 > }}} > > In another window we first issue a curl request to our apache server and > ask for the first four bytes as a set of 1-byte ranges: > > {{{ > $ curl -s -i -HRange:bytes=0-0,1-1,2-2,3-3 http://127.0.0.1/test.pdf > HTTP/1.1 206 Partial Content > Date: Mon, 04 Oct 2010 19:46:25 GMT > Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 > OpenSSL/0.9.7a > Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT > ETag: "11fc13b-11893e-48af73a5d3ba1" > Accept-Ranges: bytes > Content-Length: 389 > Content-Type: multipart/byteranges; boundary=491cfccba1f8e35b9 > > --491cfccba1f8e35b9 > Content-type: application/pdf > Content-range: bytes 0-0/1149246 > > % > --491cfccba1f8e35b9 > Content-type: application/pdf > Content-range: bytes 1-1/1149246 > > P > --491cfccba1f8e35b9 > Content-type: application/pdf > Content-range: bytes 2-2/1149246 > > D > --491cfccba1f8e35b9 > Content-type: application/pdf > Content-range: bytes 3-3/1149246 > > F > --491cfccba1f8e35b9-- > }}} > > Now while we can issue a single range request to varnish and get back the > right thing: > > {{{ > $ curl -s -i -HRange:bytes=1-1 http://localhost:4040/test.pdf ; echo > HTTP/1.1 206 Partial Content > Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 > OpenSSL/0.9.7a > Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT > ETag: "11fc13b-11893e-48af73a5d3ba1" > Content-Type: application/pdf > Accept-Ranges: bytes > Date: Mon, 04 Oct 2010 19:46:33 GMT > X-Varnish: 716983327 716983316 > Age: 189 > Via: 1.1 varnish > Connection: keep-alive > Content-Range: bytes 1-1/1149246 > Content-Length: 1 > > P > }}} > > But we cannot issue a set of ranges: > > {{{ > $ curl -s -i -HRange:bytes=0-0,1-1,2-2,3-3 > http://localhost:4040/test.pdf | strings | head -51param.set > http_range_support on > HTTP/1.1 200 OK > Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 > OpenSSL/0.9.7a > Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT > ETag: "11fc13b-11893e-48af73a5d3ba1" > Content-Type: application/pdf > Content-Length: 1149246 > Accept-Ranges: bytes > Date: Mon, 04 Oct 2010 19:46:46 GMT > X-Varnish: 716983328 716983316 > Age: 203 > Via: 1.1 varnish > Connection: keep-alive > %PDF-1.4 > 45 0 obj > ... rest of the entire PDF elided... > }}} > > The problem appears to be that cache_response.c has an assumption built > into the logic that byte range requests aren't multi-sequence: > > {{{ > 278 if (sp->disable_esi || sp->esis == 0) { > 279 /* For none ESI and non ESI-included objects, try Range > */ > 280 if (params->http_range_support && > 281 (sp->disable_esi || sp->esis == 0) && > 282 sp->obj->response == 200 && > 283 sp->wantbody && > 284 http_GetHdr(sp->http, H_Range, &r)) > 285 res_dorange(sp, r, &low, &high); > 286 > 287 sp->acct_tmp.hdrbytes += http_Write(sp->wrk, > sp->wrk->resp, 1); > }}} > > The res_dorange request that calculates the range and the subsequent call > to http_Write assume only a single range, not a set of ranges. > > Jim New description: Varnish 2.1.3 byte range support fails to work when handed a set of ranges. The HTTP 1.1 specification, section "14.35.1 Byte Ranges" specifies that {{{ "A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity." }}} Given a simple VCL of: {{{ backend default { .host = "127.0.0.1"; .port = "80"; } }}} where the backend is an Apache 2.2.14 server, we can start up varnishd on port 4040 and activate range support: {{{ $ sudo /usr/local/varnish/2.1.3/sbin/varnishd -d -P /var/run/varnish.pid -a localhost:4040 -f /usr/local/varnish/2.1.3/etc/varnish/test.vcl -u nobody -g nobody -s malloc,10M storage_malloc: max size 10 MB. Using old SHMFILE Varnish on Darwin,9.8.0,i386,-smalloc,-hcritbit 200 193 ----------------------------- Varnish HTTP accelerator CLI. ----------------------------- Type 'help' for command list. Type 'quit' to close CLI session. Type 'start' to launch worker process. start child (69026) Started 200 0 param.set http_range_support on 200 0 }}} In another window we first issue a curl request to our apache server and ask for the first four bytes as a set of 1-byte ranges: {{{ $ curl -s -i -HRange:bytes=0-0,1-1,2-2,3-3 http://127.0.0.1/test.pdf HTTP/1.1 206 Partial Content Date: Mon, 04 Oct 2010 19:46:25 GMT Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 OpenSSL/0.9.7a Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT ETag: "11fc13b-11893e-48af73a5d3ba1" Accept-Ranges: bytes Content-Length: 389 Content-Type: multipart/byteranges; boundary=491cfccba1f8e35b9 --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 0-0/1149246 % --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 1-1/1149246 P --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 2-2/1149246 D --491cfccba1f8e35b9 Content-type: application/pdf Content-range: bytes 3-3/1149246 F --491cfccba1f8e35b9-- }}} Now while we can issue a single range request to varnish and get back the right thing: {{{ $ curl -s -i -HRange:bytes=1-1 http://localhost:4040/test.pdf ; echo HTTP/1.1 206 Partial Content Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 OpenSSL/0.9.7a Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT ETag: "11fc13b-11893e-48af73a5d3ba1" Content-Type: application/pdf Accept-Ranges: bytes Date: Mon, 04 Oct 2010 19:46:33 GMT X-Varnish: 716983327 716983316 Age: 189 Via: 1.1 varnish Connection: keep-alive Content-Range: bytes 1-1/1149246 Content-Length: 1 P }}} But we cannot issue a set of ranges: {{{ $ curl -s -i -HRange:bytes=0-0,1-1,2-2,3-3 http://localhost:4040/test.pdf | strings | head -51param.set http_range_support on HTTP/1.1 200 OK Server: Apache/2.2.14 (Unix) DAV/2 mod_jk/1.2.28 mod_ssl/2.2.14 OpenSSL/0.9.7a Last-Modified: Fri, 09 Jul 2010 16:52:27 GMT ETag: "11fc13b-11893e-48af73a5d3ba1" Content-Type: application/pdf Content-Length: 1149246 Accept-Ranges: bytes Date: Mon, 04 Oct 2010 19:46:46 GMT X-Varnish: 716983328 716983316 Age: 203 Via: 1.1 varnish Connection: keep-alive %PDF-1.4 45 0 obj ... rest of the entire PDF elided... }}} The problem appears to be that cache_response.c has an assumption built into the logic that byte range requests aren't multi-sequence: {{{ 278 if (sp->disable_esi || sp->esis == 0) { 279 /* For none ESI and non ESI-included objects, try Range */ 280 if (params->http_range_support && 281 (sp->disable_esi || sp->esis == 0) && 282 sp->obj->response == 200 && 283 sp->wantbody && 284 http_GetHdr(sp->http, H_Range, &r)) 285 res_dorange(sp, r, &low, &high); 286 287 sp->acct_tmp.hdrbytes += http_Write(sp->wrk, sp->wrk->resp, 1); }}} The res_dorange request that calculates the range and the subsequent call to http_Write assume only a single range, not a set of ranges. Jim -- Comment: Sorry about the delay in replying. Yes, you are right, we only handle a single byterange interval at present, my survey of the net found no significant usage of multi-range requests. Do you know of any applications that actually use multi-range requests ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 4 11:03:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Nov 2010 11:03:04 -0000 Subject: [Varnish] #789: v2.1.3 w/ http_range_support on strips Content-Range on pass In-Reply-To: <049.fed33db428dab02e8bee5fad46a1664b@varnish-cache.org> References: <049.fed33db428dab02e8bee5fad46a1664b@varnish-cache.org> Message-ID: <058.40baf5e1996096f315b196e4375e8a85@varnish-cache.org> #789: v2.1.3 w/ http_range_support on strips Content-Range on pass ---------------------------+------------------------------------------------ Reporter: jim.robinson | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Resolution: fixed | Keywords: http_range_support byte range content-range stripped ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5506]) Do not filter out Content-Range headers in pass. Fixes: #789 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 4 11:28:09 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Nov 2010 11:28:09 -0000 Subject: [Varnish] #800: 5452 Breaks Solaris Build In-Reply-To: <044.9a5280eb866b57287b8dce305b7d2c44@varnish-cache.org> References: <044.9a5280eb866b57287b8dce305b7d2c44@varnish-cache.org> Message-ID: <053.d5ee080d5188014816925058c2c1c2bf@varnish-cache.org> #800: 5452 Breaks Solaris Build ----------------------+----------------------------------------------------- Reporter: victori | 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: (In [5507]) Add a SIGALRM based timeout mechanism for test-termnation, for OS's like Solaris which do not have pthread_timedjoin_np() Fixes: #800 -- Ticket URL: Varnish The Varnish HTTP Accelerator From jim.robinson at stanford.edu Thu Nov 4 12:31:01 2010 From: jim.robinson at stanford.edu (James A. Robinson) Date: Thu, 4 Nov 2010 05:31:01 -0700 Subject: [Varnish] #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request In-Reply-To: <058.3cd65bb85cfe12dc3fd3e2d12b9f7fba@varnish-cache.org> References: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> <058.3cd65bb85cfe12dc3fd3e2d12b9f7fba@varnish-cache.org> Message-ID: On Thu, Nov 4, 2010 at 03:50, Varnish wrote: > #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request > --------------------------+------------------------------------------------- > ?Reporter: ?jim.robinson ?| ? ? ? Owner: ?phk > ? ? Type: ?defect ? ? ? ?| ? ? ?Status: ?new > ?Priority: ?normal ? ? ? ?| ? Milestone: > Component: ?build ? ? ? ? | ? ? Version: ?2.1.3 > ?Severity: ?normal ? ? ? ?| ? ?Keywords: ?http_range_support byte range set > --------------------------+------------------------------------------------- ... > Comment: > > ?Sorry about the delay in replying. > > ?Yes, you are right, we only handle a single byterange interval at present, > ?my survey of the net found no significant usage of multi-range requests. > > ?Do you know of any applications that actually use multi-range requests ? Hello, It appears as though the problem surfaces with newer Google Chrome browser using both Adobe 8 and Adobe 9 plugins under Window, when dealing with a linearized PDF. According to the original report the problem may also exist under Windows with Firefox and using Adobe 8 plugin. I don't have that setup myself, but that is what I saw when I ran a packet sniffer to capture data from an individual who was seeing problems: http://www.screencast.com/t/MGZkYWY4Yj that I eventually traced to the varnish layer. The behavior he was seeing was due to his Chrome browser sending Range: bytes=1-1,2594-4095 when encountering one of these PDFs. Jim From varnish-bugs at varnish-cache.org Sat Nov 6 12:56:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 06 Nov 2010 12:56:25 -0000 Subject: [Varnish] #810: Varnish 2.1.4 packages won't install on Centos 5.5 Message-ID: <050.6c021325f8537463f32978bb2b898818@varnish-cache.org> #810: Varnish 2.1.4 packages won't install on Centos 5.5 ---------------------------------+------------------------------------------ Reporter: chadwackerman | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: build Version: 2.1.4 | Severity: normal Keywords: | ---------------------------------+------------------------------------------ Seeing the same problem as reported on the mailing list: http://www.gossamer-threads.com/lists/varnish/misc/16706 Trying yum --nogpgcheck and setting gpgcheck=0 in /etc/yum.repos.d/varnish.repo doesn't solve it. Nothing gets installed. ---- Downloading Packages: (1/2): varnish-libs-2.1.4-1.el5.x86_64.rpm | 98 kB 00:00 (2/2): varnish-2.1.4-1.el5.x86_64.rpm | 293 kB 00:00 ---------------------------------------------------------------------------------------------------- Total 246 kB/s | 391 kB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction error: varnish-libs-2.1.4-1.el5: Header V4 RSA/SHA256 signature: BAD, key ID c4deffeb error: varnish-2.1.4-1.el5: Header V4 RSA/SHA256 signature: BAD, key ID c4deffeb -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 6 13:00:03 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 06 Nov 2010 13:00:03 -0000 Subject: [Varnish] #811: No recent binary packages for 32-bit RHEL/CentOS Message-ID: <050.1325b4e88b8e050530222133dcf1869c@varnish-cache.org> #811: No recent binary packages for 32-bit RHEL/CentOS ---------------------------+------------------------------------------------ Reporter: chadwackerman | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 2.1.4 | Severity: normal Keywords: | ---------------------------+------------------------------------------------ Latest version in the repo is 2.0.4. I raised the issue on the IRC channel and there was consensus that providing 32-bit versions was a good idea. Argument in favor was using it on small slice/frontend machines and also on Amazon's new "free" hosting tier (http://aws.amazon.com/free/) which is optimally used in a 32-bit configuration on small sites. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 9 12:16:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Nov 2010 12:16:32 -0000 Subject: [Varnish] #686: VCL doesn't account for duplicate headers with different content In-Reply-To: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> References: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> Message-ID: <051.0b54facc4f6b86f9d76e832b7b181d05@varnish-cache.org> #686: VCL doesn't account for duplicate headers with different content -------------------------+-------------------------------------------------- Reporter: felix | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: vcl headers | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5531]) One of the silly overgeneralizations in RFC2616, is that headers which contain comma-separated lists, can be spread over multiple header lines. There is no way of knowing if this rule applies to any header not in RFC2616, short of chasing down the relevant standards document, if any, for the particular header. Considering the fact that HTTP header lines have no natural limitation on length AND that RFC2616 already specifies a mechanism for header-continuation, this doesn't add any value, at all. It is hardly a surprise that nobody used this either, so until now, we have ignored this silly stuff and just used the first header we found. But now Chromium, of all things, seems to find it necessary to spread its Cache-Control across two lines, and we get to deal with this crap. Add a function for stitching multiple header lines into one, and call it on Cache-Control in requests to deal with Chromiums issues. Since we have it, call it preemptively on Cache-Control and Vary in backend responses, since the C-code examines these fields. XXX: At some point, add VCL support for collecting specific headers this way. Fixes: #686 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 9 12:21:09 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Nov 2010 12:21:09 -0000 Subject: [Varnish] #811: No recent binary packages for 32-bit RHEL/CentOS In-Reply-To: <050.1325b4e88b8e050530222133dcf1869c@varnish-cache.org> References: <050.1325b4e88b8e050530222133dcf1869c@varnish-cache.org> Message-ID: <059.413ac32d2beafcee535a64e216dfaad9@varnish-cache.org> #811: No recent binary packages for 32-bit RHEL/CentOS ---------------------------+------------------------------------------------ Reporter: chadwackerman | Owner: tfheen Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: 2.1.4 Severity: normal | Keywords: ---------------------------+------------------------------------------------ Changes (by phk): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 9 12:21:29 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Nov 2010 12:21:29 -0000 Subject: [Varnish] #810: Varnish 2.1.4 packages won't install on Centos 5.5 In-Reply-To: <050.6c021325f8537463f32978bb2b898818@varnish-cache.org> References: <050.6c021325f8537463f32978bb2b898818@varnish-cache.org> Message-ID: <059.1246092b827f7b30bfcd3aad2a254ad0@varnish-cache.org> #810: Varnish 2.1.4 packages won't install on Centos 5.5 ---------------------------+------------------------------------------------ Reporter: chadwackerman | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: 2.1.4 Severity: normal | Keywords: ---------------------------+------------------------------------------------ Changes (by phk): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 10 09:29:32 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Nov 2010 09:29:32 -0000 Subject: [Varnish] #812: crash in HSH_Purge Message-ID: <040.1fdd26336fe4b2d2232e12531e6c12eb@varnish-cache.org> #812: crash in HSH_Purge ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- When calling VRT_purge with 0 ttl and 0 grace from vcl_miss sometimes we crash under heavy load. {{{ sub vcl_recv { if(req.request == "PURGE") { set req.hash_ignore_busy = true; } set req.grace = 3600s; return(lookup); } } sub vcl_miss { if (req.request == "PURGE") { C{ VRT_purge(sp, 0, 0); }C error 200 "Ok"; } }}} {{{ hild (30735) died signal=6 Nov 10 04:31:02 varnish-s1 varnishd[2831]: Child (30735) Panic message: Assert error in HSH_Purge(), cache_hash.c line 539: Condition((oc)->magic == 0x4d301302) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker) ident = Linux,2.6.35.3-intel- novirt,x86_64,-sfile,-sfile,-sfile,-hclassic,epoll Backtrace: 0x426188: /usr/sbin/varnishd [0x426188] 0x41f42a: /usr/sbin/varnishd(HSH_Purge+0x22a) [0x41f42a] 0x7f4cb526a577: ./vcl.iQQD1J50.so [0x7f4cb526a577] 0x42b083: /usr/sbin/varnishd(VCL_miss_method+0x43) [0x42b083] 0x413adc: /usr/sbin/varnishd [0x413adc] 0x415cb5: /usr/sbin/varnishd(CNT_Session+0x3a5) [0x415cb5] 0x427938: /usr/sbin/varnishd [0x427938] 0x427d0b: /usr/sbin/varnishd [0x427d0b] 0x7f7adeff5a04: /lib/libpthread.so.0 [0x7f7adeff5a04] 0x7f7ade8c0d4d: /lib/libc.so.6(clone+0x6d) [0x7f7ade8c0d4d] sp = 0x7f4c93902008 { fd = 41, id = 41, xid = 217661109, client = 127.0.0.1 48959, step = STP_MISS, handling = deliver, err_code = 200, err_reason = Ok, restarts = 0, esis = 0 ws = 0x7f4c93902080 { id = "sess", {s,f,r,e} = {0x7f4c93902cd8,+600,(nil),+131072}, }, http[req] = { ws = 0x7f4c93902080[sess] "PURGE", "/index.php?title=Par_Vollen", "HTTP/1.1", "TE: deflate,gzip;q=0.3", "Connection: TE", "Host: dragonage.wikia.com", "User-Agent: HTCP Purger", "X-Logged-In: 0", "X-Timer: S1289363459.012102365,VS0", "X-Forwarded-From: varnish-s1-SJC", "X-Forwarded-For: 127.0.0.1", "X-Origurl: /wiki/Par_Vollen", "X-Transformed-URL: 1", "X-Set-Vary-URL: 1", }, worker = 0x7f48190f9e20 { ws = 0x7f48190f9fa0 { id = "wrk", {s,f,r,e} = {0x7f48190d1dc0,+24,+131072,+131072}, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 10 20:11:46 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Nov 2010 20:11:46 -0000 Subject: [Varnish] #812: crash in HSH_Purge In-Reply-To: <040.1fdd26336fe4b2d2232e12531e6c12eb@varnish-cache.org> References: <040.1fdd26336fe4b2d2232e12531e6c12eb@varnish-cache.org> Message-ID: <049.66d878b944237ae86f80a555f0d3be2b@varnish-cache.org> #812: crash in HSH_Purge ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5532]) "new-purge" cannot and should not touch busy objects, as they are not subject to refcounting. Fixes: #812 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 11 09:13:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Nov 2010 09:13:28 -0000 Subject: [Varnish] #686: VCL doesn't account for duplicate headers with different content In-Reply-To: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> References: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> Message-ID: <051.5e22a9029f43a1ddecb048789f513510@varnish-cache.org> #686: VCL doesn't account for duplicate headers with different content -------------------------+-------------------------------------------------- Reporter: felix | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: vcl headers | -------------------------+-------------------------------------------------- Comment(by phk): (In [5534]) Forgot to commit with with the bugfix Fixes: #686 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 11 17:49:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Nov 2010 17:49:21 -0000 Subject: [Varnish] #813: Varnish 503's w/ FetchError straight read_error: 11 Message-ID: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> #813: Varnish 503's w/ FetchError straight read_error: 11 ----------------------+----------------------------------------------------- Reporter: ntang | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.2 Severity: major | Keywords: ----------------------+----------------------------------------------------- We're serving mp3 files up through Varnish to Apache/ PHP running Wordpress 2.8.4. Apache serves them up fine, but when we put Varnish in front, it spits out a 503 error after a long delay. I'm not sure what's going on, but I'm pretty sure it's not the correct behavior. Here's a sample from the logs: {{{ 12 SessionOpen c 10.50.43.20 24510 :6081 12 ReqStart c 10.50.43.20 24510 1686468638 12 RxRequest c HEAD 12 RxURL c /files/2010/10/HM-33-2-WEB.mp3 12 RxProtocol c HTTP/1.1 12 RxHeader c User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 12 RxHeader c Accept: */* 12 RxHeader c Host: [snip] 12 VCL_call c recv 12 VCL_return c lookup 12 VCL_call c hash 12 VCL_return c hash 12 VCL_call c miss 12 VCL_return c fetch 14 BackendOpen b default 127.0.0.1 56781 127.0.0.1 80 12 Backend c 14 default default 14 TxRequest b GET 14 TxURL b /files/2010/10/HM-33-2-WEB.mp3 14 TxProtocol b HTTP/1.1 14 TxHeader b User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 14 TxHeader b Accept: */* 14 TxHeader b Host: [snip] 14 TxHeader b X-Forwarded-For: 10.50.43.20 14 TxHeader b X-Varnish: 1686468638 14 RxProtocol b HTTP/1.1 14 RxStatus b 200 14 RxResponse b OK 14 RxHeader b Date: Thu, 11 Nov 2010 17:13:05 GMT 14 RxHeader b Server: Apache 14 RxHeader b X-Powered-By: PHP/5.2.4 14 RxHeader b Vary: Cookie 14 RxHeader b Content-Length: 1442796 14 RxHeader b Last-Modified: Thu, 11 Nov 2010 12:13:05 -0500 14 RxHeader b Expires: Sun, 12 Jan 2014 02:59:45 GMT 14 RxHeader b Cache-Control: max-age=3600, must-revalidate 14 RxHeader b Content-Type: audio/mpeg 12 TTL c 1686468638 RFC 3600 1289495585 0 0 3600 0 12 VCL_call c fetch 12 VCL_return c pass 12 ObjProtocol c HTTP/1.1 12 ObjStatus c 200 12 ObjResponse c OK 12 ObjHeader c Date: Thu, 11 Nov 2010 17:13:05 GMT 12 ObjHeader c Server: Apache 12 ObjHeader c X-Powered-By: PHP/5.2.4 12 ObjHeader c Vary: Cookie 12 ObjHeader c Last-Modified: Thu, 11 Nov 2010 12:13:05 -0500 12 ObjHeader c Cache-Control: max-age=3600, must-revalidate 12 ObjHeader c Content-Type: audio/mpeg 12 ObjHeader c magicmarker: 1 12 ObjHeader c X-Cacheable: YES 12 FetchError c straight read_error: 11 14 BackendClose b default 12 VCL_call c error 12 VCL_return c deliver 12 Length c 488 12 VCL_call c deliver 12 VCL_return c deliver 12 TxProtocol c HTTP/1.1 12 TxStatus c 503 12 TxResponse c Service Unavailable 12 TxHeader c Server: Varnish 12 TxHeader c Retry-After: 0 12 TxHeader c Content-Type: text/html; charset=utf-8 12 TxHeader c Content-Length: 488 12 TxHeader c Date: Thu, 11 Nov 2010 17:14:05 GMT 12 TxHeader c X-Varnish: 1686468638 12 TxHeader c Age: 60 12 TxHeader c Via: 1.1 varnish 12 TxHeader c Connection: close 12 TxHeader c X-Cache: MISS 12 ReqEnd c 1686468638 1289495585.225246668 1289495645.490181923 0.000139236 60.264884472 0.000050783 12 SessionClose c error 12 StatSess c 10.50.43.20 24510 60 1 1 0 0 0 251 488 }}} Here's what the curl looks like through Apache: {{{ [root at cc20-43 ~]# curl --head --header "Host: [snip]" cc85-45:80/files/2010/10/HM-33-2-WEB.mp3 HTTP/1.1 200 OK Date: Thu, 11 Nov 2010 17:45:37 GMT Server: Apache X-Powered-By: PHP/5.2.4 Vary: Cookie Content-Length: 1442796 Last-Modified: Thu, 11 Nov 2010 12:45:37 -0500 Expires: Sun, 12 Jan 2014 03:32:17 GMT Cache-Control: max-age=3600, must-revalidate Content-Type: audio/mpeg }}} And here's the curl through Varnish: {{{ [root at cc20-43 ~]# curl --head --header "Host: [snip]" cc85-45:6081/files/2010/10/HM-33-2-WEB.mp3 (pauses for some time...) HTTP/1.1 503 Service Unavailable Server: Varnish Retry-After: 0 Content-Type: text/html; charset=utf-8 Content-Length: 488 Date: Thu, 11 Nov 2010 17:47:29 GMT X-Varnish: 1686468640 Age: 106 Via: 1.1 varnish Connection: close X-Cache: MISS }}} For now, we're going to route around Varnish, but if anyone has any ideas as to why this is happening, that'd be great. Thanks! P.S. The content-length of 1442796 should be correct. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 13 18:02:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 13 Nov 2010 18:02:10 -0000 Subject: [Varnish] #814: yum installation error "[Errno -1] Header is not complete." Message-ID: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> #814: yum installation error "[Errno -1] Header is not complete." ----------------------------+----------------------------------------------- Reporter: patrick.kaiser | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: trunk | Severity: normal Keywords: | ----------------------------+----------------------------------------------- Getting the following errors when trying to install varnish via repository provided by varnish-cache.org on a RHEL5 box: # rpm --nosignature -i http://repo.varnish-cache.org/redhat/el5/noarch /varnish-release-2.1-1.noarch.rpm # yum install varnish[[BR]] ....[[BR]] ---> Downloading header for varnish to pack into transaction set. varnish-2.1.4-1.el5.x86_6 100% |=========================| 18 kB 00:00 http://repo.varnish- cache.org/redhat/varnish-2.1/el5/x86_64/varnish-2.1.4-1.el5.x86_64.rpm: [Errno -1] Header is not complete. Trying other mirror. Error: failure: varnish-2.1.4-1.el5.x86_64.rpm from varnish-2.1: [Errno 256] No more mirrors to try. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 15 13:09:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Nov 2010 13:09:39 -0000 Subject: [Varnish] #813: Varnish 503's w/ FetchError straight read_error: 11 In-Reply-To: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> References: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> Message-ID: <051.4c09353cf0d0564bcfa4f2d6ef5083fe@varnish-cache.org> #813: Varnish 503's w/ FetchError straight read_error: 11 ----------------------+----------------------------------------------------- Reporter: ntang | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.2 Severity: major | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * owner: phk => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 15 13:22:05 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Nov 2010 13:22:05 -0000 Subject: [Varnish] #813: Varnish 503's w/ FetchError straight read_error: 11 In-Reply-To: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> References: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> Message-ID: <051.5401ff42b76d2bda31371f915481eddc@varnish-cache.org> #813: Varnish 503's w/ FetchError straight read_error: 11 ----------------------+----------------------------------------------------- Reporter: ntang | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.2 Severity: major | Keywords: ----------------------+----------------------------------------------------- Comment(by martin): Hello, What you are experiencing is Varnish detecting a timeout on the read from backend. Will a direct get from backend take more than 60 seconds? I see that you have listed this as happening in Varnish version 2.1.2. Could you upgrade to the latest Varnish version 2.1.4 and see if you still experience this? Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 15 13:41:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Nov 2010 13:41:39 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references In-Reply-To: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> References: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> Message-ID: <051.5530cc1b90ca0d362c7b2986390aa9a3@varnish-cache.org> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- Comment(by slink): Results of today's IRC bugwash: * phk will want to close this bug and put it onto the shopping list as a feature request * I've been asked to re-implement this feature as a VMOD ** this will limit the syntax for match backreferences to something like re.backref(n) ** this will also imply that another match function will exist ** I am not sure how to best do RE compilation, but we'll see * phk has clarified that data referred to by a const char * can not even be assumed to continue to exist within the same vcl procedure, so we need to copy... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 15 13:49:09 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Nov 2010 13:49:09 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> Message-ID: <053.1f184c4e7a46a1e8f15a4fe740aa9f15@varnish-cache.org> #633: varnishncsa segfaults -------------------------+-------------------------------------------------- Reporter: victori | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by tfheen): Any chance you could retest current trunk and see if this is still a problem for you there? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 15 14:10:45 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Nov 2010 14:10:45 -0000 Subject: [Varnish] #813: Varnish 503's w/ FetchError straight read_error: 11 In-Reply-To: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> References: <042.cd8906484102a2787785c6a4c8b2aa70@varnish-cache.org> Message-ID: <051.ced36a202586aa9e7a386273c838dc6f@varnish-cache.org> #813: Varnish 503's w/ FetchError straight read_error: 11 ----------------------+----------------------------------------------------- Reporter: ntang | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.1.2 Severity: major | Keywords: ----------------------+----------------------------------------------------- Comment(by ntang): It shouldn't have been a timeout... here's how long it takes when I query Apache directly: {{{ [root at cc20-43 ~]# time curl --head --header "Host: [snip]" cc85-45:80/files/2010/10/HM-33-2-WEB.mp3 HTTP/1.1 200 OK Date: Mon, 15 Nov 2010 14:07:25 GMT Server: Apache X-Powered-By: PHP/5.2.4 Vary: Cookie Content-Length: 1442796 Last-Modified: Mon, 15 Nov 2010 09:07:25 -0500 Expires: Wed, 15 Jan 2014 23:54:05 GMT Cache-Control: max-age=3600, must-revalidate Content-Type: audio/mpeg real 0m0.273s user 0m0.001s sys 0m0.005s [root at cc20-43 ~]# }}} As you can see, it's returning the file in around a quarter of a second. We are planning on upgrading to 2.1.4 to see if it fixes it, but right now there's no 32 bit RPM, so we need to build one ourselves and fixing the problem quickly was our top priority. (For now we're just routing requests for mp3 files straight to Apache, around Varnish, and that's kept things moving smoothly, as we don't get a huge number of requests for them and we've got the capacity there. But obviously, we'd like Varnish to serve all of this content eventually.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 16 12:50:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Nov 2010 12:50:08 -0000 Subject: [Varnish] #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request In-Reply-To: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> References: <049.afaae7a6fae04074165e9905b721ea43@varnish-cache.org> Message-ID: <058.f6d0154d806ff93ab7ad26030fa316ab@varnish-cache.org> #788: v2.1.3 w/ http_range_support on fails to support sets in byte range request --------------------------+------------------------------------------------- Reporter: jim.robinson | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.1.3 Severity: normal | Keywords: http_range_support byte range set --------------------------+------------------------------------------------- Comment(by jnerin): Well, I'm not sure how widespread may be, but I have one example, it's Adobe Acrobat trying to display a pdf embedded in the browser (the pdf file size is 7271640 bytes): Header from a tcpdump decoded with wireshark: {{{ GET /example.pdf HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Range: bytes=8380-32397,8380-8381 }}} If first issues on request with no range: {{{ 702 RxRequest c GET 702 RxURL c /example.pdf 702 RxProtocol c HTTP/1.1 702 RxHeader c Host: www.example.com 702 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) 702 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 702 RxHeader c Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 702 RxHeader c Accept-Encoding: gzip,deflate 702 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 702 RxHeader c Keep-Alive: 115 702 RxHeader c Connection: keep-alive 702 RxHeader c Referer: http://www.example.com/ 702 VCL_call c recv 702 VCL_return c lookup 702 VCL_call c hash 702 VCL_return c hash 702 VCL_call c miss 702 VCL_return c fetch 702 Backend c 674 default default 674 TxRequest b GET 674 TxURL b /example.pdf 674 TxProtocol b HTTP/1.1 674 TxHeader b Host: www.example.com 674 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) 674 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 674 TxHeader b Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 674 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 674 TxHeader b Referer: http://www.example.com/ 674 TxHeader b Accept-Encoding: gzip 674 TxHeader b X-Varnish: 1459169995 [...] 702 TTL c 1459169995 RFC 120 1289908815 0 0 0 0 702 VCL_call c fetch 702 VCL_return c deliver 702 ObjProtocol c HTTP/1.1 702 ObjStatus c 200 702 ObjResponse c OK 702 ObjHeader c Date: Tue, 16 Nov 2010 12:00:15 GMT 702 ObjHeader c Server: Apache 702 ObjHeader c Last-Modified: Tue, 16 Nov 2010 07:38:04 GMT 702 ObjHeader c ETag: "18616f87-6ef4d8-49526a311ef00" 702 ObjHeader c Content-Type: application/pdf 702 ObjHeader c X-Cacheable: YES 674 Length b 7271640 674 BackendReuse b default [...] 702 SessionClose c remote closed 702 VCL_call c deliver 702 VCL_return c deliver 702 TxProtocol c HTTP/1.1 702 TxStatus c 200 702 TxResponse c OK 702 TxHeader c Server: Apache 702 TxHeader c Last-Modified: Tue, 16 Nov 2010 07:38:04 GMT 702 TxHeader c ETag: "18616f87-6ef4d8-49526a311ef00" 702 TxHeader c Content-Type: application/pdf 702 TxHeader c X-Cacheable: YES 702 TxHeader c Content-Length: 7271640 702 TxHeader c Accept-Ranges: bytes 702 TxHeader c Date: Tue, 16 Nov 2010 12:00:15 GMT 702 TxHeader c X-Varnish: 1459169995 702 TxHeader c Age: 0 702 TxHeader c Via: 1.1 varnish 702 TxHeader c Connection: keep-alive 702 TxHeader c X-Served-By: varnish 702 TxHeader c X-Cache: MISS 702 TxHeader c X-Cache-Hits: 0 702 Debug c "Write error, retval = 32120, len = 7272020, errno = Success" -1 Length - 7271640 702 ReqEnd c 1459169995 1289908815.705988407 1289908816.018261433 2.889583826 0.033922911 0.278350115 702 StatSess c xxx.xxx.xxx.xxx 13723 3 1 3 0 0 2 1179 7272197 }}} Then reissues the same request but with a range: {{{ 282 ReqStart c xxx.xxx.xxx.xxx 13724 1459170027 282 RxRequest c GET 282 RxURL c /example.pdf 282 RxProtocol c HTTP/1.1 282 RxHeader c Host: www.example.com 282 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) 282 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 282 RxHeader c Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 282 RxHeader c Accept-Encoding: gzip,deflate 282 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 282 RxHeader c Keep-Alive: 115 282 RxHeader c Connection: keep-alive 282 RxHeader c Range: bytes=8380-32397,8380-8381 282 VCL_call c recv 282 VCL_return c lookup 282 VCL_call c hash 282 VCL_return c hash 282 Hit c 1459169995 282 VCL_call c hit 282 VCL_return c deliver 282 VCL_call c deliver 282 VCL_return c deliver 282 TxProtocol c HTTP/1.1 282 TxStatus c 200 282 TxResponse c OK 282 TxHeader c Server: Apache 282 TxHeader c Last-Modified: Tue, 16 Nov 2010 07:38:04 GMT 282 TxHeader c ETag: "18616f87-6ef4d8-49526a311ef00" 282 TxHeader c Content-Type: application/pdf 282 TxHeader c X-Cacheable: YES 282 TxHeader c Content-Length: 7271640 282 TxHeader c Accept-Ranges: bytes 282 TxHeader c Date: Tue, 16 Nov 2010 12:00:15 GMT 282 TxHeader c X-Varnish: 1459170027 1459169995 282 TxHeader c Age: 0 282 TxHeader c Via: 1.1 varnish 282 TxHeader c Connection: keep-alive 282 TxHeader c X-Served-By: varnish 282 TxHeader c X-Cache: HIT 282 TxHeader c X-Cache-Hits: 1 282 Length c 7271640 282 ReqEnd c 1459170027 1289908815.935475588 1289908831.356354237 3.038742304 0.000062466 15.420816183 }}} At this point the browser is stuck waiting for data forever. I don't know why it asks for this absurd range pair. For the moment we have sidestepped the issue adding this to vcl_recv: {{{ vcl_recv { [...] if (req.http.Range) { return(pipe); } [...] } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 17 11:15:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Nov 2010 11:15:41 -0000 Subject: [Varnish] #815: varnish 2.1.4 source debian package does not compile under lenny Message-ID: <045.2ae27a79d063a9f74e0a685dbe606111@varnish-cache.org> #815: varnish 2.1.4 source debian package does not compile under lenny -----------------------------------------+---------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: Varnish 2.1 release | Component: packaging Version: 2.1.4 | Severity: normal Keywords: debian source package lenny | -----------------------------------------+---------------------------------- Hi, I tried to build debian package for 2.1.4 on a lenny box and it failed. The error is on the required debhelper version : debian/control asks for >=7.0.50 whereas standard debhelper lenny package is 7.0.15. Simply replacing 7.0.50 by 7.0.15 in debian/control solves the problem. Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 17 13:54:33 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Nov 2010 13:54:33 -0000 Subject: [Varnish] #815: varnish 2.1.4 source debian package does not compile under lenny In-Reply-To: <045.2ae27a79d063a9f74e0a685dbe606111@varnish-cache.org> References: <045.2ae27a79d063a9f74e0a685dbe606111@varnish-cache.org> Message-ID: <054.35a0346eaffb7b331220d2a7987687b4@varnish-cache.org> #815: varnish 2.1.4 source debian package does not compile under lenny ----------------------------------+----------------------------------------- Reporter: tmagnien | Type: defect Status: closed | Priority: normal Milestone: Varnish 2.1 release | Component: packaging Version: 2.1.4 | Severity: normal Resolution: wontfix | Keywords: debian source package lenny ----------------------------------+----------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: You need to enable the backports repository to get an updated debhelper, then it compiles just fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 17 13:55:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Nov 2010 13:55:18 -0000 Subject: [Varnish] #814: yum installation error "[Errno -1] Header is not complete." In-Reply-To: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> References: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> Message-ID: <060.5c9d3680aa3f25601d3c40aeb97819ef@varnish-cache.org> #814: yum installation error "[Errno -1] Header is not complete." -----------------------------+---------------------------------------------- Reporter: patrick.kaiser | Type: defect Status: closed | Priority: normal Milestone: | Component: packaging Version: trunk | Severity: normal Resolution: fixed | Keywords: -----------------------------+---------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: I've updated the installation instructions and rebuilt the RPM now, and it works for me. Please try and see if it works better for you as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 17 13:55:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Nov 2010 13:55:52 -0000 Subject: [Varnish] #810: Varnish 2.1.4 packages won't install on Centos 5.5 In-Reply-To: <050.6c021325f8537463f32978bb2b898818@varnish-cache.org> References: <050.6c021325f8537463f32978bb2b898818@varnish-cache.org> Message-ID: <059.82b45005a91c986e01d890d6777bbdda@varnish-cache.org> #810: Varnish 2.1.4 packages won't install on Centos 5.5 ---------------------------+------------------------------------------------ Reporter: chadwackerman | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: build | Version: 2.1.4 Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This has been fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 17 13:56:59 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Nov 2010 13:56:59 -0000 Subject: [Varnish] #566: varnishncsa segfault during (very) high load In-Reply-To: <045.329d8cea0c94b900f994347642286b5d@varnish-cache.org> References: <045.329d8cea0c94b900f994347642286b5d@varnish-cache.org> Message-ID: <054.21c739348117981704a6bb6b34af9212@varnish-cache.org> #566: varnishncsa segfault during (very) high load -------------------------+-------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Old description: > {{{ > [New process 14993] > #0 0x00002b0fc9fdb397 in VSL_NextLog (vd=0x17729010, pp=0x7fffe0ef8990) > at shmlog.c:315 > 315 if (vd->c_opt && !(vd->map[u] & M_CLIENT)) > (gdb) bt > #0 0x00002b0fc9fdb397 in VSL_NextLog (vd=0x17729010, pp=0x7fffe0ef8990) > at shmlog.c:315 > #1 0x00002b0fc9fdb47b in VSL_Dispatch (vd=0x17729010, func=0x4016f0 > , priv=0x33dff50780) at shmlog.c:349 > #2 0x00000000004012f3 in main (argc=2, argv=) at > varnishncsa.c:589 > (gdb) print vd > $1 = (struct VSL_data *) 0x17729010 > (gdb) print vd->c_opt > $2 = 1 > (gdb) print vd->map > $3 = '\0' , "\001\000", '\001' , '\0' > > (gdb) print u > $4 = 393216 > (gdb) print vd->map[u] > Cannot access memory at address 0x17789154 > (gdb) > }}} > > This typically happens in a matter of a few seconds when I launch my > tests. This is during complete CPU utilization. Core file etc on request. New description: {{{ [New process 14993] #0 0x00002b0fc9fdb397 in VSL_NextLog (vd=0x17729010, pp=0x7fffe0ef8990) at shmlog.c:315 315 if (vd->c_opt && !(vd->map[u] & M_CLIENT)) (gdb) bt #0 0x00002b0fc9fdb397 in VSL_NextLog (vd=0x17729010, pp=0x7fffe0ef8990) at shmlog.c:315 #1 0x00002b0fc9fdb47b in VSL_Dispatch (vd=0x17729010, func=0x4016f0 , priv=0x33dff50780) at shmlog.c:349 #2 0x00000000004012f3 in main (argc=2, argv=) at varnishncsa.c:589 (gdb) print vd $1 = (struct VSL_data *) 0x17729010 (gdb) print vd->c_opt $2 = 1 (gdb) print vd->map $3 = '\0' , "\001\000", '\001' , '\0' (gdb) print u $4 = 393216 (gdb) print vd->map[u] Cannot access memory at address 0x17789154 (gdb) }}} This typically happens in a matter of a few seconds when I launch my tests. This is during complete CPU utilization. Core file etc on request. -- Comment(by tfheen): Can you see if this is still reproducible? I believe it has been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 18 14:02:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Nov 2010 14:02:26 -0000 Subject: [Varnish] #816: Add a way to get the hash used (req.hash) Message-ID: <045.39de2f8fd13b2046e9b673d65cb08483@varnish-cache.org> #816: Add a way to get the hash used (req.hash) -------------------------+-------------------------------------------------- Reporter: grosser2 | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- I want to know the has that was calculated inside vcl_hash (without having to open any logs), something like req.X-hash = req.hash, or even better something to access the hash in the vcl_deliver -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 18 14:46:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Nov 2010 14:46:27 -0000 Subject: [Varnish] #816: Add a way to get the hash used (req.hash) In-Reply-To: <045.39de2f8fd13b2046e9b673d65cb08483@varnish-cache.org> References: <045.39de2f8fd13b2046e9b673d65cb08483@varnish-cache.org> Message-ID: <054.a98d1d6a6b0a169660f5c2ede8d36f82@varnish-cache.org> #816: Add a way to get the hash used (req.hash) -------------------------+-------------------------------------------------- Reporter: grosser2 | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by grosser2): what i am currently using is: set req.http.X-Hash = xxx; set req.http.X-Hash = "#" yyy; ... set req.hash = req.http.X-Hash; and in the app i copy req headers to response headers['X-Hash'] = request.headers['HTTP_X_HASH'] it works but its quiet ugly :> -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 22 08:35:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Nov 2010 08:35:34 -0000 Subject: [Varnish] #816: Add a way to get the hash used (req.hash) In-Reply-To: <045.39de2f8fd13b2046e9b673d65cb08483@varnish-cache.org> References: <045.39de2f8fd13b2046e9b673d65cb08483@varnish-cache.org> Message-ID: <054.53df69e518501f4f4ff2073ae2418ee7@varnish-cache.org> #816: Add a way to get the hash used (req.hash) -------------------------+-------------------------------------------------- Reporter: grosser2 | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: I don't have any better way for you to do it, sorry. We run the hash strings directly into the maul of SHA256 and there is no hope to get them out again unmolested. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 22 08:58:58 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Nov 2010 08:58:58 -0000 Subject: [Varnish] #817: 'varnishadm -T :6082' causes segfault Message-ID: <058.bf8ac99c99ed6a34bdf92a3c80d90e8d@varnish-cache.org> #817: 'varnishadm -T :6082' causes segfault -----------------------------------+---------------------------------------- Reporter: Martin Blix Grydeland | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Keywords: -----------------------------------+---------------------------------------- Since Varnish version 2.1.4, calling varnishadm -T :6082 (using shorthand ':6082' instead of 'localhost:6082') causes the utility to segfault. This is also present on trunk. Worked OK in Varnish 2.1.3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 22 09:08:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Nov 2010 09:08:53 -0000 Subject: [Varnish] #817: 'varnishadm -T :6082' causes segfault In-Reply-To: <058.bf8ac99c99ed6a34bdf92a3c80d90e8d@varnish-cache.org> References: <058.bf8ac99c99ed6a34bdf92a3c80d90e8d@varnish-cache.org> Message-ID: <067.5fe9bbcfa57bc3d9fe9b6d600d245286@varnish-cache.org> #817: 'varnishadm -T :6082' causes segfault -----------------------------------+---------------------------------------- Reporter: Martin Blix Grydeland | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: (In [5580]) Remove call to VSS_parse() in VSS_open(), as VSS_parse() is called in VSS_resolve() anyway. Fixes: #817 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 22 20:34:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Nov 2010 20:34:27 -0000 Subject: [Varnish] #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled Message-ID: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled -------------------+-------------------------------------------------------- Reporter: lew | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- It appears that when receiving a 304 response to a GET from a backend (for example, in response to a request with an If-modified-since header), varnishd may be waiting for a message body that never comes. (since 304s have no body) When a backend has keepalive enabled, it results in a hang on the varnish side until the connection times out and is closed by the backend server. We are experiencing this in our environment where we have varnish in front of apache/2.2.3 backends. It is reproducible in 2.1.4 and trunk with a basic default backend set to an HTTP/1.1 server with keepalive enabled (apache/2.2.3 in our case), by issuing the following request: {{{ GET /test.file HTTP/1.1 Host: your.host Connection: close Cookie: x If-Modified-Since: }}} HEAD requests appear to be handled correctly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 23 08:33:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Nov 2010 08:33:00 -0000 Subject: [Varnish] #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled In-Reply-To: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> References: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> Message-ID: <049.e6ad04f19843658165a37d291008840f@varnish-cache.org> #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled -------------------+-------------------------------------------------------- Reporter: lew | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by lew): Sorry - obviously this should be in as a varnishd issue rather than a build issue. Unfortunately I can't edit the ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 23 11:00:46 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Nov 2010 11:00:46 -0000 Subject: [Varnish] #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled In-Reply-To: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> References: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> Message-ID: <049.d392d968ebaab2968be6818abc86f553@varnish-cache.org> #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled -------------------+-------------------------------------------------------- Reporter: lew | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by lew): Further testing today reveals that I was incorrect about it affecting trunk. I see the relevant changes to rfc2616.c in the revision log, and certainly with rev 5587 everything seems to be working correctly, I think I must have failed to properly clean up between installs. Apologies for the confusion, go ahead and close this I suppose. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 23 15:02:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Nov 2010 15:02:35 -0000 Subject: [Varnish] #819: Persistent storage method, does not persist a service restart Message-ID: <048.1e885abafc72a0de36505c91a4c77df2@varnish-cache.org> #819: Persistent storage method, does not persist a service restart -------------------------+-------------------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: persistent persistence -------------------------+-------------------------------------------------- Using. {{{ -s persistent,/dev/shm/varnish-cache-file.shm,1G }}} Verified cache hit using {{{ sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } }}} And curl -D ./headers.txt http://domainname.com/page/ Checking of X-Cache headers, pre and post restart using init.d script reveal that a HIT is returned prior to restart, and a MISS is returned immediately after. Idealy we are trying to avoid the need to isolate and pre-populate a cache server in the event of a crash/restart and the -s persistent method seemed like the first logical step forward. Please advise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 23 15:32:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Nov 2010 15:32:40 -0000 Subject: [Varnish] #814: yum installation error "[Errno -1] Header is not complete." In-Reply-To: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> References: <051.f4fd7269efa6701ed626e5414d9794c5@varnish-cache.org> Message-ID: <060.931c5e4a7369aa6f358f6bc2107e529d@varnish-cache.org> #814: yum installation error "[Errno -1] Header is not complete." -----------------------------+---------------------------------------------- Reporter: patrick.kaiser | Type: defect Status: reopened | Priority: normal Milestone: | Component: packaging Version: trunk | Severity: normal Resolution: | Keywords: -----------------------------+---------------------------------------------- Changes (by patrick.kaiser): * status: closed => reopened * resolution: fixed => Comment: Thanks for looking at this. Unfortunatly I still get the same error on my RHEL5 Box: # rpm --nosignature -i http://repo.varnish-cache.org/redhat/el5/noarch /varnish-release-2.1-2.noarch.rpm # yum install varnish ... ---> Downloading header for varnish to pack into transaction set. varnish-2.1.4-2.el5.x86_6 100% |=========================| 18 kB 00:00 http://repo.varnish- cache.org/redhat/varnish-2.1/el5/x86_64/varnish-2.1.4-2.el5.x86_64.rpm: [Errno -1] Header is not complete. Trying other mirror. Error: failure: varnish-2.1.4-2.el5.x86_64.rpm from varnish-2.1: [Errno 256] No more mirrors to try. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 25 10:29:11 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 25 Nov 2010 10:29:11 -0000 Subject: [Varnish] #820: add direct purging (not ban) to admin interface Message-ID: <045.b33f18a713ebcd90c362be922c3d375c@varnish-cache.org> #820: add direct purging (not ban) to admin interface ----------------------+----------------------------------------------------- Reporter: grosser2 | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- atm we have to use curl to purge varnish, it would be simpler if we could purge with varnishadmin via full hash e.g. varnishadmin purge.direct foo.bla#/x/y/z no regex support, just simple == matching, fetch the object and set ttl exactly as one would do inside vcl (ban based purging is not an option for us since we have to many objects/purges for this) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 26 11:49:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Nov 2010 11:49:43 -0000 Subject: [Varnish] #820: add direct purging (not ban) to admin interface In-Reply-To: <045.b33f18a713ebcd90c362be922c3d375c@varnish-cache.org> References: <045.b33f18a713ebcd90c362be922c3d375c@varnish-cache.org> Message-ID: <054.c58be960c3eac289a693ca5a0a381111@varnish-cache.org> #820: add direct purging (not ban) to admin interface -----------------------+---------------------------------------------------- Reporter: grosser2 | Type: enhancement Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: wontfix | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: Yes, it would be neat, but it is not happening any time soon. To do so would require us to replicate a lot of code from the main traffic path into the CLI path and that will never be offset by the minor convenience you would gain. Sorry... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 26 11:52:38 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Nov 2010 11:52:38 -0000 Subject: [Varnish] #819: Persistent storage method, does not persist a service restart In-Reply-To: <048.1e885abafc72a0de36505c91a4c77df2@varnish-cache.org> References: <048.1e885abafc72a0de36505c91a4c77df2@varnish-cache.org> Message-ID: <057.e2403463b0edaedcb75b252bac793b0f@varnish-cache.org> #819: Persistent storage method, does not persist a service restart ------------------------------------+--------------------------------------- Reporter: David Busby | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: persistent persistence | ------------------------------------+--------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: if -spersistent is taken down before it has a chance to close the currently open segment properly, all objects therin will be lost on restart. Segments gets closed when they are full and when the CLI stop command is issued. You don't say how you restart varnishd, but if you use the CLI to give it stop and start commands, your objects should survive. If you kill the process, it won't be able to close the segment. The p*.vtc testcases indicates this works as expected. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 26 11:53:37 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Nov 2010 11:53:37 -0000 Subject: [Varnish] #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled In-Reply-To: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> References: <040.0c8b0efd0753ff3b594911dd085b2661@varnish-cache.org> Message-ID: <049.f54d897f061640993f46d45537e14c5c@varnish-cache.org> #818: Incorrectly handling 304 responses from an HTTP/1.1 backend with keepalive enabled ---------------------+------------------------------------------------------ Reporter: lew | 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: No worries... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 26 12:23:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Nov 2010 12:23:35 -0000 Subject: [Varnish] #820: add direct purging (not ban) to admin interface In-Reply-To: <045.b33f18a713ebcd90c362be922c3d375c@varnish-cache.org> References: <045.b33f18a713ebcd90c362be922c3d375c@varnish-cache.org> Message-ID: <054.da7d2af02bf5f7c1732ad4f16c1899d3@varnish-cache.org> #820: add direct purging (not ban) to admin interface -----------------------+---------------------------------------------------- Reporter: grosser2 | Type: enhancement Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: wontfix | Keywords: -----------------------+---------------------------------------------------- Comment(by grosser2): It seemed simple to me, but i dont have any ideas of varnish internals... My idea in pseudocode, just in case you were thinking about something more complex: object = ObjectStore.fetch(hash); object.ttl = 0; ObjectStore.store(object) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 11:33:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 11:33:02 -0000 Subject: [Varnish] #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse In-Reply-To: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> References: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> Message-ID: <054.1f950f49dd7bdbf9331c2e8778bcffc0@varnish-cache.org> #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse ----------------------+----------------------------------------------------- Reporter: askalski | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5599]) Merge r5476: Read expected final CRLF after chunked encoding data from backend. Make "chunkedlen" test server command output final CRLF after chunked data. Update a couple of test cases to output the final CRLF. Fixes: #780 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 12:44:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 12:44:08 -0000 Subject: [Varnish] #808: Assert crash on load testing In-Reply-To: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> References: <042.8a9ae68b2628d5026dc8f8aa1e4c3372@varnish-cache.org> Message-ID: <051.867116959943635d814aca8038349767@varnish-cache.org> #808: Assert crash on load testing ----------------------+----------------------------------------------------- Reporter: diego | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5604]) Merge r5491: Reset worker thread workspace between requests If requests come in fast enough on a single connection, typically when running synthetic benchmarks, we need to reset the worker threads workspace between requests, or we will eventually run out. This is an embarrasingly old bug. Fixes: #808 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 13:00:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 13:00:42 -0000 Subject: [Varnish] #804: Invalid command line option in varnishtest.1 In-Reply-To: <047.028f94ba444956a6d18d2c68d6b4ba1b@varnish-cache.org> References: <047.028f94ba444956a6d18d2c68d6b4ba1b@varnish-cache.org> Message-ID: <056.c73e633fa0da2eb5b59812175f824cb9@varnish-cache.org> #804: Invalid command line option in varnishtest.1 -------------------------+-------------------------------------------------- Reporter: bonetruck2 | Type: documentation Status: closed | Priority: low Milestone: | Component: documentation Version: 2.1.4 | Severity: minor Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Comment(by tfheen): (In [5606]) Merge r5496: Remove documentation of no longer existant -L option. Fixes: #804 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 13:06:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 13:06:25 -0000 Subject: [Varnish] #633: varnishncsa segfaults In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org> Message-ID: <053.2197f8aa37cecbb983f3b99aeb680009@varnish-cache.org> #633: varnishncsa segfaults -------------------------+-------------------------------------------------- Reporter: victori | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: assigned => closed * resolution: => worksforme Comment: No response from submitter; closing. Please reopen if you can reproduce this problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 13:20:49 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 13:20:49 -0000 Subject: [Varnish] #772: cli_buffer parameter doesn't work. In-Reply-To: <044.12c898455bb056ae4f68271e3a5999e5@varnish-cache.org> References: <044.12c898455bb056ae4f68271e3a5999e5@varnish-cache.org> Message-ID: <053.dc6a1c3b1ad529490818da2d97ec2fcf@varnish-cache.org> #772: cli_buffer parameter doesn't work. ------------------------+--------------------------------------------------- Reporter: Estartu | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: cli_buffer | ------------------------+--------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Old description: > I'm setting my configs via vcl.inline. Works find as long as the config > and the command shorter than 8192 bytes. > > so i tried to increase cli_buffer with param.set cli_buffer 81920 > > still the input stops at 8192 characters. > > The help to cli_buffer states that cli_buffer has to be set via -p. No > change there to. I even changed the default value in mgt_param.c > > The changed value is shown via param.show but the input still stops after > 8192 characters. > > I'm running varnish-2.1.3 SVN 5049:5055 installed via the FreeBSD Port. New description: I'm setting my configs via vcl.inline. Works find as long as the config and the command shorter than 8192 bytes. so i tried to increase cli_buffer with param.set cli_buffer 81920 still the input stops at 8192 characters. The help to cli_buffer states that cli_buffer has to be set via -p. No change there to. I even changed the default value in mgt_param.c The changed value is shown via param.show but the input still stops after 8192 characters. I'm running varnish-2.1.3 SVN 5049:5055 installed via the FreeBSD Port. -- Comment: Hi, Changesets r5588 and r5589 in trunk should solve your use-case. In order to better facilitate larger data sets through the CLI a shell here- document style of syntax has been added. This will allow you to send arbitrary long VCLs through CLI, as long as no single line is longer than 8192 bytes. See the commit comment on r5588 for an example. Note also that this will only work on authenticated CLI sessions, in order to avoid a DoS vector. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 14:31:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 14:31:02 -0000 Subject: [Varnish] #795: Conditional GETs based on modification time are not honored if Last-Modified was not explicitly set In-Reply-To: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> References: <041.b0a6ed2acb0c58c87fa9ceff762a226f@varnish-cache.org> Message-ID: <050.dbedebcf710f1d5fdeb08ad081e10dd0@varnish-cache.org> #795: Conditional GETs based on modification time are not honored if Last- Modified was not explicitly set ---------------------+------------------------------------------------------ Reporter: runa | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Comment(by tfheen): (In [5613]) Merge r5505: Change how we do If-Modified-Since on objects without a Last-Modified header. Until now, we have not allowed IMS on objects without LM header but after due consideration of our role as web-server, that restriction is found too hard: Varnish will, by definition, not find and object which is not valid, so we can trust the time we put it into the cache to be the LM date. But we can not synthesize a LM header based on this, as this would allow down-stream client-side caches to make unwarranted decisions (see RFC2616 13.3.4 p88) Fixes: #795 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 14:12:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 14:12:20 -0000 Subject: [Varnish] #806: invalid Content-Length results in hang and then 503 In-Reply-To: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> References: <044.0caa0d72946532d2efbe6cabe56b5e96@varnish-cache.org> Message-ID: <053.d37b2cef0e069f317a508d09fbfb10be@varnish-cache.org> #806: invalid Content-Length results in hang and then 503 ----------------------+----------------------------------------------------- Reporter: amorton | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5611]) Merge r5503: Make pass with content-length work again We have to check the magic status before other length indications, otherwise we cannot pass a 304 with a Content-Length. (RFC2616 p33 4.4) Fixes: #806 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 18:30:48 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 18:30:48 -0000 Subject: [Varnish] #821: add netbsd to configure Message-ID: <047.c77783af70cc776a96906333927645e0@varnish-cache.org> #821: add netbsd to configure ------------------------+--------------------------------------------------- Reporter: msporleder | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: netbsd | ------------------------+--------------------------------------------------- From pkgsrc (dragonfly would probably also work but I'm not sure what the uname value is there): {{{ --- configure.ac.orig 2009-04-01 13:35:15.000000000 +0000 +++ configure.ac @@ -55,6 +55,7 @@ AM_CONDITIONAL([HAVE_CURSES], [test x$ha save_LIBS="${LIBS}" LIBS="" AC_SEARCH_LIBS(pthread_create, [thr pthread c_r]) +LIBS="${PTHREAD_LDFLAGS} ${PTHREAD_LIBS}" PTHREAD_LIBS="${LIBS}" LIBS="${save_LIBS}" AC_SUBST(PTHREAD_LIBS) @@ -195,7 +196,7 @@ AC_ARG_ENABLE(kqueue, if test "$enable_kqueue" = yes; then case $target in - *-*-freebsd* | *-*-darwin9* ) + *-*-freebsd* | *-*-darwin9* | *-*-netbsd* ) AC_CHECK_FUNCS([kqueue]) ;; *-*-bsd*) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 29 19:12:02 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Nov 2010 19:12:02 -0000 Subject: [Varnish] #822: Repository URLs are wrong on the wiki page UsingSvnSvk Message-ID: <047.5ff850794de151226124161e23165988@varnish-cache.org> #822: Repository URLs are wrong on the wiki page UsingSvnSvk ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Type: documentation Status: new | Priority: low Milestone: | Component: website Version: trunk | Severity: minor Keywords: | ------------------------+--------------------------------------------------- The directions for checking out a copy of the source are wrong on two points: 1. ssh fails because of a key issue 2. the path is wrong Ultimately I found this to work: svn co http://varnish-cache.org/svn/trunk varnish Notice that it's using http and the path does not include "varnish". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 30 05:37:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Nov 2010 05:37:52 -0000 Subject: [Varnish] #823: Ability to determine number of healthy backends from varnishstat Message-ID: <042.95f938109ab74caae44fa84d51715c76@varnish-cache.org> #823: Ability to determine number of healthy backends from varnishstat -------------------------+-------------------------------------------------- Reporter: glenk | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Varnish 2.1 release Component: varnishstat | Version: trunk Severity: normal | Keywords: varnishstat healthy backends -------------------------+-------------------------------------------------- The ability from varnishstat to retrieve the number of healthy backends. This would be very similar to `varnishstat -1 -f n_backend? but instead of returning the number of configured backends it would return the number of healthy backends. The justification for this change is that it easily allows the monitoring of the number of healthy backends without having to run the varnish console which could constitute a security risk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 30 06:16:15 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Nov 2010 06:16:15 -0000 Subject: [Varnish] #789: v2.1.3 w/ http_range_support on strips Content-Range on pass In-Reply-To: <049.fed33db428dab02e8bee5fad46a1664b@varnish-cache.org> References: <049.fed33db428dab02e8bee5fad46a1664b@varnish-cache.org> Message-ID: <058.1c9ee18a095d4d8fe5188db932dc1313@varnish-cache.org> #789: v2.1.3 w/ http_range_support on strips Content-Range on pass ---------------------------+------------------------------------------------ Reporter: jim.robinson | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Resolution: fixed | Keywords: http_range_support byte range content-range stripped ---------------------------+------------------------------------------------ Comment(by tfheen): (In [5616]) Merge r5506: Do not filter out Content-Range headers in pass. Fixes: #789 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 30 07:36:10 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Nov 2010 07:36:10 -0000 Subject: [Varnish] #686: VCL doesn't account for duplicate headers with different content In-Reply-To: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> References: <042.f8a05be67072e6502bf73a7c4efd9ac6@varnish-cache.org> Message-ID: <051.acea1f6c59916277d2f2ed82b79d8fa8@varnish-cache.org> #686: VCL doesn't account for duplicate headers with different content -------------------------+-------------------------------------------------- Reporter: felix | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: vcl headers | -------------------------+-------------------------------------------------- Comment(by tfheen): (In [5626]) Merge r5531: Merge multi-line Cache-Control and Vary header fields One of the silly overgeneralizations in RFC2616, is that headers which contain comma-separated lists, can be spread over multiple header lines. There is no way of knowing if this rule applies to any header not in RFC2616, short of chasing down the relevant standards document, if any, for the particular header. Considering the fact that HTTP header lines have no natural limitation on length AND that RFC2616 already specifies a mechanism for header-continuation, this doesn't add any value, at all. It is hardly a surprise that nobody used this either, so until now, we have ignored this silly stuff and just used the first header we found. But now Chromium, of all things, seems to find it necessary to spread its Cache-Control across two lines, and we get to deal with this crap. Add a function for stitching multiple header lines into one, and call it on Cache-Control in requests to deal with Chromiums issues. Since we have it, call it preemptively on Cache-Control and Vary in backend responses, since the C-code examines these fields. XXX: At some point, add VCL support for collecting specific headers this way. Fixes: #686 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 30 07:43:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Nov 2010 07:43:52 -0000 Subject: [Varnish] #812: crash in HSH_Purge In-Reply-To: <040.1fdd26336fe4b2d2232e12531e6c12eb@varnish-cache.org> References: <040.1fdd26336fe4b2d2232e12531e6c12eb@varnish-cache.org> Message-ID: <049.ae853b4cd72196f74b1d999219bbedb3@varnish-cache.org> #812: crash in HSH_Purge ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5627]) Merge r5532: Make new-purge not touch busy objects "new-purge" cannot and should not touch busy objects, as they are not subject to refcounting. Fixes: #812 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 30 08:27:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Nov 2010 08:27:00 -0000 Subject: [Varnish] #817: 'varnishadm -T :6082' causes segfault In-Reply-To: <058.bf8ac99c99ed6a34bdf92a3c80d90e8d@varnish-cache.org> References: <058.bf8ac99c99ed6a34bdf92a3c80d90e8d@varnish-cache.org> Message-ID: <067.147fdb0a4146b29a87041784829759d1@varnish-cache.org> #817: 'varnishadm -T :6082' causes segfault -----------------------------------+---------------------------------------- Reporter: Martin Blix Grydeland | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Comment(by tfheen): (In [5631]) Merge r5580: Remove call to VSS_parse() in VSS_open() Remove call to VSS_parse() in VSS_open(), as VSS_parse() is called in VSS_resolve() anyway. Fixes: #817 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 30 16:02:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Nov 2010 16:02:28 -0000 Subject: [Varnish] #824: Saintmode: repeated failure causes varnish to go into 503 mode Message-ID: <045.8fa19d1123839c8ac2f07e73e3e9f542@varnish-cache.org> #824: Saintmode: repeated failure causes varnish to go into 503 mode ----------------------+----------------------------------------------------- Reporter: grosser2 | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- When setting saintmmode in vcl_error, repeated requests (5+/s) to pages that return errors(500) caused varnish to go into 503 mode, backend was still reported as healthy, but all misses(not only to the page that failed with 500) are 503 and are 'connection not attempted' in varnishstat. Hits were still ok. {{{ if (beresp.status >= 500 && beresp.status < 600) { set beresp.saintmode = 30m; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator