any object with heap_idx == 0.



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

object on deathrow.



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

for the client to reply on the internal CLI pipe.



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

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

varnishd can use to decide if a backend state can be shared between
multiple VCL programs.
 
Originally the idea was to calculate a strong hash over the tokens 
which define the backend.  

Considering the relatively short lengths of backend declarations
and the infrequency of comparisons, we have opted for an extremely
weak hash instead:  We simply output the space separted tokens as
a string.
 
The net change in code for simple backends is marginal, but for
complex backends this will be a lot simpler to implement.



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

cause Really Weird Problems if you really provoke it.

+++ Redo from start +++

LRU processing is only relevant for objects which are in the cache and
on the EXP binary heap so we merge the LRU functionality with the EXP
code in order to share locks and object reference counts.

Another thing we overlooked in the first implementation is that the VCL
callout for LRU should be able to examine the client information for
the session which tries to push stuff out, so that QoS/DoS issues can be
considered:

	sub vcl_dicard {
		if (client.bandwidth > 10 mb/s) {
			keep;
		}
	}

(which sort of indicates that "error" should be a legal action as well)

To enable this, pass the session into the stevedore when we try to
allocate space and temporarily substitute the target object for its
own object while we call vcl_discard().

The outcome of an attempt to make space can take three values, did,
didn't and couldn't.  In the latter case there is no point in trying
again and again, in particular if the cause is incurable, such as
the requested size being larger than the storage.   We still need to
handle failure to allocate storage for that case rather than core dump.

When looking for targets to nuke, we only consider objects on the
binheap which has reference count of 1, objects with higher reference
counts would not free space.

We take prospective targets off the binheap, but retain their
refcount, and tag them with a magic marker while we ponder their
destiny.

It is quite possible that another session could pick the object up
via the cache while we do so, and therefore attempts to update the
ttl or shift them in the lru chain must ignore objects which has
the magic marker.  If the object is kept, the updated ttl will
automatically take effect when we reinsert it in the binheap.



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

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

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

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

If we pass a HEAD request, we should not rewrite it to GET and not expect
a body either.



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

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

have in its cached nobjhead.



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

Close a supposedly rare memory leak: when we loose the race to create
an objhead, we need to free the hash-string we created before our
second attempt.



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

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

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

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

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

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

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

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

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

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

Don't panic if no backend.port is specified.



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

prototype


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

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

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

comparison fail.  This typically happens if a paticular header is
not present.


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

not for generating Content-Length: header.



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

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

a unnecessary connection timeout wait when the returned object does
not have a body.

Rework the "does this response have a body" logic to be more in line
with the RFC.



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

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

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

VBE_CheckFd(): Check that a filedescriptor is reusable.

Right now we simply poll it with a zero timeout, and if there are
any events, we can't reuse it.

This check may need refinement down the road.

One option would be to attempt to write a CRNL onto the fd and see
that it works.



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

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

combination.  This will be necessary in most if not all backend methods,
so it should be generic.



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

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

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

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

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

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