From varnish-bugs at projects.linpro.no Fri Apr 4 21:04:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 04 Apr 2008 21:04:06 -0000 Subject: [Varnish] #215: regex matches sporadically on identical request In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> Message-ID: <063.0e04a237d2ec436f2f32cd719b2dd7ff@projects.linpro.no> #215: regex matches sporadically on identical request ----------------------+----------------------------------------------------- Reporter: onitunes | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 1.0.4 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by onitunes): Bump. This problem still plagues our Varnish installation. Any pointers on how to debug this or even where to look are appreciated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 8 13:09:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 08 Apr 2008 13:09:25 -0000 Subject: [Varnish] #215: regex matches sporadically on identical request In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> Message-ID: <063.46190a7b94a3c64660b66ceb61e9545d@projects.linpro.no> #215: regex matches sporadically on identical request ----------------------+----------------------------------------------------- Reporter: onitunes | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 1.0.4 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I have tried very hard to reproduce this and have gotten no where at all. You can try to enable the vcl_trace parameter, that will give you line+char tracing for all VCL code, so that would tell you if the regexp matches or not. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 11 11:12:19 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 11 Apr 2008 11:12:19 -0000 Subject: [Varnish] #226: Varnishd crashes on STV_alloc at stevedore.c:72 Message-ID: <054.5bcee183f43744c7725f00eb312fe1b7@projects.linpro.no> #226: Varnishd crashes on STV_alloc at stevedore.c:72 ----------------------+----------------------------------------------------- Reporter: dingdeng | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.2 Severity: normal | Keywords: varnishd STV_alloc ----------------------+----------------------------------------------------- 1.2 branch, revision 2629. Here is the backtrace: {{{ #0 0x0000000800c0d56c in thr_kill () from /lib/libc.so.6 #1 0x000000080099101c in raise () from /usr/lib/libthr.so.2 #2 0x0000000800c8d49d in abort () from /lib/libc.so.6 #3 0x000000080066dc19 in lbv_assert (func=0x4381e8 "STV_alloc", file=0x4381ff "stevedore.c", line=72, cond=0x4381f2 "(st) != NULL", err=32) at assert.c:60 #4 0x000000000042b432 in STV_alloc (sp=0x1164008, size=85372413) at stevedore.c:72 #5 0x000000000041210b in fetch_straight (sp=0x1164008, htc=0x7fff5cae6960, b=0x25d13ab "85372413") at cache_fetch.c:63 #6 0x0000000000412f74 in Fetch (sp=0x1164008) at cache_fetch.c:369 #7 0x000000000040eda0 in cnt_fetch (sp=0x1164008) at cache_center.c:320 #8 0x0000000000410a75 in CNT_Session (sp=0x1164008) at steps.h:41 #9 0x0000000000419078 in wrk_do_one (w=0x7fff5cae8ad0) at cache_pool.c:195 #10 0x0000000000419553 in wrk_thread (priv=0x58f720) at cache_pool.c:248 #11 0x000000080099355b in pthread_create () from /usr/lib/libthr.so.2 #12 0x0000000000000000 in ?? () Cannot access memory at address 0x7fff5cae9000 }}} If you need more information, please let me know. Thanks for your kind help ;-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 15 21:54:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 15 Apr 2008 21:54:58 -0000 Subject: [Varnish] #215: regex matches sporadically on identical request In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> Message-ID: <063.3a694272adb24c59f97bac4054b2b478@projects.linpro.no> #215: regex matches sporadically on identical request ----------------------+----------------------------------------------------- Reporter: onitunes | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 1.0.4 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by onitunes): Thanks for looking into it. I'll work on the vcl_trace stuff next and also check the source code. One thing that I forgot to mention is that our Varnish instance binds to multiple interfaces (a "public" network and a "private" network). Could the backend selection logic be going through some additional hoops as a result? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Apr 17 21:21:23 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 17 Apr 2008 21:21:23 -0000 Subject: [Varnish] #227: Abstract the vca_pipes usage for alternative implementations Message-ID: <051.98dfc360d1fd1990ba30fdfcb9bc9300@projects.linpro.no> #227: Abstract the vca_pipes usage for alternative implementations -------------------------+-------------------------------------------------- Reporter: jesus | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- The vca_pipes[2] pipe()-based scheduler wake-up system isn't optimal on all platforms. Each acceptor should setup that stuff in init and have a private implementation of the actually trigger to pass control back into the eventer. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 18 12:49:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 18 Apr 2008 12:49:47 -0000 Subject: [Varnish] #228: Varnish crashes on assert error in Tcheck Message-ID: <052.1ea25d5ad449e0967addbfbb0d6bc81a@projects.linpro.no> #228: Varnish crashes on assert error in Tcheck ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: varnish crash assert error Tcheck ----------------------+----------------------------------------------------- I am running Varnish trunk/2629 on FreeBSD/amd64 7.0-RELEASE (with SCHED_ULE), on Intel hardware. After running for around half an hour, I got a crash: {{{ Child said (2, 880): <> Child said (2, 880): << Condition((t.b) != 0) not true.>> Child said (2, 880): << errno = 35 (Resource temporarily unavailable)>> }}} Backtrace: {{{ (gdb) bt #0 0x0000000800d0cfec in thr_kill () from /lib/libc.so.7 #1 0x0000000800d96c5b in abort () from /lib/libc.so.7 #2 0x000000080066dcaf in lbv_assert (func=Variable "func" is not available. ) at assert.c:65 #3 0x0000000000412fe3 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:661 #4 0x0000000000413674 in http_findhdr (hp=0x8f92268b8, l=Variable "l" is not available. ) at cache_http.c:210 #5 0x000000000041375b in http_GetHdr (hp=0x8f92268b8, hdr=0x539456 "\bExpires:", ptr=0x7ffff399b9f8) at cache_http.c:232 #6 0x00000000004289c8 in RFC2616_Ttl (sp=0x8215f6008, hp=0x8f92268b8, obj=0x8f9226800) at rfc2616.c:138 #7 0x0000000000428c1e in RFC2616_cache_policy (sp=0x8215f6008, hp=0x8f92268b8) at rfc2616.c:195 #8 0x000000000040c77c in cnt_fetch (sp=0x8215f6008) at cache_center.c:342 #9 0x000000000040d462 in CNT_Session (sp=0x8215f6008) at steps.h:41 #10 0x00000000004172c8 in wrk_do_one (w=0x7ffff399dad0) at cache_pool.c:194 #11 0x000000000041758d in wrk_thread (priv=0x800f11240) at cache_pool.c:247 #12 0x0000000800a94a88 in pthread_getprio () from /lib/libthr.so.3 #13 0x0000000000000000 in ?? () Cannot access memory at address 0x7ffff399e000 (gdb) frame 3 #3 0x0000000000412fe3 in Tcheck (t={b = 0x0, e = 0x0}) at cache.h:661 661 AN(t.b); (gdb) print t.b $1 = 0x0 (gdb) frame 4 #4 0x0000000000413674 in http_findhdr (hp=0x8f92268b8, l=Variable "l" is not available. ) at cache_http.c:210 210 Tcheck(hp->hd[u]); (gdb) print *hp $2 = {magic = 1680389577, ws = 0x8f9226828, conds = 0 '\0', logtag = HTTP_Obj, status = 301, hd = {{b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, { b = 0x8f9226b48 "HTTP/1.1", e = 0x8f9226b50 ""}, {b = 0x8f9226b51 "301", e = 0x8f9226b54 ""}, {b = 0x8f9226b55 "Moved Permanently", e = 0x8f9226b66 ""}, { b = 0x8f9226b67 "Date: Fri, 18 Apr 2008 12:20:45 GMT", e = 0x8f9226b8a ""}, { b = 0x8f9226b8b "Server: Apache/2.2.3 (Debian) Resin/3.0.25", e = 0x8f9226bb5 ""}, {b = 0x8f9226bb6 "Pragma: no-cache", e = 0x8f9226bc6 ""}, {b = 0x8f9226bc7 "Cache-Control: no-cache", e = 0x8f9226bde ""}, { b = 0x8f9226bdf "Location: /finn/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojsp/gojs"..., e = 0x8f9226fe6 ""}, {b = 0x0, e = 0x0}, { b = 0x8f9226fe7 "Content-Type: text/plain", e = 0x8f9226fff ""}, { b = 0x0, e = 0x0} }, hdf = '\0' , nhd = 12} }}} This happened after reducing obj.workspace from 4K to 2K, so it might be an object that is too big? It would be very nice to be able to log the objects that are too big. The one I see here in *hp seems to be have bogus Location field, and should be fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 18 15:52:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 18 Apr 2008 15:52:07 -0000 Subject: [Varnish] #229: Updated munin plugins for Varnish hitrate/cachehitratio Message-ID: <052.e51d21cba3b4229abff0051e45686332@projects.linpro.no> #229: Updated munin plugins for Varnish hitrate/cachehitratio -------------------------+-------------------------------------------------- Reporter: anders | Owner: des Type: enhancement | Status: new Priority: normal | Milestone: Component: munin | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Please update my Varnish hitrate/cachehitratio plugins, as they only support Varnish 1.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 18 18:57:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 18 Apr 2008 18:57:26 -0000 Subject: [Varnish] #230: Set bereq.host = backend.host if backend host is domain name (instead of ip address) Message-ID: <050.f38bc564612b70770d5cc97096c8e88b@projects.linpro.no> #230: Set bereq.host = backend.host if backend host is domain name (instead of ip address) ----------------------+----------------------------------------------------- Reporter: runa | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- When a backend host is specified using a domain name (instead of an ip addr) varnish should automatically set the Host header of the Backend request to that hostname. Currently this is needed: {{{ backend thumbs { .host = "thumbs.foo.com"; .port = "80"; } if (req.url ~ "^/thumbs/"){ set req.backend = thumbs; set req.http.host = "thumbs.foo.com";#this should be done automatically } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Apr 19 06:48:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 19 Apr 2008 06:48:56 -0000 Subject: [Varnish] #228: Varnish crashes on assert error in Tcheck In-Reply-To: <052.1ea25d5ad449e0967addbfbb0d6bc81a@projects.linpro.no> References: <052.1ea25d5ad449e0967addbfbb0d6bc81a@projects.linpro.no> Message-ID: <061.3a9b1605b2283b3ffd797fa738c549a7@projects.linpro.no> #228: Varnish crashes on assert error in Tcheck -----------------------------------------------+---------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: varnish crash assert error Tcheck | -----------------------------------------------+---------------------------- Comment (by anders): This happened again, however after running for a few hours: {{{ Child said (2, 3330): <> Child said (2, 3330): << Condition((t.b) != 0) not true.>> Child said (2, 3330): << errno = 54 (Connection reset by peer)>> /: write failed, filesystem is full }}} Unfortunately the core-dump filled the filesystem, so I could not get a useful backtrace. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 21 06:35:19 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Apr 2008 06:35:19 -0000 Subject: [Varnish] #227: Abstract the vca_pipes usage for alternative implementations In-Reply-To: <051.98dfc360d1fd1990ba30fdfcb9bc9300@projects.linpro.no> References: <051.98dfc360d1fd1990ba30fdfcb9bc9300@projects.linpro.no> Message-ID: <060.8cf3722290e4bdaa4383389f0d0bf592@projects.linpro.no> #227: Abstract the vca_pipes usage for alternative implementations -------------------------+-------------------------------------------------- Reporter: jesus | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I couldn't get your patch to apply so I stared a bit at it and found a less intrusive way to do it. I've maked the pass method optional, so that we do not need to duplicate the vca_pipe handling in the three existing acceptors. Reopen this ticket if that doesn't work for you. phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 21 06:54:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Apr 2008 06:54:08 -0000 Subject: [Varnish] #230: Set bereq.host = backend.host if backend host is domain name (instead of ip address) In-Reply-To: <050.f38bc564612b70770d5cc97096c8e88b@projects.linpro.no> References: <050.f38bc564612b70770d5cc97096c8e88b@projects.linpro.no> Message-ID: <059.200999f04746b53b3f65206dbf2e88cd@projects.linpro.no> #230: Set bereq.host = backend.host if backend host is domain name (instead of ip address) ----------------------+----------------------------------------------------- Reporter: runa | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: By default we do not overwrite the Host: header sent to the backend, unless the request did not have one to begin with, in which case we do in fact use the raw string from the backend definition as Host: content. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 21 07:05:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Apr 2008 07:05:01 -0000 Subject: [Varnish] #228: Varnish crashes on assert error in Tcheck In-Reply-To: <052.1ea25d5ad449e0967addbfbb0d6bc81a@projects.linpro.no> References: <052.1ea25d5ad449e0967addbfbb0d6bc81a@projects.linpro.no> Message-ID: <061.63c3ef17d87717a60d78a447ac81f5b4@projects.linpro.no> #228: Varnish crashes on assert error in Tcheck -----------------------------------------------+---------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: varnish crash assert error Tcheck | -----------------------------------------------+---------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: You have likely run out of workspace and varnish in general isn't too happy about that. How to handle lack of workspace is a slightly tricky issue, one option would be to allocate an "assistant workspace" on the fly with malloc(3). For now I think the diagnosis is: Don't Do That Then. Consider putting this on the post-2.0 wish-list. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 21 07:10:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Apr 2008 07:10:15 -0000 Subject: [Varnish] #215: regex matches sporadically on identical request In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no> Message-ID: <063.b493a6db734a196ac4c984b50f1a13f3@projects.linpro.no> #215: regex matches sporadically on identical request ----------------------+----------------------------------------------------- Reporter: onitunes | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 1.0.4 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): No, the dual-network thing shouldn't have anything to do with this. I'm very interested in the results you find in the vcl log, because I have nothing to go after right now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 21 18:17:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 21 Apr 2008 18:17:03 -0000 Subject: [Varnish] #221: Add a link for mod_extract_forwarded to FAQ In-Reply-To: <051.432c340d6e11a4a159772edb0bee1ce9@projects.linpro.no> References: <051.432c340d6e11a4a159772edb0bee1ce9@projects.linpro.no> Message-ID: <060.c3454630f796dbeffeb993346f4ee214@projects.linpro.no> #221: Add a link for mod_extract_forwarded to FAQ ---------------------------+------------------------------------------------ Reporter: nejko | Owner: perbu Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by perbu): * owner: des => perbu -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Apr 22 11:52:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 22 Apr 2008 11:52:48 -0000 Subject: [Varnish] #231: Assert error in VCL_recv_method() Message-ID: <050.fbea24182c47bf0fcc9c91aa22ab50f1@projects.linpro.no> #231: Assert error in VCL_recv_method() ----------------------+----------------------------------------------------- Reporter: Bart | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- With todays version of trunk, i get this assert error: {{{ Apr 22 10:30:03 andromeda varnishd: Child (32137) said <> Apr 22 10:30:03 andromeda varnishd: Child (32137) said <> Apr 22 10:30:03 andromeda varnishd: Child (32137) said <> Apr 22 10:30:03 andromeda varnishd: Child (32137) said << Condition(sp->handling & ((1 << 0)|(1 << 10)|(1 << 4)|(1 << 3)|(1 << 1))) not true.>> Apr 22 10:30:03 andromeda varnishd: Child (32143) said <> #0 0x00002aaaab3c607b in raise () from /lib/libc.so.6 #1 0x00002aaaab3c784e in abort () from /lib/libc.so.6 #2 0x00002aaaaabc5b60 in lbv_assert (func=0x43b010 "VCL_recv_method", file=0x43b067 "../../include/vcl_returns.h", line=39, cond=0x43b028 "sp->handling & ((1 << 0)|(1 << 10)|(1 << 4)|(1 << 3)|(1 << 1))", err=4) at assert.c:65 #3 0x000000000042043a in VCL_recv_method (sp=0x25b6008) at ../../include/vcl_returns.h:39 #4 0x000000000040da2e in cnt_recv (sp=0x25b6008) at cache_center.c:791 #5 0x000000000040e2f1 in CNT_Session (sp=0x25b6008) at steps.h:34 #6 0x0000000000419ea6 in wrk_do_one (w=0x42803cc0) at cache_pool.c:194 #7 0x000000000041a763 in wrk_thread (priv=0x25acc30) at cache_pool.c:247 #8 0x00002aaaaafedf1a in start_thread () from /lib/libpthread.so.0 #9 0x00002aaaab4605d2 in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () }}} The VCL code to reproduce this: {{{ backend default { .host = "192.168.100.20"; .port = "80"; } acl blacklisted { "192.168.100.100"; } sub vcl_recv { call vcl_recv_sentry; } sub vcl_recv_sentry { if (client.ip ~ blacklisted) { error 503 "Your IP has been blocked."; } if (req.request == "TRACE") { error 501 "TRACE request denied."; } } }}} If it matters, the system is a linux 2.6.18-53.1.13.el5xen (x86_64).[[BR]] The error only seems to occur when the checks are in a separate subroutine, they do work when placed in vcl_recv. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 23 15:21:09 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Apr 2008 15:21:09 -0000 Subject: [Varnish] #232: requests passed to backend without VCL processing Message-ID: <053.8e6f9aef97cb9922deee29568578312f@projects.linpro.no> #232: requests passed to backend without VCL processing ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 1.2 Severity: critical | Keywords: ----------------------+----------------------------------------------------- We are seeing very strange behaviour on a site. We are seeing this both with the 1.1.2 release and the current code from the 1.2 branch (at revision 2633). What is happening is that some requests are send directly to the backend without being rewritten as configure in vcl_recv. This appears to be happening on uncached (passed) requests. Even stranger: these requests are visible in the logs of an apache in front of varnish and in the logs of the backend server, but not in the varnischncsa or varnishlog output. Running varnishd in debug mode (with -d -d) does not show any errors or crashes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 23 15:25:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 23 Apr 2008 15:25:53 -0000 Subject: [Varnish] #232: requests passed to backend without VCL processing In-Reply-To: <053.8e6f9aef97cb9922deee29568578312f@projects.linpro.no> References: <053.8e6f9aef97cb9922deee29568578312f@projects.linpro.no> Message-ID: <062.3cf29ada631145d91b3978ebdab6d0c8@projects.linpro.no> #232: requests passed to backend without VCL processing ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 1.2 Severity: critical | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): Some more information: we are seeing this on a machine running Linux 2.6.24.2. We are using cookies for authentication, which triggers a pass rule in vcl_fetch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Apr 25 06:58:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 25 Apr 2008 06:58:13 -0000 Subject: [Varnish] #232: requests passed to backend without VCL processing In-Reply-To: <053.8e6f9aef97cb9922deee29568578312f@projects.linpro.no> References: <053.8e6f9aef97cb9922deee29568578312f@projects.linpro.no> Message-ID: <062.edbdb7c301c2e6acb9c3acc63482741c@projects.linpro.no> #232: requests passed to backend without VCL processing ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 1.2 Severity: critical | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: Enable the vcl_trace parameter and examine the varnislog output to see what exactly happens. There is nothing in your report that sounds like a Varnish bug at this point. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Apr 27 20:03:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 27 Apr 2008 20:03:05 -0000 Subject: [Varnish] #233: Backend responses with no Content-Length header Message-ID: <051.539ad76537ce0e22cfebd3de9e5f1443@projects.linpro.no> #233: Backend responses with no Content-Length header ----------------------+----------------------------------------------------- Reporter: afnid | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Keywords: Content-Length ----------------------+----------------------------------------------------- When the content-length header is missing, the length defaults to zero and the object does not get cached or sent to the client. If I set the state to pipe in the vcl.conf, the content get's passed to the client correctly. So why is there no Content-Length header? In my case I have a Java application server that does will dynamically generate a resized image from a master image based on the request, and using varnish to cache the resized images. When possible, the application server uses 'convert' to create the image and pass it through to the client, so the content length is not known ahead of time. If I buffer the images in my app-server and set a correct Content-Length header and everything works as expected. Viewing the image through a direct connection to the app server using firefox worked fine, so did viewing the image through a pound server that bypassed varnish. I have a work-around, just not as memory efficient as I would like, and if I was dealing with larger images, I would have to cache them to disk, and would defeat any reason to use varnish at all. Here is the tail-end of the log: 17 ObjProtocol c HTTP/1.1 17 ObjStatus c 200 17 ObjResponse c OK 17 ObjHeader c Server: Winstone Servlet Engine v0.9.10 17 ObjHeader c Expires: Wed, 30 Apr 2008 18:06:28 GMT 17 ObjHeader c Content-Type: image/jpeg 17 ObjHeader c Date: Sun, 27 Apr 2008 18:06:28 GMT 17 ObjHeader c X-Powered-By: Servlet/2.5 (Winstone/0.9.10) 17 TTL c 1336541393 RFC 259199 1209319588 1209319588 1209578788 0 0 17 VCL_call c fetch insert 17 Length c 0 17 VCL_call c deliver deliver 17 TxProtocol c HTTP/1.1 17 TxStatus c 200 17 TxResponse c OK 17 TxHeader c Server: Winstone Servlet Engine v0.9.10 17 TxHeader c Expires: Wed, 30 Apr 2008 18:06:28 GMT 17 TxHeader c Content-Type: image/jpeg 17 TxHeader c X-Powered-By: Servlet/2.5 (Winstone/0.9.10) 17 TxHeader c Date: Sun, 27 Apr 2008 18:06:28 GMT 17 TxHeader c X-Varnish: 1336541393 17 TxHeader c Age: 0 17 TxHeader c Via: 1.1 varnish 17 TxHeader c Connection: keep-alive 17 ReqEnd c 1336541393 1209319588.402075768 1209319588.478549719 0.005740166 0.076447487 0.000026464 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 28 03:35:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 28 Apr 2008 03:35:48 -0000 Subject: [Varnish] #234: Pass requests to PHP pages show blank page Message-ID: <058.326ed04f7347dc404ef389dc4efa6b62@projects.linpro.no> #234: Pass requests to PHP pages show blank page --------------------------+------------------------------------------------- Reporter: joshmarshall | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Keywords: --------------------------+------------------------------------------------- When a request is "pass"ed to the backend for PHP (e.g. I wanted to pass any hard refreshes to reload the cache) the resulting page is empty. Looking at the logs the size of the response from the webserver is significantly less but not zero. For example, the phpinfo() returns 45k of data to a normal request. Any requests "pass"ed to the backend return about 8k. Looking at the varnishlog the request from varnish to apache is HTTP/1.1 even though the request to varnish is HTTP/1.0 - maybe the request is allowing gzip? If so that would explain why the resulting page is empty. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Apr 28 07:56:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 28 Apr 2008 07:56:42 -0000 Subject: [Varnish] #234: Pass requests to PHP pages show blank page In-Reply-To: <058.326ed04f7347dc404ef389dc4efa6b62@projects.linpro.no> References: <058.326ed04f7347dc404ef389dc4efa6b62@projects.linpro.no> Message-ID: <067.662bbbbebe7786aae892e2c71a3475d4@projects.linpro.no> #234: Pass requests to PHP pages show blank page --------------------------+------------------------------------------------- Reporter: joshmarshall | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: wontfix Keywords: | --------------------------+------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: 1.1.2 does not support pass of POST requests, use pipe. -trunk does offer pass, allowing the connections to be reused. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Apr 30 21:27:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 30 Apr 2008 21:27:53 -0000 Subject: [Varnish] #235: Varnish Linux performance Message-ID: <057.939e5a37a22cf5a6a639947d809cd9b1@projects.linpro.no> #235: Varnish Linux performance -------------------------+-------------------------------------------------- Reporter: rafaelumann | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: performance -------------------------+-------------------------------------------------- Hi, ### Situation: We are using Quad Xeon 3Ghz HT servers in our production environment, and one varnish thread makes one CPU usage goes to 0% free. Process strace repeats: clock_gettime(CLOCK_MONOTONIC, {431276, 305144924}) = 0 epoll_wait(12, {{EPOLLIN, {u32=1371080556, u64=1371080556}}}, 1, 100) = 1 read(139, "GET /ads//i/bv1024/bv_ml07_v2.pn"..., 4095) = 403 epoll_ctl(12, EPOLL_CTL_DEL, 139, {0, {u32=0, u64=0}}) = 0 write(4002, "\317", 1) = 1 This process seems to be the responsible for distributing connections between threads and clean the timeout sockets. The problem possibly happens because this process tries to cleanup the timeout sockets each new connection. ### Kernel: Kernel: 2.6.18-53.el5PAE ### Solution: First we tried to use the same code used in varnish for freebsd (kqueue), that just searches for sockets with "dotimer=1" to clean timeout sockets, but it didn't work out because there are too many connections that would never be cleaned, and so too many sockets stayed opened. So, as a work around, I annexed a firsthand patch for test, that just add a "timeout counter" and cleans the timeout sockets every 60 seconds instead of cleaning it in every new connection received. We are using it here, and the performance is much better now. In the trunk or 1.1.2 version varnish doesn't go further than 4000 "Client requests received" with real traffic, but it goes much longer with Apache Benchmark traffic. While in our patched version we easily get to "8197.18" "Client requests received", without AB. Anyway, we don't think that this should be the final solution. Maybe a new thread to cleanup the timeout sockets will be a better solution. []s, Rafael Umann -- Ticket URL: Varnish The Varnish HTTP Accelerator From zegayews at ifi.uio.no Wed Apr 30 21:46:20 2008 From: zegayews at ifi.uio.no (zegayews at ifi.uio.no) Date: Wed, 30 Apr 2008 23:46:20 +0200 (CEST) Subject: few questions about varnish Message-ID: <1541.193.157.192.150.1209591980.squirrel@webmail.uio.no> Dear Sir/Madam, My name is Zegaye Seifu. I am a phd student at the university of Oslo. Currently I am doing a case study research on Varnish. I just would like to ask you the following 4 questions as you are a participant in the mailing list. Your prompt response to these questions is invaluable to what I am researching. Please take few minutes of your precious time and send your responses as soon as you can. 1)How do you come to use or work on Varnish? 2)What motivates you to contribute and interact in the mailing list? 3)What have you contributed to Varnish so far (like participiating in questioning, answering, bug fixing or giving patches)? Or if you have suggested any new ideas to the developers? 4)Anything that you would like to say about the software, the developers and the project organization in general? Any problems that you faced? Thank you for taking part in this study. If you would like to ask any questions or want to know about the study, you are most welcome. best regards, zegaye s.