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

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

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

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

needs to be able to walk the list.  Doing it with callbacks gets to
byzantine.



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

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

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

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

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

Don't try to sort the subtests, it removes control from the user and
does not seem to do anything good.

Consolidate the string representation in the ban instead of having it
in each subtest.



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

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

Fix a problem in testcase c00013



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

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

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

we cannot do the accounting without it in a reasonably fast manner.

Keep track of how many fixed and unfixed objects we have in a segment.

Update the object directory when TTL or BAN pointer changes.

Add a testcase for TTL changes.

Don't walk the storage list when we delete a persistent object, just
decrement the segments object count.




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

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

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