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

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

Have the objcore point to the smp_object until fixup, so that we catch
any attempt to muck with it before that and so that we hve the address
available in Fixup.

Since we don't have the silos coordinates at fixup time, make the
smp_object point to the object.

Add callbacks for updating BAN and TTL information in the segment object
index.



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

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

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

that varnishd panic messages do not get quenched on the way down.



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

Fixes ticket #466



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

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

persistent storage.

We now pass the first, very rudimentary, test-case for persistent storage.



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

Clean up the hash generation around lookups a little bit.

Start a background thread on each persistent silo and stuff the
objects we find into the hash.

Mark these with a new objcore flag, and panic if we find this flag
on lookup.



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

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

own session and worker strutures all set up and ready.

Use this for the cache-timeout thread, instead of home-rolling it.



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

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

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

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

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

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

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

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

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

but didn't until now.



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

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

and exit the manager with a bitmap that tells what we saw underway.



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

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

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

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

bottleneck.

The original idea was anti-DoS measures along the lines of
	sub vcl_recv {
		if (client.bandwith > 1 mbit/s) {
			delay (100 ms);
		}
	}

But there are does not seem to be a pressing need, wherefore it has
never been completed, and even if it was, it would not solve the
problem across a server farm.



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

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

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

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

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

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

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

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

The original expectation was a ratio of 1:10 bereq:worker but once again
reality lets down data-less speculation.

It might have been true in a scenario where the majority of objects
bind the worker thread for significant time during delivery (ie:
ISOs over 28.8 modems) but that is not what happens in reality.

With objects rapidly delivered, backend contacts will size the worker
thread pool, since that is where they spend their time "out of the loop",
and consequenty, ratios of bereq/worker is much close to 1:1 than 1:10.



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

Any continous growth is now indications of leaks.



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

the same stevedore as the object was allocated from.

I am not sure why I didn't spot this back when we added multiple
storage ability, but it is surely dumb to have to find the object
structure on one disk and the body of the object on another, or
even several other, disks.

For persistence this changes from a performance issue to problem:
Any object spread over silos will be lost on restart.

Further changes to this stuff is therefore in the pipeline, but I
wanted this fix in a version that can be merged back to 2.0.x.





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

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

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

in a way that telnet clients don't get confused about:

Return WONT on to all DO or DONT and ignore everything else.



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