From louis-philippe.gauthier at adgear.com Mon Jun 2 13:04:56 2014 From: louis-philippe.gauthier at adgear.com (Louis-Philippe Gauthier) Date: Mon, 2 Jun 2014 09:04:56 -0400 Subject: Varnish 3.0.5 memory leak? Message-ID: Hi, we've been experimenting with varnish 3.0.5 and we seem to be experiencing a memory leak. We're running varnish-3.0.5-r4 (from portage): http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-servers/varnish/varnish-3.0.5-r4.ebuild In the graph bellow you can see that the memory kept growing even after the malloc memory (12G) was full. I understand that there's a 1K overhead per object and that Varnish will use more then 12G, but it keeps growing even after the object space is full (now at 43.4G). [image: Inline image 2] box: $ uname -a Linux 3.8.13-gentoo #3 SMP Wed Jun 26 11:29:09 EDT 2013 x86_64 Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz GenuineIntel GNU/Linux configs: $ cat /etc/conf.d/varnishd # /etc/conf.d/varnishd VARNISHD="/usr/sbin/varnishd" VARNISHADM="/usr/bin/varnishadm" CONFIGFILE="/etc/varnish/default.vcl" VARNISHD_OPTS="-a :80 -p default_grace=600 -s malloc,12G -p thread_pool_max=2000 -p sess_timeout=120 -p thread_pool_min=100 -f $CONFIGFILE" rc_ulimit="-n 32786 -l 82000" $ cat /etc/varnish/default.vcl sub vcl_fetch { unset beresp.http.access-control-allow-origin; unset beresp.http.cache-control; unset beresp.http.content-type; unset beresp.http.p3p; unset beresp.http.pragma; unset beresp.http.server; set beresp.do_stream = false; set beresp.http.Content-Type = "application/json"; set beresp.ttl = 12h; return (deliver); } sub vcl_recv { if (req.url ~ "^/seg\?") { set req.url = regsub(req.url, "^/seg\?", "/db/client/1/seg.json?adsafe_url="); } else if (req.url ~ "^/raw\?") { set req.url = regsub(req.url, "^/raw\?", "/db/client/1/itgrl.json?adsafe_url="); } else { error 404 "Nope"; } } backend default { .host = "localhost"; .port = "8080"; } varnishstat: $ varnishstat -1 client_conn 118007 1.43 Client connections accepted client_drop 0 0.00 Connection dropped, no sess/wrk client_req 2674303461 32451.20 Client requests received cache_hit 2581606982 31326.38 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 92696487 1124.82 Cache misses backend_conn 143901 1.75 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 0 0.00 Backend conn. too many backend_fail 113149 1.37 Backend conn. failures backend_reuse 92437824 1121.68 Backend conn. reuses backend_toolate 143808 1.75 Backend conn. was closed backend_recycle 92583388 1123.45 Backend conn. recycles backend_retry 44 0.00 Backend conn. retry fetch_head 0 0.00 Fetch head fetch_length 92583297 1123.45 Fetch with Length fetch_chunked 0 0.00 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 0 0.00 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 0 0.00 Fetch failed fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 0 0.00 Fetch no body (304) n_sess_mem 2193 . N struct sess_mem n_sess 1743 . N struct sess n_object 17035658 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 17036857 . N struct objectcore n_objecthead 17287988 . N struct objecthead n_waitinglist 1224 . N struct waitinglist n_vbc 21 . N struct vbc n_wrk 1225 . N worker threads n_wrk_create 4831 0.06 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_lqueue 0 0.00 work request queue length n_wrk_queued 97676 1.19 N queued work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 1 . N backends n_expired 1913697 . N expired objects n_lru_nuked 73634035 . N LRU nuked objects n_lru_moved 597753138 . N LRU moved objects losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 2670567550 32405.87 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 118079 1.43 Total Sessions s_req 2674303508 32451.20 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 92583297 1123.45 Total fetch s_hdrbytes 582930172361 7073536.86 Total header bytes s_bodybytes 447671320223 5432245.12 Total body bytes sess_closed 113192 1.37 Session Closed sess_pipeline 0 0.00 Session Pipeline sess_readahead 0 0.00 Session Read Ahead sess_linger 2674190310 32449.83 Session Linger sess_herd 1005183056 12197.34 Session herd shm_records 84088575128 1020368.59 SHM records shm_writes 3867468359 46929.60 SHM writes shm_flushes 3637 0.04 SHM flushes due to overflow shm_cont 47998203 582.43 SHM MTX contention shm_cycles 28175 0.34 SHM cycles through buffer sms_nreq 113190 1.37 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 47426610 . SMS bytes allocated sms_bfree 47426610 . SMS bytes freed backend_req 92566803 1123.25 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_ban 1 . N total active bans n_ban_gone 1 . N total gone bans n_ban_add 1 0.00 N new bans added n_ban_retire 0 0.00 N old bans deleted n_ban_obj_test 0 0.00 N objects tested n_ban_re_test 0 0.00 N regexps tested against n_ban_dups 0 0.00 N duplicate bans removed hcb_nolock 2665700150 32346.80 HCB Lookups without lock hcb_lock 91663289 1112.28 HCB Lookups with lock hcb_insert 91656230 1112.20 HCB Inserts esi_errors 0 0.00 ESI parse errors (unlock) esi_warnings 0 0.00 ESI parse warnings (unlock) accept_fail 0 0.00 Accept failures client_drop_late 0 0.00 Connection dropped late uptime 82410 1.00 Client uptime dir_dns_lookups 0 0.00 DNS director lookups dir_dns_failed 0 0.00 DNS director failed lookups dir_dns_hit 0 0.00 DNS director cached lookups hit dir_dns_cache_full 0 0.00 DNS director full dnscache vmods 0 . Loaded VMODs n_gzip 0 0.00 Gzip operations n_gunzip 0 0.00 Gunzip operations sess_pipe_overflow 0 . Dropped sessions due to session pipe overflow LCK.sms.creat 1 0.00 Created locks LCK.sms.destroy 0 0.00 Destroyed locks LCK.sms.locks 339570 4.12 Lock Operations LCK.sms.colls 0 0.00 Collisions LCK.smp.creat 0 0.00 Created locks LCK.smp.destroy 0 0.00 Destroyed locks LCK.smp.locks 0 0.00 Lock Operations LCK.smp.colls 0 0.00 Collisions LCK.sma.creat 2 0.00 Created locks LCK.sma.destroy 0 0.00 Destroyed locks LCK.sma.locks 466325781 5658.61 Lock Operations LCK.sma.colls 0 0.00 Collisions LCK.smf.creat 0 0.00 Created locks LCK.smf.destroy 0 0.00 Destroyed locks LCK.smf.locks 0 0.00 Lock Operations LCK.smf.colls 0 0.00 Collisions LCK.hsl.creat 0 0.00 Created locks LCK.hsl.destroy 0 0.00 Destroyed locks LCK.hsl.locks 0 0.00 Lock Operations LCK.hsl.colls 0 0.00 Collisions LCK.hcb.creat 1 0.00 Created locks LCK.hcb.destroy 0 0.00 Destroyed locks LCK.hcb.locks 166286374 2017.79 Lock Operations LCK.hcb.colls 0 0.00 Collisions LCK.hcl.creat 0 0.00 Created locks LCK.hcl.destroy 0 0.00 Destroyed locks LCK.hcl.locks 0 0.00 Lock Operations LCK.hcl.colls 0 0.00 Collisions LCK.vcl.creat 1 0.00 Created locks LCK.vcl.destroy 0 0.00 Destroyed locks LCK.vcl.locks 4238534 51.43 Lock Operations LCK.vcl.colls 0 0.00 Collisions LCK.stat.creat 1 0.00 Created locks LCK.stat.destroy 0 0.00 Destroyed locks LCK.stat.locks 118472 1.44 Lock Operations LCK.stat.colls 0 0.00 Collisions LCK.sessmem.creat 1 0.00 Created locks LCK.sessmem.destroy 0 0.00 Destroyed locks LCK.sessmem.locks 118731 1.44 Lock Operations LCK.sessmem.colls 0 0.00 Collisions LCK.wstat.creat 1 0.00 Created locks LCK.wstat.destroy 0 0.00 Destroyed locks LCK.wstat.locks 35382849 429.35 Lock Operations LCK.wstat.colls 0 0.00 Collisions LCK.herder.creat 1 0.00 Created locks LCK.herder.destroy 0 0.00 Destroyed locks LCK.herder.locks 24026 0.29 Lock Operations LCK.herder.colls 0 0.00 Collisions LCK.wq.creat 2 0.00 Created locks LCK.wq.destroy 0 0.00 Destroyed locks LCK.wq.locks 2013141564 24428.37 Lock Operations LCK.wq.colls 0 0.00 Collisions LCK.objhdr.creat 91644710 1112.06 Created locks LCK.objhdr.destroy 74373301 902.48 Destroyed locks LCK.objhdr.locks 10786415928 130887.22 Lock Operations LCK.objhdr.colls 0 0.00 Collisions LCK.exp.creat 1 0.00 Created locks LCK.exp.destroy 0 0.00 Destroyed locks LCK.exp.locks 168213500 2041.18 Lock Operations LCK.exp.colls 0 0.00 Collisions LCK.lru.creat 2 0.00 Created locks LCK.lru.destroy 0 0.00 Destroyed locks LCK.lru.locks 166217433 2016.96 Lock Operations LCK.lru.colls 0 0.00 Collisions LCK.cli.creat 1 0.00 Created locks LCK.cli.destroy 0 0.00 Destroyed locks LCK.cli.locks 27464 0.33 Lock Operations LCK.cli.colls 0 0.00 Collisions LCK.ban.creat 1 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 168213537 2041.18 Lock Operations LCK.ban.colls 0 0.00 Collisions LCK.vbp.creat 1 0.00 Created locks LCK.vbp.destroy 0 0.00 Destroyed locks LCK.vbp.locks 0 0.00 Lock Operations LCK.vbp.colls 0 0.00 Collisions LCK.vbe.creat 1 0.00 Created locks LCK.vbe.destroy 0 0.00 Destroyed locks LCK.vbe.locks 514115 6.24 Lock Operations LCK.vbe.colls 0 0.00 Collisions LCK.backend.creat 1 0.00 Created locks LCK.backend.destroy 0 0.00 Destroyed locks LCK.backend.locks 185937951 2256.25 Lock Operations LCK.backend.colls 0 0.00 Collisions SMA.s0.c_req 315117125 3823.77 Allocator requests SMA.s0.c_fail 129837159 1575.50 Allocator failures SMA.s0.c_bytes 73800148989 895524.20 Bytes allocated SMA.s0.c_freed 60915247331 739173.00 Bytes freed SMA.s0.g_alloc 34071316 . Allocations outstanding SMA.s0.g_bytes 12884901658 . Bytes outstanding SMA.s0.g_space 230 . Bytes available SMA.Transient.c_req 12 0.00 Allocator requests SMA.Transient.c_fail 0 0.00 Allocator failures SMA.Transient.c_bytes 409344 4.97 Bytes allocated SMA.Transient.c_freed 409344 4.97 Bytes freed SMA.Transient.g_alloc 0 . Allocations outstanding SMA.Transient.g_bytes 0 . Bytes outstanding SMA.Transient.g_space 0 . Bytes available VBE.default(38.74.193.146,,8080).vcls 1 . VCL references VBE.default(38.74.193.146,,8080).happy 0 . Happy health probes Are we doing something stupid? We tried running Varnish 4.0.0-r1 but it was leaking threads so we downgraded... Thanks, Louis-Philippe Gauthier Team Lead, AdGear Trader -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image-1.png Type: image/png Size: 18251 bytes Desc: not available URL: From slink at schokola.de Mon Jun 2 14:47:28 2014 From: slink at schokola.de (Nils Goroll) Date: Mon, 02 Jun 2014 16:47:28 +0200 Subject: Varnish 3.0.5 memory leak? In-Reply-To: References: Message-ID: <538C8E80.3030406@schokola.de> On 02/06/14 15:04, Louis-Philippe Gauthier wrote: > > In the graph bellow you can see that the memory kept growing even after the > malloc memory (12G) was full. I understand that there's a 1K overhead per object > and that Varnish will use more then 12G, but it keeps growing even after the > object space is full (now at 43.4G). Actually this only accounts for the actual net overhead, but in practice there may be a substantial gross overhead in the order of a factor of 2x-3x due to fragmentation, depending on things like implementation details of the malloc you are using and the variations of object sizes. Nils From perbu at varnish-software.com Sat Jun 21 16:42:21 2014 From: perbu at varnish-software.com (Per Buer) Date: Sat, 21 Jun 2014 18:42:21 +0200 Subject: querysort added to std Message-ID: I took the boltsort vmod, ported it to 4.0 and put it into the std vmod as we talked about on the vdd. Tests passed. Someone with better eyes might still spot ugliness there, however. I'd be happy if someone looked at it. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gauthier.Delacroix at coreye.fr Mon Jun 23 08:07:48 2014 From: Gauthier.Delacroix at coreye.fr (Delacroix, Gauthier) Date: Mon, 23 Jun 2014 08:07:48 +0000 Subject: querysort added to std In-Reply-To: References: Message-ID: <5F530A9242E7F84F999DB40E0E268FBD45D2ABBB@mercalli.lild01.pictime.fr> I?ve used boltsort, but libvmod_querystring (https://github.com/Dridi/libvmod-querystring) includes cleaning features that boltsort misses. I don?t think std should include all filtering features from querystring, but the ?clean? method is a must have to optimize cache hit ratio. Gauthier Delacroix Administrateur Syst?me & R?seau Niveau 3 - Infrastructure & Produits gauthier.delacroix at coreye.fr tel : +33 (0)3 28 520 674 Parc de la Haute Borne 22, rue Herg? 59650 Villeneuve d'Ascq www.coreye.fr De : Per Buer [mailto:perbu at varnish-software.com] Envoy? : samedi 21 juin 2014 18:42 ? : Varnish Development Objet : querysort added to std I took the boltsort vmod, ported it to 4.0 and put it into the std vmod as we talked about on the vdd. Tests passed. Someone with better eyes might still spot ugliness there, however. I'd be happy if someone looked at it. -- [http://www.varnish-software.com/static/media/logo-email.png] Per Buer CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 [https://www.varnish-software.com/sites/default/files/redherring_2013_winner_sml.jpg] -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jun 23 08:13:33 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 23 Jun 2014 08:13:33 +0000 Subject: querysort added to std In-Reply-To: <5F530A9242E7F84F999DB40E0E268FBD45D2ABBB@mercalli.lild01.pictime.fr> References: <5F530A9242E7F84F999DB40E0E268FBD45D2ABBB@mercalli.lild01.pictime.fr> Message-ID: <78805.1403511213@critter.freebsd.dk> We talked a bit about what vmod_std should contain at the VDD in Stockholm and the consensus-ish-thingie was that generally useful facilities could go in there, as long as they don't drag in any 3rd party libraries. Functions for washing headers etc are certainly in that category. -- 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 fgsch at lodoss.net Mon Jun 23 09:31:48 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 10:31:48 +0100 Subject: Remaining conversions to std Message-ID: Hi, As discussed on the latest VDD I added .real (was .strtod) to the std vmod. There are 3 remaining conversions from our list: $Function REAL time2real(TIME) $Function INT time2integer(TIME) $Function TIME real2time(REAL) They are nothing more than returning their input: VCL_TIME __match_proto__(td_std_real2time) vmod_real2time(const struct vrt_ctx *ctx, VCL_REAL r) { (void)ctx; return (r); } Before I go ahead and add them are we happy with this or should we consider a different route like automagic promotion for certain types? f.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jun 23 09:35:42 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 23 Jun 2014 09:35:42 +0000 Subject: Remaining conversions to std In-Reply-To: References: Message-ID: <61632.1403516142@critter.freebsd.dk> In message , Federico Schwindt writes: >Hi, > >As discussed on the latest VDD I added .real (was .strtod) to the std vmod. >There are 3 remaining conversions from our list: > >$Function REAL time2real(TIME) >$Function INT time2integer(TIME) >$Function TIME real2time(REAL) > >They are nothing more than returning their input: > >VCL_TIME __match_proto__(td_std_real2time) >vmod_real2time(const struct vrt_ctx *ctx, VCL_REAL r) >{ > (void)ctx; > return (r); >} > >Before I go ahead and add them are we happy with this or should we consider >a different route like automagic promotion for certain types? I'm not sure I can see how that would work ? We don't have a way to force the conversion in VCL (ie: no casts) so I think it will have to be explicit -- 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 fgsch at lodoss.net Mon Jun 23 09:44:02 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 10:44:02 +0100 Subject: PATCH: stale-while-revalidate support Message-ID: Hi, After Per's recent post (1) and discussing it with him here's a patch that uses this to initialize beresp.grace. I've reused cache_rfc2616.c but perhaps this should be moved into its own file, i.e. cache_rfc5861.c. Comments? f.- 1. https://www.varnish-software.com/blog/grace-varnish-4-stale-while-revalidate-semantics-varnish -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- bin/varnishd/cache/cache.h | 3 ++- bin/varnishd/cache/cache_fetch.c | 2 ++ bin/varnishd/cache/cache_rfc2616.c | 32 +++++++++++++++++++++++++++++ bin/varnishtest/tests/b00043.vtc | 41 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 77 insertions(+), 1 deletion(-) diff --git a/bin/varnishd/cache/cache.h b/bin/varnishd/cache/cache.h index 2b10f59..759633f 100644 --- a/bin/varnishd/cache/cache.h +++ b/bin/varnishd/cache/cache.h @@ -1244,12 +1244,13 @@ char *WS_Snapshot(struct ws *ws); int WS_Overflowed(const struct ws *ws); void *WS_Printf(struct ws *ws, const char *fmt, ...) __printflike(2, 3); -/* rfc2616.c */ +/* cache_rfc2616.c */ void RFC2616_Ttl(struct busyobj *, double now); enum body_status RFC2616_Body(struct busyobj *, struct dstat *); unsigned RFC2616_Req_Gzip(const struct http *); int RFC2616_Do_Cond(const struct req *sp); void RFC2616_Weaken_Etag(struct http *hp); +void RFC5861_Stale(struct busyobj *); /* stevedore.c */ diff --git a/bin/varnishd/cache/cache_fetch.c b/bin/varnishd/cache/cache_fetch.c index a768170..c4ad0f1 100644 --- a/bin/varnishd/cache/cache_fetch.c +++ b/bin/varnishd/cache/cache_fetch.c @@ -348,6 +348,8 @@ vbf_stp_startfetch(struct worker *wrk, struct busyobj *bo) EXP_Clr(&bo->exp); RFC2616_Ttl(bo, now); + RFC5861_Stale(bo); + /* private objects have negative TTL */ if (bo->fetch_objcore->flags & OC_F_PRIVATE) bo->exp.ttl = -1.; diff --git a/bin/varnishd/cache/cache_rfc2616.c b/bin/varnishd/cache/cache_rfc2616.c index bb0a85e..3db28f6 100644 --- a/bin/varnishd/cache/cache_rfc2616.c +++ b/bin/varnishd/cache/cache_rfc2616.c @@ -365,3 +365,35 @@ RFC2616_Weaken_Etag(struct http *hp) http_Unset(hp, H_ETag); http_PrintfHeader(hp, "ETag: W/%s", p); } + +/* + * RFC5861 outlines a way to control the use of stale responses. + * We use this to initialize the grace period. + */ + +void +RFC5861_Stale(struct busyobj *bo) +{ + char *p; + const struct http *hp; + struct exp *expp; + + expp = &bo->exp; + + /* + * If we are not meant to cache this ignore any potential + * stale-while-revalidate values. + */ + if (expp->ttl <= 0.) + return; + + hp = bo->beresp; + + if (http_GetHdrField(hp, H_Cache_Control, + "stale-while-revalidate", &p) && p != NULL) { + if (*p == '-') + expp->grace = 0; + else + expp->grace = strtoul(p, NULL, 0); + } +} diff --git a/bin/varnishtest/tests/b00043.vtc b/bin/varnishtest/tests/b00043.vtc new file mode 100644 index 0000000..e5b5102 --- /dev/null +++ b/bin/varnishtest/tests/b00043.vtc @@ -0,0 +1,41 @@ +varnishtest "Test stale-while-revalidate" + +server s1 { + rxreq + txresp -hdr "Cache-Control: max-age=30, stale-while-revalidate=30" + rxreq + txresp -hdr "Cache-Control: max-age=0, stale-while-revalidate=30" + rxreq + txresp -hdr "Cache-Control: max-age=30, stale-while-revalidate=30" -hdr "Age: 40" + rxreq + txresp -status 500 -hdr "Cache-Control: max-age=30, stale-while-revalidate=30" +} -start + +varnish v1 -vcl+backend { + sub vcl_backend_response { + set beresp.http.grace = beresp.grace; + set beresp.http.ttl = beresp.ttl; + } +} -start + +client c1 { + txreq -url /1 + rxresp + expect resp.http.grace == 30.000 + expect resp.http.ttl == 30.000 + + txreq -url /2 + rxresp + expect resp.http.grace == 10.000 + expect resp.http.ttl == 0.000 + + txreq -url /3 + rxresp + expect resp.http.grace == 10.000 + expect resp.http.ttl == 0.000 + + txreq -url /4 + rxresp + expect resp.http.grace == 10.000 + expect resp.http.ttl == 0.000 +} -run From Gauthier.Delacroix at coreye.fr Mon Jun 23 09:58:00 2014 From: Gauthier.Delacroix at coreye.fr (Delacroix, Gauthier) Date: Mon, 23 Jun 2014 09:58:00 +0000 Subject: querysort added to std In-Reply-To: <78805.1403511213@critter.freebsd.dk> References: <5F530A9242E7F84F999DB40E0E268FBD45D2ABBB@mercalli.lild01.pictime.fr> <78805.1403511213@critter.freebsd.dk> Message-ID: <5F530A9242E7F84F999DB40E0E268FBD45D2ADDE@mercalli.lild01.pictime.fr> One thing that's missing in std is string to real conversion, to make it possible to control TTL randomization from header stored parameters. Gauthier Delacroix Administrateur Syst?me & R?seau Niveau 3 - Infrastructure & Produits gauthier.delacroix at coreye.fr tel?: +33 (0)3 28?520 674 Parc de la Haute Borne 22, rue Herg? 59650 Villeneuve d'Ascq www.coreye.fr -----Message d'origine----- De?: Poul-Henning Kamp [mailto:phk at phk.freebsd.dk] Envoy??: lundi 23 juin 2014 10:14 ??: Delacroix, Gauthier Cc?: Varnish Development Objet?: Re: querysort added to std We talked a bit about what vmod_std should contain at the VDD in Stockholm and the consensus-ish-thingie was that generally useful facilities could go in there, as long as they don't drag in any 3rd party libraries. Functions for washing headers etc are certainly in that category. -- 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 fgsch at lodoss.net Mon Jun 23 10:03:55 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 11:03:55 +0100 Subject: Remaining conversions to std In-Reply-To: <61632.1403516142@critter.freebsd.dk> References: <61632.1403516142@critter.freebsd.dk> Message-ID: I was thinking we edit the expression in vcc instead of erroring with "Wrong argument type" if formats don't match. Allowed conversions would be: TIME to REAL and INT REAL to TIME and INT INT to TIME and REAL I believe it would be relatively easy but do we want it? On Mon, Jun 23, 2014 at 10:35 AM, Poul-Henning Kamp wrote: > In message GZ-6geSA at mail.gmail.com> > , Federico Schwindt writes: > > >Hi, > > > >As discussed on the latest VDD I added .real (was .strtod) to the std > vmod. > >There are 3 remaining conversions from our list: > > > >$Function REAL time2real(TIME) > >$Function INT time2integer(TIME) > >$Function TIME real2time(REAL) > > > >They are nothing more than returning their input: > > > >VCL_TIME __match_proto__(td_std_real2time) > >vmod_real2time(const struct vrt_ctx *ctx, VCL_REAL r) > >{ > > (void)ctx; > > return (r); > >} > > > >Before I go ahead and add them are we happy with this or should we > consider > >a different route like automagic promotion for certain types? > > I'm not sure I can see how that would work ? > > We don't have a way to force the conversion in VCL (ie: no casts) so > I think it will have to be explicit > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Mon Jun 23 10:06:24 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 11:06:24 +0100 Subject: querysort added to std In-Reply-To: <5F530A9242E7F84F999DB40E0E268FBD45D2ADDE@mercalli.lild01.pictime.fr> References: <5F530A9242E7F84F999DB40E0E268FBD45D2ABBB@mercalli.lild01.pictime.fr> <78805.1403511213@critter.freebsd.dk> <5F530A9242E7F84F999DB40E0E268FBD45D2ADDE@mercalli.lild01.pictime.fr> Message-ID: That was added yesterday :) On Mon, Jun 23, 2014 at 10:58 AM, Delacroix, Gauthier < Gauthier.Delacroix at coreye.fr> wrote: > One thing that's missing in std is string to real conversion, to make it > possible to control TTL randomization from header stored parameters. > > Gauthier Delacroix > Administrateur Syst?me & R?seau > Niveau 3 - Infrastructure & Produits > gauthier.delacroix at coreye.fr > tel : +33 (0)3 28 520 674 > Parc de la Haute Borne > 22, rue Herg? > 59650 Villeneuve d'Ascq > www.coreye.fr > > > -----Message d'origine----- > De : Poul-Henning Kamp [mailto:phk at phk.freebsd.dk] > Envoy? : lundi 23 juin 2014 10:14 > ? : Delacroix, Gauthier > Cc : Varnish Development > Objet : Re: querysort added to std > > > We talked a bit about what vmod_std should contain at the VDD in Stockholm > and the consensus-ish-thingie was that generally useful facilities could go > in there, as long as they don't drag in any 3rd party libraries. > > Functions for washing headers etc are certainly in that category. > > -- > 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. > > > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jun 23 10:07:03 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 23 Jun 2014 10:07:03 +0000 Subject: Remaining conversions to std In-Reply-To: References: <61632.1403516142@critter.freebsd.dk> Message-ID: <90034.1403518023@critter.freebsd.dk> In message , Federico Schwindt writes: >--f46d044402f401155b04fc7df6fc >Content-Type: text/plain; charset=UTF-8 > >I was thinking we edit the expression in vcc instead of erroring with >"Wrong argument type" if formats don't match. >Allowed conversions would be: > >TIME to REAL and INT >REAL to TIME and INT >INT to TIME and REAL > >I believe it would be relatively easy but do we want it? The point here is that you have no way to ask for REAL variable in the first place, so how will you trigger the conversion ? I'd rather stick with the current (simple) rule that the only implicit conversions are to STRING, everything else must be commanded. -- 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 perbu at varnish-software.com Mon Jun 23 10:12:00 2014 From: perbu at varnish-software.com (Per Buer) Date: Mon, 23 Jun 2014 12:12:00 +0200 Subject: PATCH: stale-while-revalidate support In-Reply-To: References: Message-ID: On Mon, Jun 23, 2014 at 11:44 AM, Federico Schwindt wrote: > Hi, > > After Per's recent post (1) and discussing it with him here's a patch that > uses this to initialize beresp.grace. > I've reused cache_rfc2616.c but perhaps this should be moved into its own > file, i.e. cache_rfc5861.c. > Comments? > > RFC5861 ads two subheaders to Cache-control, stale-while-revalidate and stale-while-error. I think it makes sense to parse these in Varnish because it is much more convenient to have the backend issue the policy on each response, instead of having lots and lots of VCL. The semantics would be to parse both stale-while-revalidate and stale-while-error, set beresp.grace to the biggest. The problematic part is delivery, where one would have to have a bit more logic in vcl_hit. So vcl_hit would maybe look something like this: if (std.healthy(req.backend_hint)) { # backend healthy. if (obj.ttl + obj.cachecontrol.stale-while-revalidate > 0s) { return(deliver); } else { return(fetch); } } else { # backend is not healthy, do stale-while-error if (obj.ttl + obj.cachecontrol.stale-while-error > 0s) { return(deliver); } else { return(fetch); } } One of the problems here is that the logic relies on a probe being active on the backend. In my experience the added complexity is worth it, a lot of the "low end" users out there have mental barriers writing VCL but have no problems adding a header or two to their PHP application. The stale-while-revalidate functionality has been in Squid for quite some time and I believe there is support for ATS as well. Nginx or Apache mod_proxy does not seem to have any support for this, but those aren't very ambitious proxies, imho. -- *Per Buer* CTO | Varnish Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Mon Jun 23 10:15:48 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 11:15:48 +0100 Subject: Remaining conversions to std In-Reply-To: <90034.1403518023@critter.freebsd.dk> References: <61632.1403516142@critter.freebsd.dk> <90034.1403518023@critter.freebsd.dk> Message-ID: In this case they will be just casts or we can have the expression edited to add the conversion. My only concern is that this will add several type X to type Y functions and we will have 2 different idioms, e.g. std.real() vs std.real2time(). The first assumes string, the other not. On Mon, Jun 23, 2014 at 11:07 AM, Poul-Henning Kamp wrote: > In message < > CAJV_h0ZYBgiT-rNuUgcsN7fOX4ENJ1L0wDcvGccDqn63fXxq_A at mail.gmail.com> > , Federico Schwindt writes: > >--f46d044402f401155b04fc7df6fc > >Content-Type: text/plain; charset=UTF-8 > > > >I was thinking we edit the expression in vcc instead of erroring with > >"Wrong argument type" if formats don't match. > >Allowed conversions would be: > > > >TIME to REAL and INT > >REAL to TIME and INT > >INT to TIME and REAL > > > >I believe it would be relatively easy but do we want it? > > The point here is that you have no way to ask for REAL variable > in the first place, so how will you trigger the conversion ? > > I'd rather stick with the current (simple) rule that the only > implicit conversions are to STRING, everything else must be > commanded. > > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Mon Jun 23 10:28:04 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 11:28:04 +0100 Subject: PATCH: stale-while-revalidate support In-Reply-To: References: Message-ID: I didn't add stale-while-error support on purpose. The RFC states this should be served after we got an error from the backend, not before, so I don't believe this fits into grace per se. YMMV. On Mon, Jun 23, 2014 at 11:12 AM, Per Buer wrote: > > > > On Mon, Jun 23, 2014 at 11:44 AM, Federico Schwindt > wrote: > >> Hi, >> >> After Per's recent post (1) and discussing it with him here's a patch >> that uses this to initialize beresp.grace. >> I've reused cache_rfc2616.c but perhaps this should be moved into its own >> file, i.e. cache_rfc5861.c. >> Comments? >> >> > RFC5861 ads two subheaders to Cache-control, stale-while-revalidate and > stale-while-error. I think it makes sense to parse these in Varnish because > it is much more convenient to have the backend issue the policy on each > response, instead of having lots and lots of VCL. > > The semantics would be to parse both stale-while-revalidate and > stale-while-error, set beresp.grace to the biggest. > > The problematic part is delivery, where one would have to have a bit more > logic in vcl_hit. So vcl_hit would maybe look something like this: > > if (std.healthy(req.backend_hint)) { > # backend healthy. > if (obj.ttl + obj.cachecontrol.stale-while-revalidate > 0s) { > return(deliver); > } else { > return(fetch); > } > } else { > # backend is not healthy, do stale-while-error > if (obj.ttl + obj.cachecontrol.stale-while-error > 0s) { > return(deliver); > } else { > return(fetch); > } > } > > One of the problems here is that the logic relies on a probe being active > on the backend. In my experience the added complexity is worth it, a lot of > the "low end" users out there have mental barriers writing VCL but have no > problems adding a header or two to their PHP application. The > stale-while-revalidate functionality has been in Squid for quite some time > and I believe there is support for ATS as well. Nginx or Apache mod_proxy > does not seem to have any support for this, but those aren't very ambitious > proxies, imho. > > > > > -- > *Per Buer* > CTO | Varnish Software > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Mon Jun 23 13:01:41 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 23 Jun 2014 14:01:41 +0100 Subject: Remaining conversions to std In-Reply-To: References: <61632.1403516142@critter.freebsd.dk> <90034.1403518023@critter.freebsd.dk> Message-ID: Ah, I see your point now. I will implement the functions discussed previously then. On Mon, Jun 23, 2014 at 11:15 AM, Federico Schwindt wrote: > In this case they will be just casts or we can have the expression edited > to add the conversion. > > My only concern is that this will add several type X to type Y functions > and we will have 2 different idioms, e.g. std.real() vs std.real2time(). > The first assumes string, the other not. > > > On Mon, Jun 23, 2014 at 11:07 AM, Poul-Henning Kamp > wrote: > >> In message < >> CAJV_h0ZYBgiT-rNuUgcsN7fOX4ENJ1L0wDcvGccDqn63fXxq_A at mail.gmail.com> >> , Federico Schwindt writes: >> >--f46d044402f401155b04fc7df6fc >> >Content-Type: text/plain; charset=UTF-8 >> > >> >I was thinking we edit the expression in vcc instead of erroring with >> >"Wrong argument type" if formats don't match. >> >Allowed conversions would be: >> > >> >TIME to REAL and INT >> >REAL to TIME and INT >> >INT to TIME and REAL >> > >> >I believe it would be relatively easy but do we want it? >> >> The point here is that you have no way to ask for REAL variable >> in the first place, so how will you trigger the conversion ? >> >> I'd rather stick with the current (simple) rule that the only >> implicit conversions are to STRING, everything else must be >> commanded. >> >> >> -- >> 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slink at schokola.de Mon Jun 23 15:58:40 2014 From: slink at schokola.de (Nils Goroll) Date: Mon, 23 Jun 2014 17:58:40 +0200 Subject: abort() in vtc_log_VAS_Fail not reached Message-ID: <53A84EB0.1080006@schokola.de> I've just stumbled over this code in vtc_log.c:vtc_log() if (lvl > 0) return; if (lvl == 0) vtc_error = 1; if (pthread_self() != vtc_thread) pthread_exit(NULL); Opinions on adding an option to varnishtest to always abort() for assertion failures? this code goes back to commit 1ff88369bf3690020975f2250ebad4ada39d1e0d Author: Poul-Henning Kamp Date: Tue Oct 25 09:33:57 2011 +0000 Make it possible to mark http stuff "non-fatal". The thread (s%d/c%d) still dies, but it does not mark this as fatal with respect to the test as such. This is useful where varnishd shuts the connection on a backend prematurely, as part of the correct execution of a test. Fix a undue recursion problem with asserts in the vtc_log code. Nils From phk at phk.freebsd.dk Mon Jun 23 18:27:14 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 23 Jun 2014 18:27:14 +0000 Subject: abort() in vtc_log_VAS_Fail not reached In-Reply-To: <53A84EB0.1080006@schokola.de> References: <53A84EB0.1080006@schokola.de> Message-ID: <61065.1403548034@critter.freebsd.dk> In message <53A84EB0.1080006 at schokola.de>, Nils Goroll writes: >I've just stumbled over this code in vtc_log.c:vtc_log() > > if (lvl > 0) > return; > if (lvl == 0) > vtc_error = 1; > if (pthread_self() != vtc_thread) > pthread_exit(NULL); > >Opinions on adding an option to varnishtest to always abort() for assertion >failures? Good idea, send patch... -- 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 dridi.boukelmoune at zenika.com Tue Jun 24 09:45:20 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Tue, 24 Jun 2014 11:45:20 +0200 Subject: querysort added to std In-Reply-To: <78805.1403511213@critter.freebsd.dk> References: <5F530A9242E7F84F999DB40E0E268FBD45D2ABBB@mercalli.lild01.pictime.fr> <78805.1403511213@critter.freebsd.dk> Message-ID: On Mon, Jun 23, 2014 at 10:13 AM, Poul-Henning Kamp wrote: > > We talked a bit about what vmod_std should contain at the VDD in > Stockholm and the consensus-ish-thingie was that generally useful > facilities could go in there, as long as they don't drag in any > 3rd party libraries. The querystring module doesn't drag any dependency, so you could turn this into a native module and replace its `sort` function by the boltsort module's function. You would need to remove the Varnish 3 stuff (using cpp to deal with differences) and make it conform to your coding standards. Also this function uses the request's workspace (which is fine to me) but it's still not part of VRT despite ABI rules being relaxed with major/minor compatibility. I have plans for the querystring modules (new functions, and functions replaced by objects) but if you were to include it in the main tree, I would continue maintenance. I'd maintain the 3.0 vmod as I do today and send you relevant patches. > Functions for washing headers etc are certainly in that category. In this case I'd rather not put "everything" in the std module, like you did with the directors. The cookie module would be a good candidate too for instance. But I agree, that you'd need a significant amount of related functions to put them in their own module, and you probably don't want to include too many of them. Best Regards, Dridi > -- > 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. > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev From phk at phk.freebsd.dk Wed Jun 25 21:54:05 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 25 Jun 2014 21:54:05 +0000 Subject: handling failure in varnish Message-ID: <30219.1403733245@critter.freebsd.dk> One of the longest standing items we have on our wish list is a more graceful and more informative handling of "out of workspace" types of errors. I've been looking at that a bit and have started to mitigate the asserts that currently litter these cases. But I still having come up with a really good mental model of how to do it. My current leaning is that we will register these failures in a flag om the worker-thread (wrk->failed ?) so that we only have to look one place to see if we have already failed. ... because, we probably cannot just fail out of a VCL method because we cannot tell if mess up a VMOD that way, imagine something like: foobar.firstpart(); set req.http.foobar = foobar.makeheader(); foobar.secondpart(); If we just fail out of the VCL when the second line fails to get the necessary storage, we cannot know if the last line is necessary in order to clean properly up in the VMOD. In general I prefer all struct http.* operations should become no-ops after a failure, as a general "latch errors" principle, and obviously an VSL should be emitted that tells where things went haywire, in particular which workspace did so. Any ideas and insights are most welcome... -- 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 martin at varnish-software.com Thu Jun 26 10:17:02 2014 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 26 Jun 2014 12:17:02 +0200 Subject: handling failure in varnish In-Reply-To: <30219.1403733245@critter.freebsd.dk> References: <30219.1403733245@critter.freebsd.dk> Message-ID: I would consider a VMOD that requires calls into it in a specific order, and all of those calls having to be made for it not to blow up, to be a poorly written VMOD. When we have REQ_PRIV variables, it should be possible to write VMODs that don't have that requirement, and they will be able to clean up after themselves properly on those callbacks (which would be called even if wrk->failed). So I'm not sure the VMOD use case is the right reason to go for no-ops on workspace exhaustion. Actually as a VMOD writer, I think I would find the sudden no-op behavior more surprising than a VCL method ending early, and I fear we'll end up with VMODs that crash in strange ways on workspace exhaustion that way when the data it expected to be written inside of the same VMOD method wasn't there. I believe a strict exit from the VCL method before the next statement on an error condition would be preferable to the no-ops. Martin On 25 June 2014 23:54, Poul-Henning Kamp wrote: > > One of the longest standing items we have on our wish list is a more > graceful and more informative handling of "out of workspace" types of > errors. > > I've been looking at that a bit and have started to mitigate the > asserts that currently litter these cases. > > But I still having come up with a really good mental model of how > to do it. > > My current leaning is that we will register these failures in a > flag om the worker-thread (wrk->failed ?) so that we only have > to look one place to see if we have already failed. > > ... because, we probably cannot just fail out of a VCL method > because we cannot tell if mess up a VMOD that way, imagine > something like: > > foobar.firstpart(); > set req.http.foobar = foobar.makeheader(); > foobar.secondpart(); > > If we just fail out of the VCL when the second line fails to get > the necessary storage, we cannot know if the last line is necessary > in order to clean properly up in the VMOD. > > In general I prefer all struct http.* operations should become > no-ops after a failure, as a general "latch errors" principle, > and obviously an VSL should be emitted that tells where things > went haywire, in particular which workspace did so. > > Any ideas and insights are most welcome... > > -- > 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. > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Cell: +47 21 98 92 60 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From slink at schokola.de Thu Jun 26 19:47:46 2014 From: slink at schokola.de (Nils Goroll) Date: Thu, 26 Jun 2014 21:47:46 +0200 Subject: [PATCH] Streaming and Content-Length Message-ID: <53AC78E2.8090505@schokola.de> Hi, here's the first set of patches to address #1506. These do not cover Range-Requests yet, but these should be easy to address once we got this first set in. PATCH 1/4 is a prerequisite for the next patch. It contains what is required to test for premature shutdown of client connections by Varnish, handling for bodies longer than the available buffer in varnishtest plus a reduction of the number of read calls. PATCH 2/4 is the actual first fix for #1506 PATCH 3/4 adds an assertion to VBO_DerefBusyObj which I found helpful during testing. *pbo = NULL is delayed until after the test for the case pbo = &oc->busyobj PATCH 4/4 addresses races I have observed with objcore->busyobj bering set to NULL while being accessed Reviews appreciated Thanks, Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-http_rxchar-and-http_swallow_body-improvements-some-.patch Type: text/x-patch Size: 4878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Announce-the-Content-Length-from-the-backend-to-clie.patch Type: text/x-patch Size: 6076 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-If-the-busy-object-has-a-fetch_objcore-the-latter-sh.patch Type: text/x-patch Size: 1383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Hold-a-refernce-to-the-busy-object-while-accessing-i.patch Type: text/x-patch Size: 4713 bytes Desc: not available URL: From slink at schokola.de Thu Jun 26 20:01:57 2014 From: slink at schokola.de (Nils Goroll) Date: Thu, 26 Jun 2014 22:01:57 +0200 Subject: handling failure in varnish In-Reply-To: References: <30219.1403733245@critter.freebsd.dk> Message-ID: <53AC7C35.206@schokola.de> On 26/06/14 12:17, Martin Blix Grydeland wrote: > I believe a strict exit from the VCL method before the next statement on an > error condition would be preferable to the no-ops. my personal preference is to go even further than that. We have got several use cases in production where we really cannot allow ourselves to continue after WS exhaustion, so a relevant portion of our vcl follow the pattern set req.http.hdr = something; if (! req.http.hdr) { error 503 "bad thing happened here"; } At this point I hardly see a justification any more to silently ignore set operations, so I'd vote for an informative 503 (e.g. "workspace exhaustion at VCL line xxx") with similar handling for VCL functions. These errors should also be logged via stderr/syslog. The admin should have an option to replace the 503 body with synth content suitable for the general public - she could keep the original error for requests from dev/ops machines etc. My impression is that the current behavior makes varnish behavior appear obscure and hard to debug. Nils From slink at schokola.de Thu Jun 26 20:05:53 2014 From: slink at schokola.de (Nils Goroll) Date: Thu, 26 Jun 2014 22:05:53 +0200 Subject: handling failure in varnish In-Reply-To: <53AC7C35.206@schokola.de> References: <30219.1403733245@critter.freebsd.dk> <53AC7C35.206@schokola.de> Message-ID: <53AC7D21.4020707@schokola.de> On 26/06/14 22:01, Nils Goroll wrote: > with similar handling for VCL functions. This should have read "VMOD functions" From phk at phk.freebsd.dk Mon Jun 30 16:46:30 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 30 Jun 2014 16:46:30 +0000 Subject: [PATCH] Streaming and Content-Length In-Reply-To: <53AC78E2.8090505@schokola.de> References: <53AC78E2.8090505@schokola.de> Message-ID: <24652.1404146790@critter.freebsd.dk> In message <53AC78E2.8090505 at schokola.de>, Nils Goroll writes: >here's the first set of patches to address #1506. These do not cover >Range-Requests yet, but these should be easy to address once we got this first >set in. I've looked at this, but it touches on a number of related areas which I feel calls for a more general solution. The present issue is that we don't want to throw a perfectly good Content-Length from the backend away, if we can send it to the client while we are streaming an object still being fetched. But if we gzip, gunzip or ESI process the object, that C-L must not be passed to the client, since it will (may really) not match the data they get. The general issue is: Who controls the Content-Length header and what relation, if any, does have to obj->len. The answer to the first part is that we have to ask the fetch and delivery filters that question: nobody else knows, and in the future there may be such filters in vmods which we don't even know about, until we ask them. So the solution is to pile up the fetch-pipeline before calling vcl_backend_response{} and once v_b_r{] returns, we ask the pipeline if the C-L (if the backend sent one) is vetoed by the pipeline. For instance the gzip and gunzip VFP's would both veto it. Similarly, we have to ask the delivery pipeline, so that VDP::gunzip can veto the C-L because it will not match the result. That is going to be in 4.1 So far, so good, what about the second half of the question: obj->len ? If we get a uncompressed object from the backend and VFP::gzip it, we do actually know what C-L to send in case we VDP::gunzip it later, if only we had a place to store it in the meantime. This sounds like a pathological case, but it is actually indicative for a large class of things VMODs might do to objects, where a VFP and VDP will work in tandem, if only they could talk to each other. One very prominent example is ESI, where we produce a bytestring which tells us how to rip the object apart for ESI processing. Today we store that ESI string totally separate directly in struct object, because there is only that single "out-of-band" information at this time. But down the road, not sure when, I'll add a generalized facility so that VFP's can attach attributes to objects, and they will be appended to the obj.body encoded somehow. That will allow VFP:gzip and VFP:testgunzip to store the "other" length as an attribute which VDP:gunzip can retrive and emit as a C-L. And it will allow VFP::ESI to store two attributes, one with all the includes, and one with the instruction stream, so that we can fire of all the includes in parallel while we compose the ESI object. The caveat is that the attributes will only be available once the full object body has been fetched, so the VDP's either need to have a fall back strategy. For instance VDP::gunzip will just veto any C-L and fall back to chunked encoding if there is no attribute available with the C-L to use. This may or may not be in 4.1 -- 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.