Only delete empty segments from front of list.

Preallocate the temporary object-index buffer at open time.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4278 d4fa192b-c00b-0410-8231-f00ffab90ce4

using malloc space.

Otherwise -spersistent would resurrect objects without their Vary
specifications.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4277 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4276 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4275 d4fa192b-c00b-0410-8231-f00ffab90ce4

Use consistent boundary check for end of segment.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4274 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4273 d4fa192b-c00b-0410-8231-f00ffab90ce4

Use an index into the segments object index instead of a pointer, to
avoid dealing with the temporary buffer used in the active segment.

Correctly count the various kinds of states objects can be in.

Only check the signature id inside the signature id field.

Don't load segments if the object index was not committed.

Reuse the temporary object index buffer.

Lock updates to ttl and ban, if in the active segment, to close
race against segment closing.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4272 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4271 d4fa192b-c00b-0410-8231-f00ffab90ce4

Reserve space for the objects entry in the index, when the object
is allocated.

Allow smaller than requested allocations for non-object allocations.

Attempt allocation from three segments, then give up.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4270 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4269 d4fa192b-c00b-0410-8231-f00ffab90ce4

Take due care to not confuse unloaded segments with empty segments
in this respect.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4268 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4267 d4fa192b-c00b-0410-8231-f00ffab90ce4

an object structure.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4266 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4265 d4fa192b-c00b-0410-8231-f00ffab90ce4

Increase the ID field in the shmlog records from 16 to 32 bits to cater
for 64k+ connections.

Both varnishd and libvarnishapi needs to be recompiled, but apps should
not need to.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4264 d4fa192b-c00b-0410-8231-f00ffab90ce4

attempting a reply.

Fixes #561



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4263 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4261 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4241 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4239 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4238 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4237 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4236 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4235 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4234 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4233 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4232 d4fa192b-c00b-0410-8231-f00ffab90ce4

progress.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4231 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4230 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4229 d4fa192b-c00b-0410-8231-f00ffab90ce4

some significant changes to the policy.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4228 d4fa192b-c00b-0410-8231-f00ffab90ce4

appropriate location for this code.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4227 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

what is leaking.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4225 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4223 d4fa192b-c00b-0410-8231-f00ffab90ce4

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

Fixes #549



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4221 d4fa192b-c00b-0410-8231-f00ffab90ce4