From nigel_varnish at unos.net Tue Nov 4 06:44:09 2008 From: nigel_varnish at unos.net (Nathan Uno) Date: Tue, 4 Nov 2008 00:44:09 -0600 Subject: varnishd and PAE Message-ID: Greetings! I'm running varnishd on PAE-enabled kernel (on PAE-capable hardware). At startup varnishd recognizes that this is a 32-bit operating system and restricts the cache size to 2GB. I *think* PAE should prevent me from running out of address space - is this a correct understanding? If so, is there a way for me to ask varnishd to ignore this limitation? (the source code seems to say "no") I've already tried using -s to be explicit, but recent versions of varnishd (I'm on 2.0.1) seem to enforce the limit regardless of the command-line options. I've thought about hacking the check out of storage_file.c and recompiling, but I'm not sure that's safe. I'd appreciate any insight anyone might have on this issue. Thanks very much, Nato -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at linpro.no Tue Nov 4 06:56:12 2008 From: perbu at linpro.no (Per Buer) Date: Tue, 04 Nov 2008 07:56:12 +0100 Subject: varnishd and PAE In-Reply-To: References: Message-ID: <490FF20C.3070903@linpro.no> Hi, Nathan Uno skrev: > I'm running varnishd on PAE-enabled kernel (on PAE-capable hardware). > At startup varnishd recognizes that this is a 32-bit operating system > and restricts the cache size to 2GB. I *think* PAE should prevent me > from running out of address space - is this a correct understanding? No. PAE makes it possible for you operating system to address more then 4Gb of memory. Unless there is is specific support in the application (there isn't) it will still be limited to a 32bit address space. > If so, is there a way for me to ask varnishd to ignore this limitation? No, sorry. 3 or 4 years ago it might have made sense to add the possibility to work around this limit (maybe by having several cache children each with 2GB) - but it is hardly relevant any more. There isn't much 32 bit hardware left these days. -- Per Buer http://linpro.no/ | http://redpill.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From tfheen at linpro.no Thu Nov 6 09:34:24 2008 From: tfheen at linpro.no (Tollef Fog Heen) Date: Thu, 06 Nov 2008 10:34:24 +0100 Subject: varnishd and PAE In-Reply-To: <490FF20C.3070903@linpro.no> (Per Buer's message of "Tue, 04 Nov 2008 07:56:12 +0100") References: <490FF20C.3070903@linpro.no> Message-ID: <87mygdyz8f.fsf@qurzaw.linpro.no> ]] Per Buer | > If so, is there a way for me to ask varnishd to ignore this limitation? | | No, sorry. 3 or 4 years ago it might have made sense to add the | possibility to work around this limit (maybe by having several cache | children each with 2GB) - but it is hardly relevant any more. There | isn't much 32 bit hardware left these days. You could run multiple varnish-es and have a hashing proxy like nginx in front. I do not recommend doing this -- 64 bit capable hardware is the norm today and you'll be better off just getting a new server and running a 64 bit OS on it. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From nigel_varnish at unos.net Thu Nov 6 14:50:46 2008 From: nigel_varnish at unos.net (Nathan Uno) Date: Thu, 6 Nov 2008 08:50:46 -0600 Subject: varnishd and PAE In-Reply-To: <87mygdyz8f.fsf@qurzaw.linpro.no> References: <490FF20C.3070903@linpro.no> <87mygdyz8f.fsf@qurzaw.linpro.no> Message-ID: Actually, this is *exactly* what I ended up doing as a test - using nginx with the upstream_hash module. However, the PAE hardware I'm on is 64-bit hardware, so it's just a matter of getting a 64-bit OS install and I'll be in good shape. Thanks for all the help! Nato On Thu, Nov 6, 2008 at 3:34 AM, Tollef Fog Heen wrote: > ]] Per Buer > > | > If so, is there a way for me to ask varnishd to ignore this limitation? > | > | No, sorry. 3 or 4 years ago it might have made sense to add the > | possibility to work around this limit (maybe by having several cache > | children each with 2GB) - but it is hardly relevant any more. There > | isn't much 32 bit hardware left these days. > > You could run multiple varnish-es and have a hashing proxy like nginx in > front. I do not recommend doing this -- 64 bit capable hardware is the > norm today and you'll be better off just getting a new server and > running a 64 bit OS on it. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at linpro.no Fri Nov 7 09:58:00 2008 From: tfheen at linpro.no (Tollef Fog Heen) Date: Fri, 07 Nov 2008 10:58:00 +0100 Subject: Hardware Load Balancer problem In-Reply-To: <03ff01c93ba5$79cb50a0$7801a8c0@hitchcock> (Scott Persinger's message of "Fri, 31 Oct 2008 15:05:02 -0700") References: <03ff01c93ba5$79cb50a0$7801a8c0@hitchcock> Message-ID: <87r65nuac7.fsf@qurzaw.linpro.no> ]] "Scott Persinger" | In the past, as soon as we took down apache on one of our servers, the | load balancer would detect it and route all traffic to the other | servers. | | However, since we started running varnish, the load balancer doesn't | seem to detect that a server is down, and so it keeps sending traffic | even after varnish has quit. What kind of checking does the load balancer do? Just a TCP connect or a complete GET? Also, if Varnish has quit, it should not receive connections at all.. the load balancer should get connection refused. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From pbruna at it-linux.cl Mon Nov 10 18:35:53 2008 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 10 Nov 2008 15:35:53 -0300 (CLST) Subject: Lost connections In-Reply-To: <25019485.24551226324031880.JavaMail.root@lisa.itlinux.cl> Message-ID: <348039.25291226342153856.JavaMail.root@lisa.itlinux.cl> Hi, Im running varnish with 3 load balance directors. The first again two windows IIS and the second against a couple of Apache servers, and the third against a couple of Glassfish Servers. The Apache and Glassfish are on the same machines. Yesterday Varnish staterd to behavie erractil, the sites stop responding and i had to restart varnish every 5 minutes for make it work again. I saw this in the log, i dont know exactly what it means: ######################################################## 147 TxRequest b GET 147 TxURL b /fcgi-bin/mapserv?map=/var/www/mapcity_2_0/map/chile_tiled.map&LAYERS=Oceano%2Craster_sudamerica%2CBoundaries%2CPark%2Curban%2CElevation%2CLakes%2CHidrography%2CEscaleras%2CCalles%2CAvenidas%2CAutopistas%2CCaminos%2Camerica%2Cbound_limit%2CLocality&FORMAT 147 TxProtocol b HTTP/1.1 147 TxHeader b Accept: */* 147 TxHeader b Referer: http://192.168.1.15:8080/cache/ 147 TxHeader b Accept-Language: es-cl 147 TxHeader b UA-CPU: x86 147 TxHeader b Accept-Encoding: gzip, deflate 147 TxHeader b User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2) 147 TxHeader b Host: mapa4.mapcity.com 147 TxHeader b X-Forwarded-For: 172.16.1.20 147 TxHeader b X-Varnish: 1045402604 147 TxHeader b X-Forwarded-For: 172.16.1.20 173 SessionClose c dropped 173 StatSess c (null) (null) 1226247930 0 0 0 0 0 0 0 231 SessionClose c dropped 231 StatSess c (null) (null) 1226247930 0 0 0 0 0 0 0 234 SessionClose c dropped 234 StatSess c (null) (null) 1226247930 0 0 0 0 0 0 0 235 SessionClose c dropped 235 StatSess c (null) (null) 1226247930 0 0 0 0 0 0 0 236 SessionClose c dropped 236 StatSess c (null) (null) 1226247930 0 0 0 0 0 0 0 236 SessionClose c dropped 236 StatSess c (null) (null) 1226247931 0 0 0 0 0 0 0 237 SessionClose c dropped 237 StatSess c (null) (null) 1226247931 0 0 0 0 0 0 0 238 SessionClose c dropped 238 StatSess c (null) (null) 1226247931 0 0 0 0 0 0 0 ################################################################## The lines with "SessionClose c dropper and null..." start repeating until i restarted Varnish. I know that some changes occurs on the Apache Web Servers, i dont know exactly what was changed. Also i got this in the log: ################################################################## 210 TxRequest b GET 210 TxURL b /fcgi-bin/mapserv?map=/var/www/mapcity_2_0/map/chile_tiled.map&LAYERS=Oceano%2Craster_sudamerica%2CBoundaries%2CPark%2Curban%2CElevation%2CLakes%2CHidrography%2CEscaleras%2CCalles%2CAvenidas%2CAutopistas%2CCaminos%2Camerica%2Cbound_limit%2CLocality&FORMAT 210 TxProtocol b HTTP/1.1 210 TxHeader b Host: mapa1.mapcity.com 210 TxHeader b User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-AR; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 210 TxHeader b Accept: image/png,image/*;q=0.8,*/*;q=0.5 210 TxHeader b Accept-Language: es-ar,es;q=0.8,en-us;q=0.5,en;q=0.3 210 TxHeader b Accept-Encoding: gzip,deflate 210 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 210 TxHeader b Referer: http://192.168.1.15:8080/cache/ 210 TxHeader b X-Forwarded-For: 172.16.1.20 210 TxHeader b X-Varnish: 1045397913 210 TxHeader b X-Forwarded-For: 172.16.1.20 ################################################################## I dont know if is ok the line: "Referer: http://192.168.1.15:8080/cache/", I also dont know where it came from. The configuration of Varnish is: ################################################################### director webcl_director round-robin { { .backend = { .host = "webcl1"; .port = "http"; } } { .backend = { .host = "webcl2"; .port = "http"; } } } director gfish_director round-robin { { .backend = { .host = "webcl1"; .port = "8080"; } } # { .backend = { .host = "webcl2"; .port = "8080"; } } } director winvc_director round-robin { { .backend = { .host = "winvc1"; .port = "http"; }} { .backend = { .host = "winvc2"; .port = "http"; }} } sub vcl_recv { if (req.http.host ~ "^(mapa.|encuestas.|encuestas.|desarrollo.|webservices.|belcorp.|webcl1.|accor.|webcl3.)?mapcity.(cl|com)$") { set req.backend = webcl_director; } if (req.http.host ~ "^(omd.|webservice2.|sodexho.)mapcity.(cl|com)$") { set req.backend = gfish_director; } if (req.http.host ~ "www.censodecomercio.cl") { set req.backend = gfish_director; } if (req.http.host ~ "^(beta.|clasico.|www.)?mapcity.(cl|com|pe)$") { set req.backend = winvc_director; } # Add a unique header containing the client address remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = client.ip; } ############################################################################## Any idea why Varnish stop responding? ------------------------------------ Patricio Bruna V. IT Linux Ltda. http://www.it-linux.cl Fono : (+56-2) 333 0578 - Chile Fono: (+54-11) 6632 2760 - Argentina M?vil : (+56-09) 8827 0342 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuno at unos.net Tue Nov 4 07:08:57 2008 From: nuno at unos.net (Nathan Uno) Date: Tue, 4 Nov 2008 01:08:57 -0600 Subject: varnishd and PAE In-Reply-To: <490FF20C.3070903@linpro.no> References: <490FF20C.3070903@linpro.no> Message-ID: Ok - that makes sense. Thanks for you help! Nato On 11/4/08, Per Buer wrote: > Hi, > > Nathan Uno skrev: > >> I'm running varnishd on PAE-enabled kernel (on PAE-capable hardware). >> At startup varnishd recognizes that this is a 32-bit operating system >> and restricts the cache size to 2GB. I *think* PAE should prevent me >> from running out of address space - is this a correct understanding? > > No. PAE makes it possible for you operating system to address more then > 4Gb of memory. Unless there is is specific support in the application > (there isn't) it will still be limited to a 32bit address space. > >> If so, is there a way for me to ask varnishd to ignore this limitation? > > No, sorry. 3 or 4 years ago it might have made sense to add the > possibility to work around this limit (maybe by having several cache > children each with 2GB) - but it is hardly relevant any more. There > isn't much 32 bit hardware left these days. > > > -- > Per Buer > http://linpro.no/ | http://redpill.se/ > > From nigel_varnish at unos.net Thu Nov 13 04:34:53 2008 From: nigel_varnish at unos.net (Nathan Uno) Date: Wed, 12 Nov 2008 22:34:53 -0600 Subject: varnishd appears to die if error is called from vcl_deliver Message-ID: If I call error from vcl_deliver varnishd appears to die. For example, the following (nonsensical) definition: sub vcl_deliver { error 503 "Badness"; } ... results in the following varnishlog output (which looks like a crash to me): 10 SessionOpen c 172.18.26.105 47478 :8081 10 ReqStart c 172.18.26.105 47478 1731927449 10 RxRequest c GET 10 RxURL c /PRIME/mtproxy/mtdata/14/2608/5704/1024 10 RxProtocol c HTTP/1.1 10 RxHeader c Accept-Encoding: identity 10 RxHeader c Host: 172.18.26.105:8081 10 RxHeader c Connection: close 10 RxHeader c User-agent: Python-urllib/2.4 10 VCL_call c recv 10 VCL_return c lookup 10 VCL_call c hash 10 VCL_return c hash 10 VCL_call c miss 10 VCL_return c fetch 12 BackendOpen b default 127.0.0.1 60316 127.0.0.1 8880 10 Backend c 12 default default 12 TxRequest b GET 12 TxURL b /PRIME/mtproxy/mtdata/14/2608/5704/1024 12 TxProtocol b HTTP/1.1 12 TxHeader b Accept-Encoding: identity 12 TxHeader b Host: 172.18.26.105:8081 12 TxHeader b User-agent: Python-urllib/2.4 12 TxHeader b X-Varnish: 1731927449 12 TxHeader b X-Forwarded-For: 172.18.26.105 0 CLI - Rd vcl.load boot ./vcl.1P9zoqAU.so 0 CLI - Wr 0 200 Loaded "./vcl.1P9zoqAU.so" as "boot" 0 CLI - Rd vcl.use boot 0 CLI - Wr 0 200 0 CLI - Rd start 0 Debug - "Acceptor is epoll" 0 CLI - Wr 0 200 0 WorkThread - 0x4485ec10 start 0 WorkThread - 0x4525fc10 start 0 WorkThread - 0x45c60c10 start 0 WorkThread - 0x46661c10 start 0 WorkThread - 0x47062c10 start 0 WorkThread - 0x47a63c10 start 0 WorkThread - 0x48464c10 start 0 WorkThread - 0x48e65c10 start 0 WorkThread - 0x49866c10 start 0 WorkThread - 0x4a267c10 start -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbruna at it-linux.cl Fri Nov 14 15:31:36 2008 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Fri, 14 Nov 2008 12:31:36 -0300 (CLST) Subject: Error in messages Message-ID: <31803510.31171226676696252.JavaMail.root@lisa.itlinux.cl> What means this error? Nov 14 15:09:47 balanceador varnishd[28858]: Child (28859) died signal=6 Nov 14 15:09:47 balanceador varnishd[28858]: Child (28859) Panic message: Missing errorhandling code in cnt_lookup(), cache_center.c line 606: Condition((p) != 0) not true. thread = (cache-worker)sp = 0x2ab2cff98008 { fd = 317, id = 317, xid = 1867396264, client = 200.113.161.41:63013, step = STP_LOOKUP, handling = HASH, ws = 0x2ab2cff98078 { overflow id = "sess", {s,f,r,e} = {0x2ab2cff987b0,,+8164,(nil),+8192}, }, worker = 0x2ab2ce001c00 { }, vcl = { srcname = { "/etc/varnish/default.vcl", "Default", }, }, }, ------------------------------------ Patricio Bruna V. IT Linux Ltda. http://www.it-linux.cl Fono : (+56-2) 333 0578 - Chile Fono: (+54-11) 6632 2760 - Argentina M?vil : (+56-09) 8827 0342 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel_varnish at unos.net Fri Nov 14 17:46:46 2008 From: nigel_varnish at unos.net (Nathan Uno) Date: Fri, 14 Nov 2008 11:46:46 -0600 Subject: varnishd appears to die if error is called from vcl_deliver In-Reply-To: References: Message-ID: This appears to be because include/vcl_returns.h (varnish 2.0.1) asserts that deliver shouldnt' return error: VCL_MET_MAC(deliver,DELIVER,(VCL_RET_RESTART|VCL_RET_DELIVER)) The documentation (man 7 vcl) indicates that error can be returned from vcl_deliver(): The vcl_deliver subroutine may terminate with one of the following key- words: error code [reason] Return the specified error code to the client and abandon the request. deliver Deliver the object to the client. It looks from the revision history that the change took place between r2341 and 4 and r3047. It appears to be a deliberate change because vcl_error() calls vcl_deliver(). So it appears there is a documentation bug, not a code bug. >) What I'm really interested in doing is forcing a document into cache without having that document delivered. I'm attempting to do this by defining a URL pattern to hint to varnish to fetch a document with a specific hash (i.e. not a hash specific to the particular request). vcl_hash() knows what to do and is working properly. vcl_fetch() knows what's going on and sets the infamous magic marker to tell vcl_deliver() what's up. I had thought that I could just then tell vcl_deliver() to generate an "error" with HTTP status code of 200 and bogus content and avoid having the actual cached document returned. This, however, seems not to be the case. Am I overlooking a much simpler way to accomplish my goal? Thanks, Nato On Wed, Nov 12, 2008 at 10:34 PM, Nathan Uno wrote: > If I call error from vcl_deliver varnishd appears to die. For example, the > following (nonsensical) definition: > > sub vcl_deliver { > error 503 "Badness"; > } > > ... results in the following varnishlog output (which looks like a crash to > me): > > 10 SessionOpen c 172.18.26.105 47478 :8081 > 10 ReqStart c 172.18.26.105 47478 1731927449 > 10 RxRequest c GET > 10 RxURL c /PRIME/mtproxy/mtdata/14/2608/5704/1024 > 10 RxProtocol c HTTP/1.1 > 10 RxHeader c Accept-Encoding: identity > 10 RxHeader c Host: 172.18.26.105:8081 > 10 RxHeader c Connection: close > 10 RxHeader c User-agent: Python-urllib/2.4 > 10 VCL_call c recv > 10 VCL_return c lookup > 10 VCL_call c hash > 10 VCL_return c hash > 10 VCL_call c miss > 10 VCL_return c fetch > 12 BackendOpen b default 127.0.0.1 60316 127.0.0.1 8880 > 10 Backend c 12 default default > 12 TxRequest b GET > 12 TxURL b /PRIME/mtproxy/mtdata/14/2608/5704/1024 > 12 TxProtocol b HTTP/1.1 > 12 TxHeader b Accept-Encoding: identity > 12 TxHeader b Host: 172.18.26.105:8081 > 12 TxHeader b User-agent: Python-urllib/2.4 > 12 TxHeader b X-Varnish: 1731927449 > 12 TxHeader b X-Forwarded-For: 172.18.26.105 > 0 CLI - Rd vcl.load boot ./vcl.1P9zoqAU.so > 0 CLI - Wr 0 200 Loaded "./vcl.1P9zoqAU.so" as "boot" > 0 CLI - Rd vcl.use boot > 0 CLI - Wr 0 200 > 0 CLI - Rd start > 0 Debug - "Acceptor is epoll" > 0 CLI - Wr 0 200 > 0 WorkThread - 0x4485ec10 start > 0 WorkThread - 0x4525fc10 start > 0 WorkThread - 0x45c60c10 start > 0 WorkThread - 0x46661c10 start > 0 WorkThread - 0x47062c10 start > 0 WorkThread - 0x47a63c10 start > 0 WorkThread - 0x48464c10 start > 0 WorkThread - 0x48e65c10 start > 0 WorkThread - 0x49866c10 start > 0 WorkThread - 0x4a267c10 start > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel_varnish at unos.net Fri Nov 14 20:46:10 2008 From: nigel_varnish at unos.net (Nathan Uno) Date: Fri, 14 Nov 2008 14:46:10 -0600 Subject: varnishd appears to die if error is called from vcl_deliver In-Reply-To: References: Message-ID: For the record... I also attempted to restart from vcl_deliver(), figuring I could check req.restart in vcl_recv() and make decisions there. Unfortunately, while the VCL_RET_RESTART behavior in vcl_fetch() is to restart the request at vcl_recv(), the VCL_RET_RESTART behavior for vcl_deliver() is to INCOMPL(), which involves an abort() and I'm back where I started. Any other ideas out there? Thanks, Nato On Fri, Nov 14, 2008 at 11:46 AM, Nathan Uno wrote: > This appears to be because include/vcl_returns.h (varnish 2.0.1) asserts > that deliver shouldnt' return error: > > VCL_MET_MAC(deliver,DELIVER,(VCL_RET_RESTART|VCL_RET_DELIVER)) > > The documentation (man 7 vcl) indicates that error can be returned from > vcl_deliver(): > > The vcl_deliver subroutine may terminate with one of the > following key- > words: > > error code [reason] > Return the specified error code to the client and > abandon the > request. > > deliver > Deliver the object to the client. > > It looks from the revision history that the change took place between r2341 > and 4 and r3047. It appears to be a deliberate change because vcl_error() > calls vcl_deliver(). So it appears there is a documentation bug, not a code > bug. >) > > What I'm really interested in doing is forcing a document into cache > without having that document delivered. I'm attempting to do this by > defining a URL pattern to hint to varnish to fetch a document with a > specific hash (i.e. not a hash specific to the particular request). > vcl_hash() knows what to do and is working properly. vcl_fetch() knows > what's going on and sets the infamous magic marker to tell vcl_deliver() > what's up. > > I had thought that I could just then tell vcl_deliver() to generate an > "error" with HTTP status code of 200 and bogus content and avoid having the > actual cached document returned. This, however, seems not to be the case. > > Am I overlooking a much simpler way to accomplish my goal? > > Thanks, > > Nato > > > On Wed, Nov 12, 2008 at 10:34 PM, Nathan Uno wrote: > >> If I call error from vcl_deliver varnishd appears to die. For example, >> the following (nonsensical) definition: >> >> sub vcl_deliver { >> error 503 "Badness"; >> } >> >> ... results in the following varnishlog output (which looks like a crash >> to me): >> >> 10 SessionOpen c 172.18.26.105 47478 :8081 >> 10 ReqStart c 172.18.26.105 47478 1731927449 >> 10 RxRequest c GET >> 10 RxURL c /PRIME/mtproxy/mtdata/14/2608/5704/1024 >> 10 RxProtocol c HTTP/1.1 >> 10 RxHeader c Accept-Encoding: identity >> 10 RxHeader c Host: 172.18.26.105:8081 >> 10 RxHeader c Connection: close >> 10 RxHeader c User-agent: Python-urllib/2.4 >> 10 VCL_call c recv >> 10 VCL_return c lookup >> 10 VCL_call c hash >> 10 VCL_return c hash >> 10 VCL_call c miss >> 10 VCL_return c fetch >> 12 BackendOpen b default 127.0.0.1 60316 127.0.0.1 8880 >> 10 Backend c 12 default default >> 12 TxRequest b GET >> 12 TxURL b /PRIME/mtproxy/mtdata/14/2608/5704/1024 >> 12 TxProtocol b HTTP/1.1 >> 12 TxHeader b Accept-Encoding: identity >> 12 TxHeader b Host: 172.18.26.105:8081 >> 12 TxHeader b User-agent: Python-urllib/2.4 >> 12 TxHeader b X-Varnish: 1731927449 >> 12 TxHeader b X-Forwarded-For: 172.18.26.105 >> 0 CLI - Rd vcl.load boot ./vcl.1P9zoqAU.so >> 0 CLI - Wr 0 200 Loaded "./vcl.1P9zoqAU.so" as "boot" >> 0 CLI - Rd vcl.use boot >> 0 CLI - Wr 0 200 >> 0 CLI - Rd start >> 0 Debug - "Acceptor is epoll" >> 0 CLI - Wr 0 200 >> 0 WorkThread - 0x4485ec10 start >> 0 WorkThread - 0x4525fc10 start >> 0 WorkThread - 0x45c60c10 start >> 0 WorkThread - 0x46661c10 start >> 0 WorkThread - 0x47062c10 start >> 0 WorkThread - 0x47a63c10 start >> 0 WorkThread - 0x48464c10 start >> 0 WorkThread - 0x48e65c10 start >> 0 WorkThread - 0x49866c10 start >> 0 WorkThread - 0x4a267c10 start >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimrub at finjan.com Tue Nov 18 16:43:39 2008 From: dimrub at finjan.com (Dmitry Rubinstein) Date: Tue, 18 Nov 2008 18:43:39 +0200 Subject: Using the test framework for other proxy products Message-ID: <50DD80D1E881B649AAD30E0FFEED4358ED3B6D@exmail1.finjan.com> Greetings! I came across Varnish in a search not for a caching proxy, but rather for a testing framework that would allow us to test our product (which is a security product that acts as an HTTP proxy). Is anyone known to have tried (and succeeded) using the Varnish test framework in order to test anything other than Varnish? What I have in mind is testing for compliance with various HTTP specifications mostly, including things as core to HTTP as pipelining, and as specific as various flavors of authentication. The necessary condition is, obviously, development of some sort of adapter that would allow setting up the other-than-varnish-proxy in accordance with the configuration being tested. -- Dmitry Rubinstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Nov 18 17:01:54 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 18 Nov 2008 17:01:54 +0000 Subject: Using the test framework for other proxy products In-Reply-To: Your message of "Tue, 18 Nov 2008 18:43:39 +0200." <50DD80D1E881B649AAD30E0FFEED4358ED3B6D@exmail1.finjan.com> Message-ID: <19574.1227027714@critter.freebsd.dk> In message <50DD80D1E881B649AAD30E0FFEED4358ED3B6D at exmail1.finjan.com>, "Dmitry Rubinstein" writes: >Is anyone known to >have tried (and succeeded) using the Varnish test framework in order to >test anything other than Varnish? Not that I know of, but I would be very happy to see the varnishtest tool developed into a more capable and general HTTP-proxy test tool. -- 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 mnot at yahoo-inc.com Thu Nov 20 05:38:11 2008 From: mnot at yahoo-inc.com (Mark Nottingham) Date: Wed, 19 Nov 2008 21:38:11 -0800 Subject: Using the test framework for other proxy products In-Reply-To: <50DD80D1E881B649AAD30E0FFEED4358ED3B6D@exmail1.finjan.com> References: <50DD80D1E881B649AAD30E0FFEED4358ED3B6D@exmail1.finjan.com> Message-ID: <1E8AF4CD-8433-4557-BAF9-6E03A7E6B0CB@yahoo-inc.com> You may be interested in: http://coad.measurement-factory.com/ Cheers, On 18/11/2008, at 8:43 AM, Dmitry Rubinstein wrote: > Greetings! > > I came across Varnish in a search not for a caching proxy, but > rather for a testing framework that would allow us to test our > product (which is a security product that acts as an HTTP proxy). Is > anyone known to have tried (and succeeded) using the Varnish test > framework in order to test anything other than Varnish? What I have > in mind is testing for compliance with various HTTP specifications > mostly, including things as core to HTTP as pipelining, and as > specific as various flavors of authentication. The necessary > condition is, obviously, development of some sort of adapter that > would allow setting up the other-than-varnish-proxy in accordance > with the configuration being tested. > > -- > Dmitry Rubinstein > > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev -- Mark Nottingham mnot at yahoo-inc.com From cklinger at novareto.de Thu Nov 20 13:34:54 2008 From: cklinger at novareto.de (Christian Klinger) Date: Thu, 20 Nov 2008 14:34:54 +0100 Subject: Problem with Backend Health Polling Message-ID: Hello Varnish, i try to work with loadbalancing and health checking. This is a part of my vcl file: If i start without the .porbe part all works fine. director cluster round-robin { { .backend = {.host = "10.10.60.192"; .port = "8080"; .probe = { .url = "/test.html"; .timeout = 5000 ms; .interval = 2s; .window=10; .threshold = 8; } } } If i start with this config i see this in varnishlog: 0 Backend_health - cluster Still sick 4--X-S--- 0 4 5 0.000000 0.000000 On the Web-Server i see this in the access log: 10.10.60.196 - Anonymous [20/Nov/2008:13:55:33 +0200] "GET /test.html HTTP/1.1" 200 228 "" "" and a wget to 10.10.60.192:8080/test.html works without any porblems. Maybe someone has an idea for me. Thanks in advance Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenxy.china at gmail.com Fri Nov 21 06:54:10 2008 From: chenxy.china at gmail.com (chen xiaoyong) Date: Fri, 21 Nov 2008 14:54:10 +0800 Subject: need a char ',' in mgt_param.c line 780 Message-ID: <7ab169e90811202254p7601a2c3u7e10890b23e3f438@mail.gmail.com> trunk Rev 3411 make error: mgt_param.c:781: error: expected '}' before numeric constant mgt_param.c:783: warning: braces around scalar initializer mgt_param.c:783: warning: (near initialization for 'parspec[37].def') mgt_param.c:783: warning: excess elements in scalar initializer mgt_param.c:783: warning: (near initialization for 'parspec[37].def') mgt_param.c:784: warning: excess elements in scalar initializer mgt_param.c:784: warning: (near initialization for 'parspec[37].def') mgt_param.c:784: warning: excess elements in scalar initializer mgt_param.c:784: warning: (near initialization for 'parspec[37].def') mgt_param.c:784: warning: excess elements in scalar initializer mgt_param.c:784: warning: (near initialization for 'parspec[37].def') mgt_param.c:789: warning: excess elements in scalar initializer mgt_param.c:789: warning: (near initialization for 'parspec[37].def') mgt_param.c:790: warning: excess elements in scalar initializer mgt_param.c:790: warning: (near initialization for 'parspec[37].def') mgt_param.c:791: warning: excess elements in scalar initializer mgt_param.c:791: warning: (near initialization for 'parspec[37].def') mgt_param.c:791: warning: excess elements in scalar initializer mgt_param.c:791: warning: (near initialization for 'parspec[37].def') mgt_param.c:792: warning: braces around scalar initializer mgt_param.c:792: warning: (near initialization for 'parspec[37].units') mgt_param.c:792: warning: excess elements in scalar initializer mgt_param.c:792: warning: (near initialization for 'parspec[37].units') mgt_param.c:793: warning: excess elements in scalar initializer mgt_param.c:793: warning: (near initialization for 'parspec[37].units') mgt_param.c:793: warning: excess elements in scalar initializer mgt_param.c:793: warning: (near initialization for 'parspec[37].units') mgt_param.c:793: warning: excess elements in scalar initializer mgt_param.c:793: warning: (near initialization for 'parspec[37].units') mgt_param.c:798: warning: excess elements in scalar initializer mgt_param.c:798: warning: (near initialization for 'parspec[37].units') -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter at linpro.no Fri Nov 21 07:23:47 2008 From: petter at linpro.no (Petter Knudsen) Date: Fri, 21 Nov 2008 08:23:47 +0100 Subject: need a char ',' in mgt_param.c line 780 In-Reply-To: <7ab169e90811202254p7601a2c3u7e10890b23e3f438@mail.gmail.com> References: <7ab169e90811202254p7601a2c3u7e10890b23e3f438@mail.gmail.com> Message-ID: <49266203.9070301@linpro.no> chen xiaoyong wrote: > trunk Rev 3411 > > make error: > mgt_param.c:781: error: expected '}' before numeric constant > mgt_param.c:783: warning: braces around scalar initializer Sorry about that. It's been fixed. Petter From robin.kunde at recoursive.com Fri Nov 21 19:58:02 2008 From: robin.kunde at recoursive.com (Robin Kunde) Date: Fri, 21 Nov 2008 14:58:02 -0500 Subject: make check results from ubuntu 8.10 and fedora core 9 Message-ID: I hope these help in any way. If you'd like me to re-run these test with certain parameters, I'd be happy to. Complete output attached. ubuntu 8.10 desktop (32 bit): 76 of 97 tests failed fedora core 9 server (64 bit): 1 of 97 tests failed -------------- next part -------------- A non-text attachment was scrubbed... Name: make_check_fc9.log Type: text/x-log Size: 126260 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make_check_ubuntu810.log Type: text/x-log Size: 75865 bytes Desc: not available URL: From cloude at instructables.com Fri Nov 21 23:01:32 2008 From: cloude at instructables.com (Cloude Porteus) Date: Fri, 21 Nov 2008 15:01:32 -0800 Subject: ESI JSP Tag Library? Message-ID: <4a05e1020811211501l4e4930dere1e8c66370ceecc6@mail.gmail.com> I want to start trying out the ESI feature, but I can't seem to find the JESI tag library. Is anyone using ESI within their local Java environment? Thanks for any help. best, cloude -- VP of Product Development Instructables.com Thanksgiving @ Instructables.com http://www.instructables.com/id/Stuffing/ http://www.instructables.co/id/Turkey_Recipe/ http://www.instructables.com/id/Pumpkin_Pie/ -------------- next part -------------- An HTML attachment was scrubbed... URL: