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

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

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

to see if they get reused ended up being named "acceptors", which is a bad
name because we have another thread which accepts new connections.

Rename the "fake" acceptors to "waiters"



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

it when we have used the object anyway.



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

which point to the objects.

Preallocate objcore with obj+objhead before we enter locked
hash sections.

Rename objcore.list to objcore.lru_list.

Eliminate obj.list and objhead.hashlen



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

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

- Changelog item to specfile for the rpm package
- Added html doc to the rpm package



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

In the future, this will be the bits of a cached object we cannot
realistically expect to stay paged out for any period of time.



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

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

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

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

addition of features to the ESI code.

The particular situation in #433 arises because a XML comment is not
bounded in length, the same way as an <esi:include...> element naturally
is.  This opens the window for trouble when large sections of XML is
commented out for some reason or another.

Bite the bullet and create a "storage-pointer" consisting of a pointer
to a storage segment and a pointer into that segment.

Add a main-loop which uses these pointers to walks over the entire
object, looking for stuff we care about, and handle each appropriately.

In addition to coping properly with the situation in #433, this code is
also close to 100 lines shorter and has a more logical structure.

The downside is that it is isn't quite as memory-access-alergic as the
previous version.  (I challenge anybody to measure the effect of this.)

Fixes: #433



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

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

tests cases.



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

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

I suspect a white-space cleanup got it at some point.



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

time sequencing of shmlog records for debugging purposes.



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

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

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

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

Add two test-cases for objects we should not esi parse.



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

the grim reaper has taken the object off the binheap to inspect it.



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

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

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

Fixes build failure


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

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

has closed the connection on us.

Fixes	#427



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

(The recent change that moved the compiler into its own subprocess
eliminates risk that a compiler error causes the management process
to die, you just do not get a sensible syntax error).

Fixes: #417



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

This hopefully finaly lays the sporadic
	assert(oe2->timer_when >= oe->timer_when);
panics to rest.



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

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

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

from VCL.

It is possible to instigate purges two ways from VCL now:

        sub vcl_recv {
		# Purge the req.url
                if (req.request == "PURGE") {
                        purge (req.url == req.url);
                        error 410;
                }

		# Take entire purge instruction from "Purge:" header
                if (req.request == "PURGESTR") {
                        purge ("" req.http.purge);
                        error 410;
                }

Testcase for this.



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

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

And add separate rxhdrs and rxbody primitives.

Submitted by: Yonatan Broza & Dmitry Rubinstein



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

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

the VCL compiler



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

of zero from serializing access to an object with very draconian
backend cache-control headers.

We could get far even with a one second TTL, but following our general
"there is a reason people put Varnish there in the first place" logic
we use the default_ttl parameter (default: 120 s) for this value.

If another value is desired, this can be set in vcl_fetch, even if it
looks somewhat counter-intuitive:

	sub vcl_fetch {
		if (obj.http.set-cookie) {
			set obj.ttl = 10s;
			pass;
		}
	}

Fixes #425



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

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

obviously should be freed.

This could fix 421 or make it much worse, but give us more info.



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