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

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

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

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

When there is no idle workerthread available, an incoming requests will
get queued until a thread becomes available.

We called this "overflow" because it overflowed the worker thread pool.

However, "overflow" gives the impression that the request is somehow
lost, which it is not.

"queued" gives a much more precise idea what goes on.



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

Rename 'purges' to 'bans' so that we can implement _real_ purges
also.

They really have been called 'bans' internally all the way through,
but for reasons now forgotten, we thought it would be too hard to
explain to people that purges were called bans in Varnish, so
the user-fronting side were named purges.

As it transpired, people were surprised that purges in varnish
did not free the storage right away, and various other kinds of
confusion also materialized.

The sky convinced me to implement real purges for efficiency
reasons when Vary is used, and of course now the name "purge"
was taken.

I'm sure people will curse about this change in the 2.x to 3.x
migration, but sooner or later it had to happen, and now it did.



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

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

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

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

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

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

to the client or not.



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

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

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

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

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

stevedore which matches the name exactly.



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

inside vcl_fetch()



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

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

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

this is much cleaner and does not demand a brand new python interpreter.



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

bytes and make the two stevedore space variables that type.



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

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

Be a total CPP-show-off-douche and make it very easy to add further
variables in the future, provided you can find the magic table.

Presently define three variables:


	REAL storage.$stevedore.free_space
	REAL storage.$stevedore.used_space
	BOOL storage.$stevedore.happy

Still debating if I should add a "SPACE" type to VCL, so that you
can write:
	if (storage.foobar.free_space < 1 GB) {...}

until I decide, it is a REAL, which is less than useful, because
we have no relational operators besides identity for REAL.



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

Presently, you can only test for the existence of a given stevedore,
but it gets a lot of support code in place.



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

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

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

This is a generalization of the trick we have used for things like
req.http.foobar, which can now also be used with other parts of
the namespace.

The plan is to use it for storage.disk1.free and similar.



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

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

We will no longer allow an object to be split across multiple
stevedores, because the necessary logic to allow control of which
stevedores allow this (malloc, file) vs. those that cannot tolerate
this (persistent) is just not worth the effort.

It is very dubious if there are any non-disadvantages to splitting
objects across stevedores in the first place.



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

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

Re-open #310 for 2.1.4 - trunk checks out fine.

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

the fixed location HTTP fields.

Prodded by: email from anordby, in re r4603



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

Fixes: #411


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

Fixes #794

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

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

Spotted by:	sky



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

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

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

in critbit to avoid a malloc in the locked path.

Move the waitinglist to its own structure in preparation for Big
Things Afoot which will give it more work to do.  This saves a
pointer in objhead on average, always a good thing.

Have the worker thread preallocate a waitinglist structure.



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