- 29 Sep, 2009 3 commits
-
-
Poul-Henning Kamp authored
attempting a reply. Fixes #561 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4263 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
We still do not have the cleaner, so when we run out of space we simply exit the worker process with a message, the restart will blow away some segments and thus make some space for us. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4262 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4261 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 24 Sep, 2009 3 commits
-
-
Poul-Henning Kamp authored
Submitted by: "Jos I. Boumans" <jos@dwim.org> git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4242 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4241 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
because vcl_recv does "return(error);", force the status to 501. Fixes: #558 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4240 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 22 Sep, 2009 1 commit
-
-
Tollef Fog Heen authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4239 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 21 Sep, 2009 1 commit
-
-
Tollef Fog Heen authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4238 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 15 Sep, 2009 1 commit
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4237 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 14 Sep, 2009 1 commit
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4236 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 11 Sep, 2009 1 commit
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4235 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 08 Sep, 2009 5 commits
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4234 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4233 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4232 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
progress. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4231 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4230 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 04 Sep, 2009 3 commits
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4229 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
some significant changes to the policy. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4228 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
appropriate location for this code. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4227 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 03 Sep, 2009 1 commit
-
-
Poul-Henning Kamp authored
to fix the discrepancy in the object/objcore count they would otherwise represent. XXX: Not quite sure if they should also be counted as a subset of n_object to give people an easy way to access "total objects available in cache". Will decide this later. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4226 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 02 Sep, 2009 7 commits
-
-
Poul-Henning Kamp authored
what is leaking. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4225 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
and instead (ab)used the obj.* set. This allowed, amongst other things, the headers of cached objects to be munged by subsequent cache-hits. This was just as bad an idea as it sounds. The downside was, that we had to reserve object workspace for the potentially created headers, and this really bites, memory wise, if your content is many small objects. This commit allows, and sets obj_workspace to zero, allocating only as much space as is necessary for the actual headers after vcl_fetch() has returned. The downside is, without extra workspace, you can no longer change the content of obj.* string variables after the vcl_fetch() which instantiated the object. For now we still allow the obj_workspace to be set to reserve such space, but in all likelyhood, this ability will disappear in the future. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4224 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4223 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
busy cache entry or to ditch it. Ditch it as soon as we can, so we don't hold other clients on a busy objcore longer than necessary. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4222 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Fixes #549 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4221 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4220 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
replace a half-baked one in vtc.c with it. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4219 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 01 Sep, 2009 1 commit
-
-
Poul-Henning Kamp authored
expiry thread from moving objcores from one list to another. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4218 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 31 Aug, 2009 1 commit
-
-
Poul-Henning Kamp authored
I can tell FlexeLint to ignore them. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4217 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 28 Aug, 2009 3 commits
-
-
Poul-Henning Kamp authored
Add a parameter, so the worker thread gets forced to dump stats into the global pool for every N requests it serves. This should solve the problem where a wget(1) client does not show up in the stats, until the session ends. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4216 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Move most of the stat fields used in cache_center.c into the workers private stats, hopefully reducing the lock contention and stats precision at the same time. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4215 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Petter Knudsen authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4214 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 27 Aug, 2009 1 commit
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4213 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 26 Aug, 2009 4 commits
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4212 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
The cruical difference is that we can remove from a VLIST without having the head of the VLIST, which comes handy when expiring a non-instantiated object from a -spersistent stevedore. We flip the LRU list around, so that the frontmost element has not been accessed for the longest time, and simulate tail-inserts by putting a senteniel on the tail of the list. Presently the senteniel is a full objcore, which is a non-issue with few machines having more than a handful of stevedores, but once the persistent stevedore moves to per-segment LRU lists, this needs to be addressed, probably by wrapping the LRU linkage in a separate structure. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4211 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4210 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4209 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 24 Aug, 2009 1 commit
-
-
Kristian Lyngstøl authored
This allows us to put items on a blacklist for a specific backend based on the response it gave us. The basic syntax is (vcl_fetch): if (beresp.status == 500) { set beresp.saintmode = 20s; restart; } Health checks are modified accordingly, which means graced objects are used if no healthy backends are left to try. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4208 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 20 Aug, 2009 1 commit
-
-
Kristian Lyngstøl authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4207 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 19 Aug, 2009 1 commit
-
-
Poul-Henning Kamp authored
and try to push objects away from the tail end so that the list can be shortened. It won't work if your bans contains any req.* tests, because the lurker has no request to compare against. By default the lurker is disabled, you enable it by setting the 'ban_lurker_sleep' parameter to the amount of time the lurker should sleep between doing things. If it cannot do anything, it always sleeps for a second. NB: This feature is on probation, there is currently no guarantee it will end up in a future varnish release, it depends on the impact and usability. Feedback much anticipated. One of the quasi-nasty details of this feature, is the need to work against the lock-order in cache_hash.c, see details in comments for HSH_FindBan(). git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4206 d4fa192b-c00b-0410-8231-f00ffab90ce4
-