From varnish-bugs at projects.linpro.no Wed Oct 1 17:18:10 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:18:10 -0000 Subject: [Varnish] #290: Make dir in /usr/local/var/varnish In-Reply-To: <054.a171d91cbb7594e23ea750517981ab8a@projects.linpro.no> References: <054.a171d91cbb7594e23ea750517981ab8a@projects.linpro.no> Message-ID: <063.a252cf22b76e135c43f7c37fea3be500@projects.linpro.no> #290: Make dir in /usr/local/var/varnish ----------------------+----------------------------------------------------- Reporter: The_ZoRo | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => invalid Comment: No response from submitter; it looks like you just forgot to run make install, which is necessary for proper operation if you don't pass -n to varnishd. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:21:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:21:53 -0000 Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed In-Reply-To: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> References: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> Message-ID: <060.4f437eeb79abb232c0f3944449b9ea6c@projects.linpro.no> #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed ----------------------+----------------------------------------------------- Reporter: peter | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest * milestone: => Later Comment: Doing so would require two passes through the esi-tree and challenge workspace allocation and other things. For now this is an errata thing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:22:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:22:34 -0000 Subject: [Varnish] #8: VCL completeness In-Reply-To: <049.8948111148324535217a4c9812a5f0d0@projects.linpro.no> References: <049.8948111148324535217a4c9812a5f0d0@projects.linpro.no> Message-ID: <058.da5a55b5c612b1e0b99518fb7784730b@projects.linpro.no> #8: VCL completeness ----------------------+----------------------------------------------------- Reporter: des | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Close this, it's tracked in the wiki now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:23:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:23:33 -0000 Subject: [Varnish] #216: String concatenation in functions In-Reply-To: <051.d8162fcb19c67b07da17c0349a8c725c@projects.linpro.no> References: <051.d8162fcb19c67b07da17c0349a8c725c@projects.linpro.no> Message-ID: <060.4acfcded941cb0aec97b7d5da80648d7@projects.linpro.no> #216: String concatenation in functions ----------------------+----------------------------------------------------- Reporter: teddy | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: move to wiki -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:26:18 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:26:18 -0000 Subject: [Varnish] #224: Improved logging In-Reply-To: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no> References: <049.b840548eba4d9d14102064bf6f789678@projects.linpro.no> Message-ID: <058.5f10273c6546d03b9c4fc290334dcfaf@projects.linpro.no> #224: Improved logging -------------------------+-------------------------------------------------- Reporter: des | Owner: des Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: moved to wiki -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:27:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:27:50 -0000 Subject: [Varnish] #246: Make req available in vcl_deliver In-Reply-To: <058.53d2945701dca8896a94831a3f392163@projects.linpro.no> References: <058.53d2945701dca8896a94831a3f392163@projects.linpro.no> Message-ID: <067.e0c1317f14c1d946b90d1010b1cc45b8@projects.linpro.no> #246: Make req available in vcl_deliver --------------------------+------------------------------------------------- Reporter: alex.taggart | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------------+------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: moved to wiki -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:30:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:30:39 -0000 Subject: [Varnish] #222: On Solaris, request is not sent to the backend and varnish reports 503 In-Reply-To: <050.ca6dba8e263646410802591b85306447@projects.linpro.no> References: <050.ca6dba8e263646410802591b85306447@projects.linpro.no> Message-ID: <059.5d01a24287fc581792d1b9aa3f5307b6@projects.linpro.no> #222: On Solaris, request is not sent to the backend and varnish reports 503 --------------------+------------------------------------------------------- Reporter: jyri | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: major | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => fixed Comment: long since fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:31:40 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:31:40 -0000 Subject: [Varnish] #220: varnishtop segfaults In-Reply-To: <049.46ec2aa69c7071bdb978c4c5876a4d4c@projects.linpro.no> References: <049.46ec2aa69c7071bdb978c4c5876a4d4c@projects.linpro.no> Message-ID: <058.e3e9237877d66f5f430885cbff7e96f0@projects.linpro.no> #220: varnishtop segfaults ------------------------+--------------------------------------------------- Reporter: akv | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: We increased the SHM to 80MB, assume fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:32:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:32:41 -0000 Subject: [Varnish] #210: The binary heap implementation does not scale In-Reply-To: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> References: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> Message-ID: <058.40e20f97811d69ecedaa1692f0a00d69@projects.linpro.no> #210: The binary heap implementation does not scale -------------------------+-------------------------------------------------- Reporter: phk | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * priority: normal => lowest * milestone: => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:33:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:33:53 -0000 Subject: [Varnish] #206: Improved VCL primitives for header manipulation In-Reply-To: <049.a382d66fd206944c4a15b1cc891e9d9a@projects.linpro.no> References: <049.a382d66fd206944c4a15b1cc891e9d9a@projects.linpro.no> Message-ID: <058.89580e34d983cc31cf5d8524039f80fa@projects.linpro.no> #206: Improved VCL primitives for header manipulation -------------------------+-------------------------------------------------- Reporter: des | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: moved to wiki -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:34:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:34:47 -0000 Subject: [Varnish] #184: After a url purge the page takes about 20 sek or time out before it is viewed. In-Reply-To: <058.88bcec527e068e486073fafb55a2d4d2@projects.linpro.no> References: <058.88bcec527e068e486073fafb55a2d4d2@projects.linpro.no> Message-ID: <067.0e66ca6bb5246b84ca68740a700df232@projects.linpro.no> #184: After a url purge the page takes about 20 sek or time out before it is viewed. --------------------------+------------------------------------------------- Reporter: krkomvarnish | Owner: des Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 1.1.1 Severity: major | Resolution: worksforme Keywords: Purge | --------------------------+------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: time out ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:37:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:37:08 -0000 Subject: [Varnish] #15: per-client log tailer In-Reply-To: <049.500045ec0822e4291d95e2427e2134f7@projects.linpro.no> References: <049.500045ec0822e4291d95e2427e2134f7@projects.linpro.no> Message-ID: <058.dbfda0f9795dc90126ffbab3c31ec422@projects.linpro.no> #15: per-client log tailer -------------------------+-------------------------------------------------- Reporter: des | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: change requests tracked in wiki now -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 1 17:37:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Oct 2008 17:37:57 -0000 Subject: [Varnish] #13: RFC compliance audit In-Reply-To: <049.e66c7bb40506de4c05d5f2a155d46d85@projects.linpro.no> References: <049.e66c7bb40506de4c05d5f2a155d46d85@projects.linpro.no> Message-ID: <058.f2ee28cd2854c5a23fbd331489fcdb35@projects.linpro.no> #13: RFC compliance audit ----------------------+----------------------------------------------------- Reporter: des | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Overtaken by events. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 2 12:44:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 02 Oct 2008 12:44:07 -0000 Subject: [Varnish] #190: VCL Sample In-Reply-To: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no> References: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no> Message-ID: <066.00b532428ffd3e9be45929d5ea3a7321@projects.linpro.no> #190: VCL Sample ---------------------------+------------------------------------------------ Reporter: michael.lee | Owner: tfheen Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 1.1.1 Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: http://varnish.projects.linpro.no/wiki/VCLExampleCacheCookies and the man page are now updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 3 07:18:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 03 Oct 2008 07:18:55 -0000 Subject: [Varnish] #343: Varnish crashes frequently with restart in vcl_fetch Message-ID: <050.2e50ed37b95b065838f8bf3e8675abf9@projects.linpro.no> #343: Varnish crashes frequently with restart in vcl_fetch ----------------------+----------------------------------------------------- Reporter: noah | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- This piece of code seems to be cause frequent crashes in both Varnish 2.0 beta 2 and -trunk from May 6th. Removing it fixes the problem. sub vcl_fetch { # Restart failed requests (i.e: 5xx) if (obj.status != 200 && obj.status != 301 && obj.status != 302 && obj.status != 403 && obj.status != 404) { restart; } } Unfortunately I don't have time to provide a backtrace at this moment. I'm running on Linux 64-bit (Ubuntu Hardy) with a single Apache backend. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 3 10:46:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 03 Oct 2008 10:46:49 -0000 Subject: [Varnish] #343: Varnish crashes frequently with restart in vcl_fetch In-Reply-To: <050.2e50ed37b95b065838f8bf3e8675abf9@projects.linpro.no> References: <050.2e50ed37b95b065838f8bf3e8675abf9@projects.linpro.no> Message-ID: <059.858250d16d0975dd490c01c884a6aa03@projects.linpro.no> #343: Varnish crashes frequently with restart in vcl_fetch ----------------------+----------------------------------------------------- Reporter: noah | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): Does the patch in http://git.err.no/cgi- bin/gitweb.cgi?p=varnish;a=commitdiff;h=4cf6d244b3af3c09acd4bbc7df295124ec484b19#patch1 fix this for you? It'll make restarts go to vcl_error after reaching max_restarts. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 3 12:12:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 03 Oct 2008 12:12:48 -0000 Subject: [Varnish] #186: No logging data on quick aborts with varnishlog or varnishncsa In-Reply-To: <052.35a6a62e76ff9bcab197bf597959229a@projects.linpro.no> References: <052.35a6a62e76ff9bcab197bf597959229a@projects.linpro.no> Message-ID: <061.b0f75c09fbfb7daa2570affe39ad0e24@projects.linpro.no> #186: No logging data on quick aborts with varnishlog or varnishncsa -------------------------+-------------------------------------------------- Reporter: rinogo | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 1.1.1 Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => worksforme Comment: I can't reproduce this problem here, neither on fast, nor slow links. If you are able to reproduce the problem with trunk, please reopen the bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 3 20:47:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 03 Oct 2008 20:47:04 -0000 Subject: [Varnish] #344: varnish won't build on ppc/ppc64 using jemalloc Message-ID: <052.af7ccd95f6e79e73c54f11a039e753d3@projects.linpro.no> #344: varnish won't build on ppc/ppc64 using jemalloc --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- As reported on IRC, there is something, uhm, strange going on when building varnish on the ppc64 boxes in koji, the build farm environment for Fedora. i386 and x86_64 builds work without problems. ppc and ppc64 builds fails unless deactivating jemalloc. Then I dug out my old RS6000 B50, and put it on net in the attic, and installed "mock" on it. Mock is the same build environment as koji uses, or at least, that's what is't supposed to be. On the B50, varnish compiles with jemalloc in mock for fedora rawhide (soon-to-become fedora 10) without problems at all. (I could not test ppc64 as as that old box is only 32bit ppc.) Now, I whined a bit about this at #fedora-ppc, and got this, uhm, insightful answer from David Woodhouse, one of the glibc upstream maintainers: "It's possible that in koji we use 64KiB pages, rather than 4KiB. Is this the package with the 'special' allocator? Make it use getpagesize() instead of hard-coding the page size to some number it pulls out of its arse." Is it possible to do this? Earlier, Woodhouse has asked why we can't use the stock glibc malloc, and rather file a bug against glibc explaining what problems their malloc has. I would suggest to do this anyhow. A normal bug on Fedora in http://bugzilla.redhat.com/ would do, as the Fedora maintainers are also upstream maintainers. The worst thing that could happen would be that the reporter got flamed. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Oct 5 12:00:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 05 Oct 2008 12:00:21 -0000 Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed In-Reply-To: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> References: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> Message-ID: <060.68b16841bebf84f00084aff36d1a4873@projects.linpro.no> #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed ----------------------+----------------------------------------------------- Reporter: peter | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by eugaia): In my opinion, VCL should allow for telling the client how to cache objects in a way that can be set independently of Varnish's cache. This could be done in at least three ways I can think of (off the top of my head, quickly): 1) Last modified time (as sky suggests, this should logically be set to the youngest cached object) 2) Cached on the client for TTL (as phk says, this should logically be set to the shortest TTL of any cached objects) 3) A different 'external' TTL (this could be set independently to any of the objects that are part of the page and independently of Varnish's cache of the page - the obj.ttl value). I would expect (3) to be used only in a few number of cases if the other two are properly implemented, but there may be some specific cases where someone might wish to set an external cache time greater than the minimum objects TTL's time as a design decision. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 6 13:25:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 06 Oct 2008 13:25:41 -0000 Subject: [Varnish] #210: The binary heap implementation does not scale In-Reply-To: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> References: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> Message-ID: <058.61705acb9bc3a6cc603d6ea186eaa53b@projects.linpro.no> #210: The binary heap implementation does not scale -------------------------+-------------------------------------------------- Reporter: phk | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by eugaia): I've not tried this yet, but would having multiple instances of Varnish on the same server, with a URL-based hash load-balancer between them largely solve the problem until the issue is fixed? Obviously there would be the overhead of the extra load-balancer in front of the Varnish instances, but it may be more than compensated for by the gain with large object sets. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 6 17:18:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 06 Oct 2008 17:18:44 -0000 Subject: [Varnish] #344: varnish won't build on ppc/ppc64 using jemalloc In-Reply-To: <052.af7ccd95f6e79e73c54f11a039e753d3@projects.linpro.no> References: <052.af7ccd95f6e79e73c54f11a039e753d3@projects.linpro.no> Message-ID: <061.7ded0defa11fc2db3653aaafc10ef632@projects.linpro.no> #344: varnish won't build on ppc/ppc64 using jemalloc --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): Tested with 64k pagesize. Output from varnishd -C changed from a lot of trash to "#d" (and nothing more), but that's still broken, of course. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 7 09:46:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Oct 2008 09:46:24 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.66867382a58543c97e880e89225f765d@projects.linpro.no> #330: 2.0-beta1 dies with accept error ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: low | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3261]) Sleep for a bit if accept(2) returns EMFILE Hopefully, this will mitigate pile-ups somewhat and prevent us from running out of file descriptors, at least as quickly. See #330. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 7 10:57:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Oct 2008 10:57:37 -0000 Subject: [Varnish] #339: Repeated Assert error in cnt_recv() In-Reply-To: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> References: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> Message-ID: <062.5e3e24b869578bd90d326a95f2df4a28@projects.linpro.no> #339: Repeated Assert error in cnt_recv() ----------------------+----------------------------------------------------- Reporter: kierank | 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 [3262]) Make sure ESI includes don't trip the director NULL check in vcl_recv. Fixes #339 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 7 11:08:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Oct 2008 11:08:46 -0000 Subject: [Varnish] #280: Workspace overflows give confusing error messaqe In-Reply-To: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> References: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> Message-ID: <062.a4817adb2f5def9631e18c3982b71a6d@projects.linpro.no> #280: Workspace overflows give confusing error messaqe ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): (In [3265]) Error out when reaching max_restarts Partially addresses #280 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 7 11:21:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Oct 2008 11:21:57 -0000 Subject: [Varnish] #342: error keyword in vcl_fetch fails In-Reply-To: <051.ca1f0eab87cc4f2beac5b0a8a72a7644@projects.linpro.no> References: <051.ca1f0eab87cc4f2beac5b0a8a72a7644@projects.linpro.no> Message-ID: <060.4fbe3e49cc70b0dbcf858c6af4eebc88@projects.linpro.no> #342: error keyword in vcl_fetch fails -----------------------------+---------------------------------------------- Reporter: wiebe | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: error vcl_fetch | -----------------------------+---------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r3263. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 7 14:40:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Oct 2008 14:40:14 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() Message-ID: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- Again, when using OpenWebLoad errors seem to be very frequent. http://openwebload.sourceforge.net/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 7 14:42:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Oct 2008 14:42:20 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.75b1ad53f3d8cc46e09e76887bd6070f@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): Also only happens with ESI pages. However, non ESI pages do not crash but requests per second when using OpenWebLoad are very low. (e.g. under 10 requests per second) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 8 07:39:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Oct 2008 07:39:24 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.c5c32f2aecf435fb96db22f029b01850@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Is it possible to catch the offending transaction in varnishlog ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 8 07:49:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Oct 2008 07:49:04 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.57557f20d0132196a15817435cda7335@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Just a comment on your VCL: {{{ 39 lookup; 40 # The default vcl_recv is used from here. 41 } 42 }}} That comment is wrong, when you issue "lookup", that is a terminating action of vcl_recv and no further code will be executed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 8 14:16:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Oct 2008 14:16:36 -0000 Subject: [Varnish] #346: rc1 has a timing issue in make check Message-ID: <052.c736794dc2a98c51ac53bc0de9c374bc@projects.linpro.no> #346: rc1 has a timing issue in make check --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Keywords: --------------------+------------------------------------------------------- Most of the times I build rc1 on my fedora9/i386 box, it fails. Sometimes, it succeeds. A build log with varnishtest -d available at http://init.linpro.no/ingvar/varnish/rc1/rc1.build.log.f9.i386 and attached to this ticket. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 8 14:46:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Oct 2008 14:46:15 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.fbd65c83ddaddcd99fca97525d350a2f@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): Ok, It looks like that comment should have been removed ages ago anyway... As for the varnishlog I assume the child restarts here: {{{ 0 CLI - Rd vcl.load boot ./vcl.1P9zoqAU.so }}} (not really sure what to interpret from it though... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 8 14:58:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Oct 2008 14:58:04 -0000 Subject: [Varnish] #346: rc1 has a timing issue in make check In-Reply-To: <052.c736794dc2a98c51ac53bc0de9c374bc@projects.linpro.no> References: <052.c736794dc2a98c51ac53bc0de9c374bc@projects.linpro.no> Message-ID: <061.5f88a3ab0c29e9e36a532766b114450c@projects.linpro.no> #346: rc1 has a timing issue in make check --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: you know, one could have cut out just the relevant testcase from that logfile... :-) My earlier comments about automatic runs of varnishtest still applies. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 8 20:51:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Oct 2008 20:51:08 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.fac26f8f83fe2457533603e2a006c2ab@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): It seems like a new workerthread is created, which promptly starts scheduling an already handled sessions (hence the DONE state). I'll try to stare at the source to see if I can spot how that can happen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 9 11:08:11 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 09 Oct 2008 11:08:11 -0000 Subject: [Varnish] #346: rc1 has a timing issue in make check In-Reply-To: <052.c736794dc2a98c51ac53bc0de9c374bc@projects.linpro.no> References: <052.c736794dc2a98c51ac53bc0de9c374bc@projects.linpro.no> Message-ID: <061.b3d1168e51e79965190404f31e0d4878@projects.linpro.no> #346: rc1 has a timing issue in make check --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): This particular bug seems fixed in r3269 in trunk. I'm hitting a similar bug from time to time though, but now it's more seldom. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 9 11:15:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 09 Oct 2008 11:15:55 -0000 Subject: [Varnish] #347: 2.0-rc1, make check: b00019.vtc fails on rhel4/i386 Message-ID: <052.993d1e7cb8e42680f847e99e4934a7cc@projects.linpro.no> #347: 2.0-rc1, make check: b00019.vtc fails on rhel4/i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Keywords: --------------------+------------------------------------------------------- make check fails from time to time on rhel4/i386. Similar to #346. This time it's b00019.vtc that fails. See http://init.linpro.no/ingvar/varnish/rc1/el4/build.err.el4.i386. Also attached to this bug. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 9 11:19:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 09 Oct 2008 11:19:46 -0000 Subject: [Varnish] #348: Two extra parameters to control whether to include Via:varnish and X-Varnish header items Message-ID: <052.f74396f9c11e682f0fbf726a2036fe9e@projects.linpro.no> #348: Two extra parameters to control whether to include Via:varnish and X-Varnish header items -------------------------+-------------------------------------------------- Reporter: 191919 | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- This patch adds two extra parameters to control whether to include Via:varnish and X-Varnish header items. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 9 22:02:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 09 Oct 2008 22:02:25 -0000 Subject: [Varnish] #349: varnishtest b00019.vtc fails sometimes on fedora9/i386 Message-ID: <052.604d0cdc02e8f5ef86b580cd84ae1cd8@projects.linpro.no> #349: varnishtest b00019.vtc fails sometimes on fedora9/i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Keywords: --------------------+------------------------------------------------------- Built varnish in a while-true loop. The build failed at make check on the 39th try, in tests/b00019.vtc Error log at http://init.linpro.no/ingvar/varnish/fedora- debug/build.err.varnish-2.0.11.rc1.fc9.i386.b00019.vtc and attached to this bug. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 9 22:09:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 09 Oct 2008 22:09:49 -0000 Subject: [Varnish] #349: varnishtest b00019.vtc fails sometimes on fedora9/i386 In-Reply-To: <052.604d0cdc02e8f5ef86b580cd84ae1cd8@projects.linpro.no> References: <052.604d0cdc02e8f5ef86b580cd84ae1cd8@projects.linpro.no> Message-ID: <061.9fb2923a2cf304ee61abe44ad191c4a8@projects.linpro.no> #349: varnishtest b00019.vtc fails sometimes on fedora9/i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): This was with rc1 + varnishtest from trunk of today, r3273. Looks like a duplicate of #347 to me. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 10 11:02:09 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 10 Oct 2008 11:02:09 -0000 Subject: [Varnish] #350: Get pagesize from getpagesize() instead of hardcoding it Message-ID: <052.bdb100a7e21a62e5ee007fcf0dd452a5@projects.linpro.no> #350: Get pagesize from getpagesize() instead of hardcoding it --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- ssia, actually. Different Linux implementations use different pagesize. For example, RHEL5 on ppc64 uses a pagesize of 64k, while on i386, it uses 4k. This should be set at runtime. Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 10 15:21:32 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 10 Oct 2008 15:21:32 -0000 Subject: [Varnish] #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used In-Reply-To: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> References: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> Message-ID: <070.aae97df110de96a8784a238df1a50399@projects.linpro.no> #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used -----------------------------+---------------------------------------------- Reporter: anders at fupp.net | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 1.0 Severity: normal | Resolution: Keywords: | -----------------------------+---------------------------------------------- Changes (by anders): * status: closed => reopened * resolution: fixed => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 10 15:25:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 10 Oct 2008 15:25:07 -0000 Subject: [Varnish] #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used In-Reply-To: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> References: <061.520150cb6e2cd14d384b19671cf259ef@projects.linpro.no> Message-ID: <070.8e73996451b76c8e6e882f98184aa0da@projects.linpro.no> #97: Varnishd fails to start in FreeBSD if IPv6 support is missing in kernel and -T localhost: is used -----------------------------+---------------------------------------------- Reporter: anders at fupp.net | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 1.0 Severity: normal | Resolution: Keywords: | -----------------------------+---------------------------------------------- Comment (by anders): It seems that Varnish again has this bug. I removed IPv6 support from my kernel, I use -T localhost:8080 and have this in /etc/hosts: {{{ ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain }}} If I try to start Varnish, it crashes: {{{ Starting varnishd. Classic hash: 500009 buckets Using old SHMFILE socket(): Protocol not supported Assert error in mgt_cli_telnet(), mgt_cli.c line 478: Condition(sock >= 0) not true. errno = 43 (Protocol not supported) Abort trap (core dumped) }}} . Backtrace: {{{ (gdb) bt #0 0x0000000800da9dec in kill () from /lib/libc.so.7 #1 0x0000000800da8c5b in abort () from /lib/libc.so.7 #2 0x00000008006784cc in lbv_assert_default ( func=0x6e1
, file=0x6
, line=0, cond=0x800da9e0c "r\001?H\213\r\n\230\022", err=43, xxx=-7192) at assert.c:61 #3 0x000000000042b53c in mgt_cli_telnet (dflag=Variable "dflag" is not available. ) at mgt_cli.c:478 #4 0x000000000042ab87 in mgt_run (dflag=2, T_arg=0x7fffffffedad "localhost:8080") at mgt_child.c:518 #5 0x0000000000435c9a in main (argc=37, argv=0x7fffffffe9e0) at varnishd.c:630 (gdb) frame 3 #3 0x000000000042b53c in mgt_cli_telnet (dflag=Variable "dflag" is not available. ) at mgt_cli.c:478 478 assert(sock >= 0); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 10 15:36:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 10 Oct 2008 15:36:47 -0000 Subject: [Varnish] #351: v00017.vtc, v00018.vtc and v00019.vtc fails on ppc64 Message-ID: <052.7fe3ddde6383eb256ea1dc9d51dfe8dc@projects.linpro.no> #351: v00017.vtc, v00018.vtc and v00019.vtc fails on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Source: varnish-2.0-rc1 with bin/varnishtest as in r3273. Build environment: fedora8 ppc64 kernel, mock build fedora10 mock target: tests v00017.vtc and v00018.vtc fails http://init.linpro.no/ingvar/varnish/rc1/build.log.varnish-2.0-0.11.rc1.fc10.mock_f8.ppc64 fedora10 mock target with disable-jemalloc: tests v00017.vtc and v00018.vtc fails http://init.linpro.no/ingvar/varnish/rc1/build.log.varnish-2.0-0.11.rc1.fc10.mock_f8.ppc64 .disable-jemalloc fedora8 mock target with disable-jemalloc: tests v00017.vtc, v00018.vtc and v00019.vtc fails http://init.linpro.no/ingvar/varnish/rc1/build.log.varnish-2.0-0.11.rc1.fc8.ppc64 .disable-jemalloc Didn't bother to attach the build logs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 11 10:25:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 11 Oct 2008 10:25:16 -0000 Subject: [Varnish] #347: b00019.vtc fails sometimes. In-Reply-To: <052.993d1e7cb8e42680f847e99e4934a7cc@projects.linpro.no> References: <052.993d1e7cb8e42680f847e99e4934a7cc@projects.linpro.no> Message-ID: <061.9cddf735d58d9e4baf5d20759963f233@projects.linpro.no> #347: b00019.vtc fails sometimes. -------------------------+-------------------------------------------------- Reporter: ingvar | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 2.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishtest * summary: 2.0-rc1, make check: b00019.vtc fails on rhel4/i386 => b00019.vtc fails sometimes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 11 10:25:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 11 Oct 2008 10:25:44 -0000 Subject: [Varnish] #349: varnishtest b00019.vtc fails sometimes on fedora9/i386 In-Reply-To: <052.604d0cdc02e8f5ef86b580cd84ae1cd8@projects.linpro.no> References: <052.604d0cdc02e8f5ef86b580cd84ae1cd8@projects.linpro.no> Message-ID: <061.d1e86f22065397c99eec13351c7a54b3@projects.linpro.no> #349: varnishtest b00019.vtc fails sometimes on fedora9/i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: duplicate Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: duplicate of #347 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 11 11:43:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 11 Oct 2008 11:43:41 -0000 Subject: [Varnish] #352: ESI can't process gzipped documents Message-ID: <052.153fb00196d161c5a9c055dd5fefd446@projects.linpro.no> #352: ESI can't process gzipped documents ----------------------+----------------------------------------------------- Reporter: toledo | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Keywords: esi gzip ----------------------+----------------------------------------------------- When processing an HTML page that had been gzip compressed by the originating server varnish complains with: No ESI processing, binary object: 0x1f at pos 0 I've verified by turning setting esi_syntax to 1 that it's trying to parse a gzipped document 10 Debug c "Parse: 8890 <%1f%8b%08>" A workaround is to disable gzip compression, but that is obviously suboptimal. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 11 11:54:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 11 Oct 2008 11:54:33 -0000 Subject: [Varnish] #352: ESI can't process gzipped documents In-Reply-To: <052.153fb00196d161c5a9c055dd5fefd446@projects.linpro.no> References: <052.153fb00196d161c5a9c055dd5fefd446@projects.linpro.no> Message-ID: <061.19efc105a324a775b7602f3176f419de@projects.linpro.no> #352: ESI can't process gzipped documents ----------------------+----------------------------------------------------- Reporter: toledo | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: esi gzip | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: I will move this one to the "post 2.0" wikipage, it is not a bug under the current specification for varnish. If at some point we implement support for this, I don't see it as a "101" level feature. Getting all the bits and pieces of an ESI page compressed so that they can be concatenated as a compressed object is not a trivial undertaking, and not getting it right means that you spend a lot of cpu time compressing objects that only one client will see. In particular I have a hard time seeing the benefit from compressing the page on the backend, uncompressing it on varnish, doing ESI, and then compressing the result for the client. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 13 13:17:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 13 Oct 2008 13:17:08 -0000 Subject: [Varnish] #353: Changelog not updated Message-ID: <052.ad684261434ae76e497f345e109a9f68@projects.linpro.no> #353: Changelog not updated --------------------+------------------------------------------------------- Reporter: arthur | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- In the trunk the Changelog file talks about Varnish 1.0.4 : Change log for Varnish 1.0.4 [snip] Where is the changelog for version 2.* ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 14 03:01:59 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 14 Oct 2008 03:01:59 -0000 Subject: [Varnish] #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed In-Reply-To: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> References: <051.e1c165fdb86e393caefa38ae0f7c55fb@projects.linpro.no> Message-ID: <060.e8939217bfa21a87a3435d38c80a2052@projects.linpro.no> #247: Varnish sends 304 header for ESI pages although some of the included objects might have changed ----------------------+----------------------------------------------------- Reporter: peter | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by eugaia): I've realised after writing this that 3 is already possible using the set obj.http.cache-control command. Sorry for my ignorance. -- Ticket URL: Varnish The Varnish HTTP Accelerator From ajian521 at gmail.com Tue Oct 14 10:04:50 2008 From: ajian521 at gmail.com (Ajian) Date: Tue, 14 Oct 2008 18:04:50 +0800 Subject: watch the varnish ,no data Message-ID: <9ab009b80810140304p186c2941v2523aab13f9f4971@mail.gmail.com> HI, I use the varnish-2.0-rc1.tar.gz ,I install it without any error ,and configure the vcl.conf . Check it by FireBug , FireBug display : DateTue, 14 Oct 2008 09:37:00 GMTX-Varnish681905755 681731196Age12553 Via1.1 varnish (why the firebug display the varnish is 1.1 ,is not 2.0. Is it the HTTP 1.1 ?) As a result Varnish is running well . but I use *varnishstat* check varnish ,It's bad, the cache_hit is 0 . 0+06:34:09 imobile-23 Hitrate ratio: 0 0 0 Hitrate avg: 0.0000 0.0000 0.0000 38 0.00 0.00 Client connections accepted 105 0.00 0.00 Client requests received 0 0.00 0.00 Cache hits 0 0.00 0.00 Cache hits for pass 0 0.00 0.00 Cache misses 165 0.00 0.01 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 0 0.00 0.00 Backend connections failures 146 0.00 0.01 Backend connections reuses 165 0.00 0.01 Backend connections recycles 0 0.00 0.00 Backend connections unused 1 . . N struct srcaddr 0 . . N active struct srcaddr 13 . . N struct sess_mem 1 . . N struct sess 0 . . N struct object 9 . . N struct objecthead 3 . . N struct smf 0 . . N small free smf 3 . . N large free smf 1 . . N struct vbe_conn 6 . . N struct bereq I don't know it's my mistake or it's the varnish's bug. if it's my mistake tell me why .The following is my vcl.conf backend default { .host = "192.168.0.24"; .port = "80"; ; } acl purge { "localhost"; "192.168.0.0"/16; } sub vcl_recv { # Handle special requests if (req.request != "GET" && req.request != "HEAD") { # POST - Logins and edits if (req.request == "POST") { pass; #pipe; } # PURGE - The CacheFu product can invalidate updated URLs if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } lookup; } } # Don't cache authenticated requests if (req.http.Cookie && req.http.Cookie ~ "__ac(|_(name|password|persistent))=") { # Force lookup of specific urls unlikely to need protection if (req.url ~ "\.(jpeg|png|js|css)") { unset req.http.cookie; lookup; } pass; } if (req.http.Cookie) { unset req.http.cookie; lookup; } # The default vcl_recv is used from here. } # Do the PURGE thing sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged"; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache"; } } I send the bug for the first time ,I don't know the form is right or wrong ? I hope write it back ,Thank you ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at cheney.net Tue Oct 14 10:09:24 2008 From: dave at cheney.net (Dave Cheney) Date: Tue, 14 Oct 2008 21:09:24 +1100 Subject: watch the varnish ,no data In-Reply-To: <9ab009b80810140304p186c2941v2523aab13f9f4971@mail.gmail.com> References: <9ab009b80810140304p186c2941v2523aab13f9f4971@mail.gmail.com> Message-ID: I'm pretty sure that refers to the HTTP version, so HTTP/1.1 not Varnish's version. Cheers Dave On 14/10/2008, at 9:04 PM, Ajian wrote: > > Date > Tue, 14 Oct 2008 09:37:00 GMT > X-Varnish > 681905755 681731196 > Age > 12553 > Via > 1.1 varnish > > (why the firebug display the varnish is 1.1 ,is not 2.0. Is it the > HTTP 1.1 ?) From phk at phk.freebsd.dk Tue Oct 14 10:45:57 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 14 Oct 2008 10:45:57 +0000 Subject: watch the varnish ,no data In-Reply-To: Your message of "Tue, 14 Oct 2008 21:09:24 +1100." Message-ID: <1787.1223981157@critter.freebsd.dk> In message , Dave Cheney write s: >I'm pretty sure that refers to the HTTP version, so HTTP/1.1 not >Varnish's version. Correct, that is what RFC2616 demands. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dave at cheney.net Tue Oct 14 10:48:31 2008 From: dave at cheney.net (Dave Cheney) Date: Tue, 14 Oct 2008 21:48:31 +1100 Subject: watch the varnish ,no data In-Reply-To: <1787.1223981157@critter.freebsd.dk> References: <1787.1223981157@critter.freebsd.dk> Message-ID: PHK is, of course, correct http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45 Cheers Dave On 14/10/2008, at 9:45 PM, Poul-Henning Kamp wrote: >> I'm pretty sure that refers to the HTTP version, so HTTP/1.1 not >> Varnish's version. > > Correct, that is what RFC2616 demands. From varnish-bugs at projects.linpro.no Tue Oct 14 11:15:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 14 Oct 2008 11:15:22 -0000 Subject: [Varnish] #347: b00019.vtc fails sometimes. In-Reply-To: <052.993d1e7cb8e42680f847e99e4934a7cc@projects.linpro.no> References: <052.993d1e7cb8e42680f847e99e4934a7cc@projects.linpro.no> Message-ID: <061.4d208796c024f3d5a4507a19ad22ad79@projects.linpro.no> #347: b00019.vtc fails sometimes. -------------------------+-------------------------------------------------- Reporter: ingvar | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r3294 -- Ticket URL: Varnish The Varnish HTTP Accelerator From ajian521 at gmail.com Wed Oct 15 02:05:02 2008 From: ajian521 at gmail.com (Ajian) Date: Wed, 15 Oct 2008 10:05:02 +0800 Subject: watch the varnish ,no data In-Reply-To: References: <9ab009b80810140304p186c2941v2523aab13f9f4971@mail.gmail.com> Message-ID: <9ab009b80810141905x19a977c9h625be68284f516c4@mail.gmail.com> Thanks , Another questions? Why the *varnishstat* watch the varnish cache_hit,Hitrate ratio,Hitrate avg are zero . Now varnish is working well but I can't watch the data. I doubt my configure is right or wrong ,Please tell my why . It's the varnish's bug or It's my mistake . Thanks one more time . Hitrate ratio: 0 0 0 Hitrate avg: 0.0000 0.0000 0.0000 2008/10/14 Dave Cheney > I'm pretty sure that refers to the HTTP version, so HTTP/1.1 not Varnish's > version. > > Cheers > > Dave > > > On 14/10/2008, at 9:04 PM, Ajian wrote: > > >> Date >> Tue, 14 Oct 2008 09:37:00 GMT >> X-Varnish >> 681905755 681731196 >> Age >> 12553 >> Via >> 1.1 varnish >> >> (why the firebug display the varnish is 1.1 ,is not 2.0. Is it the HTTP >> 1.1 ?) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Thu Oct 16 10:26:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 16 Oct 2008 10:26:16 -0000 Subject: [Varnish] #353: Changelog not updated In-Reply-To: <052.ad684261434ae76e497f345e109a9f68@projects.linpro.no> References: <052.ad684261434ae76e497f345e109a9f68@projects.linpro.no> Message-ID: <061.d7d4cd3d035484f52c8e88f55fbc2f14@projects.linpro.no> #353: Changelog not updated --------------------+------------------------------------------------------- Reporter: arthur | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r3299. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 16 15:16:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 16 Oct 2008 15:16:00 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.019704f2d729bf9a8b4b897fa67c1da2@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by peter): I think we are running in the same problem when trying to benchmark an ESI page. Has there been any progress on this problem? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 08:45:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 08:45:25 -0000 Subject: [Varnish] #354: Segfault in strcmp in http_DissectRequest() Message-ID: <049.9b20ee39c069a29bda51077c9a05432c@projects.linpro.no> #354: Segfault in strcmp in http_DissectRequest() ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: ----------------------+----------------------------------------------------- Reported by various. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 09:04:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 09:04:57 -0000 Subject: [Varnish] #354: Segfault in strcmp in http_DissectRequest() In-Reply-To: <049.9b20ee39c069a29bda51077c9a05432c@projects.linpro.no> References: <049.9b20ee39c069a29bda51077c9a05432c@projects.linpro.no> Message-ID: <058.e4878c751c4be15729e5c6498d71a33f@projects.linpro.no> #354: Segfault in strcmp in http_DissectRequest() ----------------------+----------------------------------------------------- Reporter: phk | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This was caused by an attempt to find the HTTP version on badly formed HTTP requests. Fixed in r3315 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 17:07:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 17:07:21 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.db0ea47b4453f81874931de227178eca@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): Although it might be trivial, here is how to reproduce the bug: 1. Extract file into root of server. 2. Edit vcl to make index.html parsed by ESI 3. Download and build Openload 4. Run 'openload http://host/varnish/index.html' -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 18:34:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 18:34:23 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.c0ea1c879e74a6d23525afef85afdada@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by peter): This is my trace for this error: {{{ Child (31926) Panic message: Assert error in CNT_Session(), cache_center.c line 1008: Condition(sp->step == STP_FIRST || sp->step == STP_START || sp->step == STP_LOOKUP || sp->step == STP_RECV) not true. thread = (cache-worker)sp = 0x2b255004 { fd = -1, id = 42, xid = 0, client = 10.0.0.2:57384, step = STP_DONE, handling = HASH, ws = 0x2b25504c { id = "sess", {s,f,r,e} = {0x2b2554dc,,+276,(nil),+8192}, }, worker = 0x2e3e2110 { }, }, }}} I can reproduce this using Apache Bench (ab) from the command line with a concurrency of 50 and letting it run for 30 seconds (it stops immediately however). The error I get from ab is: {{{ Benchmarking 10.0.0.7 (be patient) apr_socket_recv: Connection reset by peer (54) Total of 186 requests completed }}} I've copied the ESI example of the Wiki and modified it a little (added one extra include and date.cgi is date.php in my case). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 19:55:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 19:55:43 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.111a7c20262f43363b2f8168ce002fb0@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): OK, I have it reproduced: An ESI include hitting the waitinglist is the bad news. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 21:01:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 21:01:03 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.465ec33426b7c5eb952620759a244bf1@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by peter): Ok, I just got it reproduced on a FreeBSD 7 VMWare, but you don't need the details anymore as I understand? Is this really bad news because it can't be easily fixed or do you mean with the bad news what the cause is? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 17 21:29:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Oct 2008 21:29:49 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.2373e77bb6435766e6fd1982d4ccee78@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | 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 [3322]) ESI includes can hit the waiting list and since the state is stored on the worker thread stack, we cannot just let another thread pick up. This is not as much a fix as a workaround: simply sleep until the object we wait for is no longer busy. The issue may have to be revisited in the long run, but for 2.0.x this will have to do. Fixes #345 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 18 08:51:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 18 Oct 2008 08:51:38 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.93aeda6e3bf2fd8747d042958adc7578@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by peter): Thank you very much! Just tried it again and it's now very stable! What are the implications of this workaround versus a real fix, only a little loss in performance? Because the performance is still more than ok as far as I can see, but only tested in a VM... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 18 08:54:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 18 Oct 2008 08:54:35 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.9218929eb38a4a226bd1c18c7d85b944@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by peter): BTW, is this fix part of 2.0.1? If not, any chance a 2.0.2 release will be released soon? Thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 18 08:56:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 18 Oct 2008 08:56:50 -0000 Subject: [Varnish] #345: Assert error in CNT_Session() In-Reply-To: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> References: <053.1d607a53ea420ff95153f71873be5407@projects.linpro.no> Message-ID: <062.20633596c19ab719d7449666d8968c92@projects.linpro.no> #345: Assert error in CNT_Session() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Normally we don't hold more than one worker thread "hostage" while we wait for the backend to reply, but in this case references via ESI:include will hold their worker thread hostage also. Depending how often ESI:include hits busy objects, this may or may not lead to increased thread pools. Using grace, even with just a couple of seconds grace, would mitigate this in many cases. Dunno about 2.0.2, that's not my decision. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 20 11:40:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 20 Oct 2008 11:40:53 -0000 Subject: [Varnish] #355: grace not documented Message-ID: <050.8925fc4ff5931834e2a641a3ee266395@projects.linpro.no> #355: grace not documented -----------------------+---------------------------------------------------- Reporter: eric | Type: documentation Status: new | Priority: low Milestone: | Component: documentation Version: 2.0 | Severity: normal Keywords: vcl grace | -----------------------+---------------------------------------------------- req.grace and obj.grace is not documented in the vcl manual pages. -- Eric -- Ticket URL: Varnish The Varnish HTTP Accelerator From kradziszewski at gmail.com Mon Oct 20 11:34:57 2008 From: kradziszewski at gmail.com (Kamil Radziszewski) Date: Mon, 20 Oct 2008 13:34:57 +0200 Subject: Solaris x86_64 with SunStudio Message-ID: <231965b00810200434g164c522cr996898587fd6c72@mail.gmail.com> Hi, I compiled varnish-2.0.1 under SunStudio 12 on Solaris 10u5 in 64bit. 1. LDFLAGS=-m64 CFLAGS=-m64 ./configure --prefix=/opt/varnish-2.0.1 2. make && make install When I try to run varnishd I get this error: mgt_run_cc(): failed to load compiled VCL program: ld.so.1: varnishd: fatal: ./vcl.ORk8t3RP.so: wrong ELF class: ELFCLASS32 VCL compilation failed. I modified the config.h file after ./configure process : from: /* C compiler command line for VCL code */ #define VCC_CC "cc -Kpic -G -o %o %s" to: /* C compiler command line for VCL code */ #define VCC_CC "cc -m64 -Kpic -G -o %o %s" After this, varnishd starts without any errors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kradziszewski at gmail.com Mon Oct 20 11:37:12 2008 From: kradziszewski at gmail.com (Kamil Radziszewski) Date: Mon, 20 Oct 2008 13:37:12 +0200 Subject: "mgt_run_cc(): failed to load compiled VCL program" under x86_64 Solaris10u5 Message-ID: <231965b00810200437y35970134ya7421414df84d96a@mail.gmail.com> Hi, I compiled varnish-2.0.1 under SunStudio 12 on Solaris 10u5 in 64bit. 1. LDFLAGS=-m64 CFLAGS=-m64 ./configure --prefix=/opt/varnish-2.0.1 2. make && make install When I try to run varnishd I get this error: mgt_run_cc(): failed to load compiled VCL program: ld.so.1: varnishd: fatal: ./vcl.ORk8t3RP.so: wrong ELF class: ELFCLASS32 VCL compilation failed. I modified the config.h file after ./configure process : from: /* C compiler command line for VCL code */ #define VCC_CC "cc -Kpic -G -o %o %s" to: /* C compiler command line for VCL code */ #define VCC_CC "cc -m64 -Kpic -G -o %o %s" After this, varnishd starts without any errors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Tue Oct 21 09:02:11 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 21 Oct 2008 09:02:11 -0000 Subject: [Varnish] #356: v00017.vtc fails on x86_64 Message-ID: <051.f99bddfcf0e83b27a73b71e0bb8abdaf@projects.linpro.no> #356: v00017.vtc fails on x86_64 -------------------------------+-------------------------------------------- Reporter: wiebe | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: v00017.vtc x86_64 | -------------------------------+-------------------------------------------- Varnish 2.0.1 does not compile on x86_64 platforms (rhel5), the v00017.vtc test fails : {{{ # top TEST ././tests/v00017.vtc starting # TEST VCL compiler coverage test: vcc_acl.c ## v1 Launch ### v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/__v1 -a '127.0.0.1:9091' -T 127.0.0.1 :9011 -P /tmp/__v1/varnishd.pid ### v1 opening CLI connection ### v1 CLI connection fd = 3 ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) ### v1 CLI STATUS 200 ### v1 CLI STATUS 200 ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) ### v1 CLI STATUS 106 ## v1 VCL compilation failed (as expected) ### v1 CLI STATUS 200 ---- v1 VCL compilation got 200 expected 106 ---- TEST FILE: ././tests/v00017.vtc ---- TEST DESCRIPTION: VCL compiler coverage test: vcc_acl.c FAIL: ./tests/v00017.vtc =============================================== 1 of 96 tests failed Please report to varnish-dev at projects.linpro.no =============================================== }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 21 09:59:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 21 Oct 2008 09:59:46 -0000 Subject: [Varnish] #357: Varnish exits quietly when arguments to -a or -T resolves to multiple, similar IP addresses Message-ID: <049.9f614c149e511516cbb17ff505bd0570@projects.linpro.no> #357: Varnish exits quietly when arguments to -a or -T resolves to multiple, similar IP addresses ----------------------+----------------------------------------------------- Reporter: ssm | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- = Summary = When a hostname used as an argument for -a or -t resolves to multiple, similar, IP addresses, varnish exits at start with return code 0, and no error message. = Environment = Observed on Linux 2.6. This was observed when the name "localhost" resolved to multiple similar addresses. Not exactly a common scenario, hopefully. /etc/hosts contained the following information for "localhost": {{{ 127.0.0.1 localhost 127.0.0.1 localhost.localdomain localhost }}} When starting without "-d", the exit code is "0", and no error messages are printed. No varnish processes are running before or after these commands have been run. {{{ # /usr/sbin/varnishd -P /var/run/varnishd.pid -a localhost:6081 -T 127.0.0.1:6082 -b 127.0.0.1:8080 -u varnish -g varnish storage_file: filename: ./varnish.R7z0le (unlinked) size 715 MB. Using old SHMFILE # /usr/sbin/varnishd -P /var/run/varnishd.pid -a 127.0.0.1:6081 -T localhost:6082 -b 127.0.0.1:8080 -u varnish -g varnish storage_file: filename: ./varnish.atOxPT (unlinked) size 715 MB. Using old SHMFILE }}} = Debugging = With debugging, a bit more information is available, at least for the management address: == debug: service address == The -a address resolves to multiple (similar) IP addresses. Exit code here is "0". {{{ # /usr/sbin/varnishd -d -P /var/run/varnishd.pid -a localhost:6081 -T 127.0.0.1:6082 -b 127.0.0.1:8080 -u varnish -g varnish storage_file: filename: ./varnish.6FMb2V (unlinked) size 715 MB. Using old SHMFILE New Pid 11375 Debugging mode, enter "start" to start child start child (11376) Started Pushing vcls failed: CLI communication error Child (11376) said Closed fds: 3 5 7 11 12 14 15 Child (11376) said Child starts Child (11376) said managed to mmap 750772224 bytes of 750772224 Child (11376) said Ready unlink ./vcl.1P9zoqAU.so k 1 rev 16 # }}} == debug: management address == The -T address resolves to multiple (similar) IP addresses. Exit code here is "0". {{{ # /usr/sbin/varnishd -d -P /var/run/varnishd.pid -a 127.0.0.1:6081 -T localhost:6082 -b 127.0.0.1:8080 -u varnish -g varnish storage_file: filename: ./varnish.avOhWv (unlinked) size 715 MB. Using old SHMFILE New Pid 11529 bind(): Address already in use Assert error in mgt_cli_telnet(), mgt_cli.c line 478: Condition(sock >= 0) not true. errno = 98 (Address already in use) k 1 rev 16 # }}} == debug: backend address == For completeness, I tried with the backend address as well. The exit code here is "2", and an error message is printed. This is expected behaviour. The -b address resolves to multiple (similar) IP addresses. {{{ # /usr/sbin/varnishd -d -P /var/run/varnishd.pid -a 127.0.0.1:6081 -T 127.0.0.1:6082 -b localhost:8080 -u varnish -g varnish Backend host "localhost": resolves to multiple IPv4 addresses. Only one address is allowed. Please specify which exact address you want to use, we found these: 127.0.0.1 127.0.0.1 (input Line 2 Pos 13) .host = "localhost"; ------------###########- In backend specification starting at: (input Line 1 Pos 1) backend default { #######---------- VCL compilation failed # }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 21 12:17:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 21 Oct 2008 12:17:25 -0000 Subject: [Varnish] #358: pre-allocated cache file gets shrunk on start of varnishd Message-ID: <052.cad7b471086d56fbda7c33534524c287@projects.linpro.no> #358: pre-allocated cache file gets shrunk on start of varnishd --------------------+------------------------------------------------------- Reporter: sascha | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | --------------------+------------------------------------------------------- With the new version, my cache file gets shrunk. I made it with dd with a size of ~259 GB, but after starting varnishd, only about 119 GB are left. I don't give a size parameter when starting, as in -s file,/var/cache/varnish/store.bin which worked as expected with older releases. after another reboot/restart, the cache file has 189 GB. according to a post from Tollef, it seems as if the already existing file isn't honored, and instead a new file with a size of 50 % of the free space is created. -- Ticket URL: Varnish The Varnish HTTP Accelerator From kradziszewski at gmail.com Wed Oct 22 13:13:25 2008 From: kradziszewski at gmail.com (Kamil Radziszewski) Date: Wed, 22 Oct 2008 15:13:25 +0200 Subject: Again - On Solaris, request is not sent to the backend and varnish reports 503 Message-ID: <231965b00810220613q1dfb386fw81f49fd354dde3a6@mail.gmail.com> OS: Solaris 10 5/08 s10x_u5wos_10 X86 Compilator: SunStudio12 VarnishVersion: 2.0.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at projects.linpro.no Wed Oct 22 21:47:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 22 Oct 2008 21:47:57 -0000 Subject: [Varnish] #210: The binary heap implementation does not scale In-Reply-To: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> References: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no> Message-ID: <058.6c39cb055213ecf201de30da9f844448@projects.linpro.no> #210: The binary heap implementation does not scale -------------------------+-------------------------------------------------- Reporter: phk | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by eugaia): I'm not really sure how the implementation works, but could it be possible to add another level of hashing? There could be a setting for caches that have very large object sets, that does some kind of double-hashing of hash string, whereas smaller sites only had one. As I say, I don't know how things work so that may just sound silly to you guys that know what's going on. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 23 06:19:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Oct 2008 06:19:12 -0000 Subject: [Varnish] #359: regsub documented as using $1, $2 etc, but actually uses \1, \2 for replacement strings Message-ID: <052.caf5e0adaa1ed9af7ff10129b15d8a9c@projects.linpro.no> #359: regsub documented as using $1,$2 etc, but actually uses \1, \2 for replacement strings --------------------+------------------------------------------------------- Reporter: eugaia | Type: documentation Status: new | Priority: low Milestone: | Component: documentation Version: trunk | Severity: minor Keywords: regsub | --------------------+------------------------------------------------------- Everywhere I've seen in the documentation, it says that $1,$2 etc are used for replacement strings in regsub, e.g. set bereq.url = regsub ( req.url , "/from_dir/(.*)" , "/to/url=$1" ); However, this just results in a literal '$1' inserted. In fact \1,\2 etc are used, so it should be set bereq.url = regsub ( req.url , "/from_dir/(.*)" , "/to/url=\1" ); This can be confusing, and should be fixed at some point. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 23 08:39:28 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 23 Oct 2008 08:39:28 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.6a5186f8a1bdb0173e3498d1280179c5@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): child stops responding,maybe because many stale url or invalid url requests. many appearance like http://varnish.projects.linpro.no/ticket/278 this is a test. tool : http_load files: old_urlfile : with many stale urls new_urlfile : valid urls appearance? http_load with old_urlfile? varnish child restarted 2 times. Using varnishstat tool, sometimes, 'Client connections accepted ' increased , and 'Client requests received'?'Client requests received' reduced quickly ; 'overflowed work requests','dropped work requests' increased http_load with new_urlfile: varnish worked well, all parameter keep balance. ./http_load -proxy xxx.xx.xx.xx:80 -parallel 300 -seconds 600 old_urlfile {{{ 230308 fetches, 300 max parallel, 3.46973e+09 bytes, in 600 seconds 15065.6 mean bytes/connection 383.846 fetches/sec, 5.78288e+06 bytes/sec msecs/connect: 16.6254 mean, 3005.54 max, 0.214 min msecs/first-response: 663.117 mean, 58565 max, 0.078 min 274 timeouts 746 bad byte counts HTTP response codes: code 200 -- 227006 code 301 -- 4 code 400 -- 2 code 403 -- 745 code 404 -- 1579 code 503 -- 53 }}} ./http_load -proxy xxx.xx.xx.xx:80 -parallel 300 -seconds 600 new_urlfile {{{ 2142952 fetches, 300 max parallel, 4.33502e+10 bytes, in 600 seconds 20229.2 mean bytes/connection 3571.59 fetches/sec, 7.22504e+07 bytes/sec msecs/connect: 59.8291 mean, 9006.85 max, 0.206 min msecs/first-response: 9.14167 mean, 10636.9 max, 0.305 min 101 bad byte counts HTTP response codes: code 200 -- 2136852 code 403 -- 393 code 404 -- 5670 code 503 -- 36 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 24 11:15:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 24 Oct 2008 11:15:25 -0000 Subject: [Varnish] #360: Cannot create temp file on startup Message-ID: <052.b5fd53604abc3f624eff0e699d9d04b0@projects.linpro.no> #360: Cannot create temp file on startup ----------------------+----------------------------------------------------- Reporter: ltning | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Starting varnishd 2.0.1 with default startup script on FreeBSD 7.0 inside a jail fails in bin/varnishd/mgt_vcc.c line 152. It attempts to create a temporary file for compiling the VCL (presumably), using a relative path (i.e. no idea where it actually attempts to create it. Specifying instance name with -n /tmp/foo and chowning /tmp/foo to www is a workaround. It seems that having a world-writeable directory is not sufficient; it must be owned by the same user as the varnishd process (needs confirmation). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 25 01:36:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 25 Oct 2008 01:36:15 -0000 Subject: [Varnish] #361: random director only sending traffic to one backend Message-ID: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> #361: random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Keywords: director -----------------------+---------------------------------------------------- Howdy, To summarize, I have three machines running Ubuntu Server 8.04.1. The two backend boxes are running Apache 2.2 serving static content and proxing to local Jetty6 containers, and the frontend box is running Varnish 2.0.1 with a random director. However, only the second backend receives any requests. If the second backend is sick the director properly switches to the first backend, which is good, but I was ideally hoping to have both backends active. I saw a similar report in the list archives from September by duja at torlen.net, but I didn't see a bug report. My VCL to setup the backends and director is like so: backend web01 { .host = "10.107.111.30"; .port = "80"; .host_header = "hostname.ca"; .probe = { .url = "/index.gsp"; .timeout = 50 ms; .interval = 2s; .window = 10; .threshold = 8; } } backend web02 { .host = "10.107.111.31"; .port = "80"; .host_header = "hostname.ca"; .probe = { .url = "/index.gsp"; .timeout = 50 ms; .interval = 2s; .window = 10; .threshold = 8; } } director balance random { { .backend = web01; .weight = 1; } { .backend = web02; .weight = 1; } } Also, per discussion I read at some point while setting this up, I have disabled keepalives in Apache. Some perhaps useful varnishstat output: 24005 0.00 0.09 Client connections accepted 129163 4.00 0.49 Client requests received 101185 4.00 0.39 Cache hits 1464 0.00 0.01 Cache hits for pass 26511 0.00 0.10 Cache misses 27978 0.00 0.11 Backend connections success 0 0.00 0.00 Backend connections not attempted 0 0.00 0.00 Backend connections too many 0 0.00 0.00 Backend connections failures 0 0.00 0.00 Backend connections reuses 0 0.00 0.00 Backend connections recycles 0 0.00 0.00 Backend connections unused Let me know if there's any other info I can provide, with the caveat that this is a production setup so any disruption will need to be brief. Thanks, Bryan -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 25 12:02:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 25 Oct 2008 12:02:17 -0000 Subject: [Varnish] #362: Add malloc size option to varnishd.1 manual page Message-ID: <048.6d6293d69bbb64b321d0094c7f25f6f5@projects.linpro.no> #362: Add malloc size option to varnishd.1 manual page ---------------------------+------------------------------------------------ Reporter: mm | Owner: phk Type: documentation | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ---------------------------+------------------------------------------------ The varnishd.1 manual page is missing the malloc size limit feature. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Oct 25 20:55:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 25 Oct 2008 20:55:42 -0000 Subject: [Varnish] #363: The first POST request is replaced by GET Message-ID: <053.a1f0b750ba0de527247294d34b1f6df0@projects.linpro.no> #363: The first POST request is replaced by GET ----------------------+----------------------------------------------------- Reporter: tcouery | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: 2.0 Severity: normal | Keywords: POST ----------------------+----------------------------------------------------- When a POST request (RxRequest=POST) is sending for the first time and the "vcl_fetch" choose "lookup" then the backend receive a GET request (TxRequest=GET). '''Varnishlog:''' {{{ 9 SessionOpen c 10.10.10.10 4202 0.0.0.0:7070 9 ReqStart c 10.10.10.10 4202 1108969861 9 RxRequest c POST 9 RxURL c /backoffice/Modification.serv 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: server:7070 9 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 9 RxHeader c Accept: text/javascript, text/html, application/xml, text/xml, */* 9 RxHeader c Accept-Language: fr,en;q=0.8,fr-fr;q=0.5,en-us;q=0.3 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 RxHeader c X-Requested-With: XMLHttpRequest 9 RxHeader c X-Prototype-Version: 1.6.0.2 9 RxHeader c Content-Type: application/x-www-form-urlencoded; charset=UTF-8 9 RxHeader c Referer: http://server:7070/page.html 9 RxHeader c Content-Length: 179 9 RxHeader c Cookie: JSESSIONID=15878C33A57E8AF324F6F93A89972AD4; 9 RxHeader c Pragma: no-cache 9 RxHeader c Cache-Control: no-cache 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 VCL_call c miss 9 VCL_return c fetch 11 BackendOpen b default 127.0.0.1 57805 127.0.0.1 8080 9 Backend c 11 default default 11 TxRequest b GET 11 TxURL b /backoffice/Modification.serv 11 TxProtocol b HTTP/1.1 11 TxHeader b Host: server:7070 11 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 11 TxHeader b Accept: text/javascript, text/html, application/xml, text/xml, */* 11 TxHeader b Accept-Language: fr,en;q=0.8,fr-fr;q=0.5,en-us;q=0.3 11 TxHeader b Accept-Encoding: gzip,deflate 11 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 11 TxHeader b X-Requested-With: XMLHttpRequest 11 TxHeader b X-Prototype-Version: 1.6.0.2 11 TxHeader b Content-Type: application/x-www-form-urlencoded; charset=UTF-8 11 TxHeader b Referer: http://server:7070/page.html 11 TxHeader b Cookie: JSESSIONID=15878C33A57E8AF324F6F93A89972AD4; 11 TxHeader b Pragma: no-cache 11 TxHeader b X-Varnish: 1108969861 11 TxHeader b X-Forwarded-For: 10.10.10.10 11 RxProtocol b HTTP/1.1 11 RxStatus b 200 11 RxResponse b OK 11 RxHeader b Server: Apache-Coyote/1.1 11 RxHeader b Cache-Control: no-cache, post-check=0, pre-check=0 11 RxHeader b Pragma: no-cache 11 RxHeader b Content-Type: application/json;charset=UTF-8 11 RxHeader b Content-Length: 116 11 RxHeader b Date: Sat, 25 Oct 2008 20:23:25 GMT }}} '''vcl.conf:''' {{{ backend default { .host = "127.0.0.1"; .port = "8080"; } sub vcl_recv { lookup; } sub vcl_fetch { if(obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no-cache" || obj.http.Cache-Control ~ "private" || !obj.cacheable || obj.http.Set-Cookie) { pass; } deliver; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 28 21:37:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Oct 2008 21:37:03 -0000 Subject: [Varnish] #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: Message-ID: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: -------------------+-------------------------------------------------------- Reporter: sky | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- {{{ Child (26886) Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: Condition((p) != 0) not true. thread = (cache-worker)sp = 0x7fa02e565008 { fd = 2587, id = 2587, xid = 1102107080, client = 69.76.134.78:29427, step = STP_LOOKUP, handling = LOOKUP, ws = 0x7fa02e565078 { overflow id = "sess", {s,f,r,e} = {0x7fa02e5657b0,,+8180,(nil),+8192}, }, worker = 0x7f9b75debc10 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 28 21:52:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 28 Oct 2008 21:52:04 -0000 Subject: [Varnish] #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: In-Reply-To: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> References: <049.3002d0474221823a2f18635787aa854b@projects.linpro.no> Message-ID: <058.10fb0db69077019181d40f7ad2774083@projects.linpro.no> #364: Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: --------------------+------------------------------------------------------- Reporter: sky | Owner: sky Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * owner: => sky -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 29 18:08:10 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Oct 2008 18:08:10 -0000 Subject: [Varnish] #365: Calling "restart" from "vcl_hit" serves an empty request. Message-ID: <053.3bd80ec1bb4dbb46e6379b8b1ddd1b94@projects.linpro.no> #365: Calling "restart" from "vcl_hit" serves an empty request. ----------------------+----------------------------------------------------- Reporter: nkallen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- sub vcl_hit { if (...) { restart; } } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 30 09:05:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Oct 2008 09:05:47 -0000 Subject: [Varnish] #361: random director only sending traffic to one backend In-Reply-To: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> References: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> Message-ID: <064.2f9e083b16e1401620bfd43fa8c7a494@projects.linpro.no> #361: random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: director | -----------------------+---------------------------------------------------- Comment (by foxdie): This bug is also present in trunk R3355 (and most likely up to R3357 which is the latest release at this post, and has only had superficial man page updates since R3355). Swapping the order of the backends works as expected, its always the second in the list that doesn't work. I'll do some more testing today to see if tertiary (aka third) backend's get used. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 30 09:07:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Oct 2008 09:07:36 -0000 Subject: [Varnish] #361: random director only sending traffic to one backend In-Reply-To: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> References: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> Message-ID: <064.1644aafed746e59320f93595451b5a2a@projects.linpro.no> #361: random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: director | -----------------------+---------------------------------------------------- Comment (by foxdie): Replying to [comment:1 foxdie]: > This bug is also present in trunk R3355 (and most likely up to R3357 which is the latest release at this post, and has only had superficial man page updates since R3355). > > Swapping the order of the backends works as expected, its always the second in the list that doesn't work. > > I'll do some more testing today to see if tertiary (aka third) backend's get used. CORRECTION! It's always the FIRST in the list that doesn't get polled (based on 2 backends, about to test with 3). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 30 09:56:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Oct 2008 09:56:34 -0000 Subject: [Varnish] #361: random director only sending traffic to one backend In-Reply-To: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> References: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> Message-ID: <064.ba55f50f06c12fb93083a5a30b196970@projects.linpro.no> #361: random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: director | -----------------------+---------------------------------------------------- Comment (by foxdie): Okay, testing with the following director: director myDirector random { { .backend = ServerA; .weight = 5; } { .backend = ServerB; .weight = 4; } { .backend = ServerC; .weight = 5; } } Only ServerC received requests in this test. My guess is its probably not an index problem now, its probably a weighting bug, where the last backend in the list is grossly outweighting every other backend, I could be mistaken but at least it gives the developers an avenue to inspect. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 30 10:09:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Oct 2008 10:09:01 -0000 Subject: [Varnish] #366: CLI Communication Error when calling vcl.discard in management interface Message-ID: <052.1727b4b0db11f5c555d134fb64c4b0fd@projects.linpro.no> #366: CLI Communication Error when calling vcl.discard in management interface ----------------------+----------------------------------------------------- Reporter: foxdie | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: cli, communication, error, vcl.discard, discard ----------------------+----------------------------------------------------- This ones only a minor problem, when telnet'ed into the management interface, if I try and discard an unused vcl sometimes I get the following: {{{ vcl.load test /etc/varnish/live.vcl.experimental 200 13 VCL compiled. vcl.use test 200 0 vcl.use boot 200 0 vcl.discard test 400 23 CLI communication error vcl.discard test 200 0 }}} But as you can see, reissuing the command it works. This is an intermittent problem, it doesn't happen all the time. * Trunk R3355 * Compiled on a quad core xeon X86_64 system running Centos 5.x linux * Varnish is configured to use malloc with 128GB storage on a 200GB RAID 10 Swap partition * If any more info is needed, you can message me on the IRC channel (irc.linpro.no in #varnish) or reply here. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 30 11:22:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 30 Oct 2008 11:22:26 -0000 Subject: [Varnish] #361: [PATCH] random director only sending traffic to one backend In-Reply-To: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> References: <055.ff8050d51e9e973aa20befaaf5323a41@projects.linpro.no> Message-ID: <064.dc755b3d82eaea81626f776568a2cc23@projects.linpro.no> #361: [PATCH] random director only sending traffic to one backend -----------------------+---------------------------------------------------- Reporter: fehwalker | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 2.0 Severity: major | Resolution: Keywords: director | -----------------------+---------------------------------------------------- Changes (by petter): * summary: random director only sending traffic to one backend => [PATCH] random director only sending traffic to one backend Comment: The only time that s1 and s2 are the same are when hitting the last backend, as the summation of s2 is stopped when a backend is found. Awaiting comment from PHK -- Ticket URL: Varnish The Varnish HTTP Accelerator