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

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

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

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

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

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

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

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

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

Constification.


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

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

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

even can have any effect, but this will close it at a cost of one
extra kevent(2) every 100ms timer tick.

The (perceived) problem is that we have pending kqueue changes we
have not yet told the kernel about, then close a number of expired
FD's which might be instantly be recycled by the accept(2) over in
the other thread before we tell the kernel about the pending changes.

In that case, the kernel has no way of knowing that our changes
referred to the previous instance of the fd and not the new one.

The solution is to push the changes to the kernel before servicing
the timer.



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

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

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

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

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

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

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

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

threads.

Inspired by, but not expected to have any effect on #199


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

Add req.grace timer:  We only serve degraded mode objects if both the
request and the object's grace timers are satisfied.

Sort expiry list on obj.ttl + obj.grace and fiddle list if either changes.

In the hash lookup: record if any objects still in grace by obj.grace which
match our Vary: criteria (if any).

If no in-ttl object was found AND we have a graced object AND it is also
graced by req.grace AND it is being fetched: serve the graced object.

Otherwise, mark us as successor to the graced object while we fetch to
give others the chance.

When we unbusy the object, clean the magic pointers between the two
objects again.


To play with this you need at least:

	sub vcl_recv {
		set req.grace = 2m;
	}
	sub vcl_fetch {
		set obj.grace = 2m;
	}


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

The amount of time after obj.ttl this object can be served, provided
we are already trying to fetch a new copy.

Nothing inspects this variable yet.




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

of the objects on the objecthead to see if there is anything we can use.

This unpessimizes Vary: processing, where we previously might go to sleep
on a busy object despite the fact that we have a good and valid object
with the Vary: we desire.



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

particular object, because we cannot know beforehand if it will work out
for us, but sleeps on any one of potentially multiple busy objects becoming
ready for us to test against.

Therefore it makes sense to move the waiting list from the object to the
object head, as this both simplifies the code and eliminates a refhold on
busy objects.



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

With the advent of prefetch and degraded mode, the invariants of
objectheads change so that more than one object can be busy at any
one time.

Thus we can no longer assume that the busy object or one subsequent to
it, is the one we eventually desire, and we must start our search from
the front of the list again.

As an amusing sidenote: this eliminates the only "goto" in all of varnishd.



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

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

Debian packaging: Add an override to the lintian program to stop it from complaining about a false positive

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

Allow the user to disable specific acceptor mechanisms (e.g. do not
use epoll even though it is available).

Don't look for kqueue on systems where we know it doesn't work.

Bail if no acceptor mechanism was found.

Bail if no curses or ncurses was found.

Warn the user if SO_{RCV,SND}TIMEO are non-functional.


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

non-NULL port (e.g. ":80" which is a valid listening address).  In that
case, port should be free()d before returning.

Coverity Scan (CID:15)


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

sure (without more coffee) that the assumption is incorrect, but it makes
the code gratuitously non-transparent.

Coverity Scan (CID:8)


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

Coverty Scan (CID: 12-14,16)


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

Coverity Scan (CID:12)


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

Implicated in Coverity Scan (CID:12-16)



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

I don't think it is likely that they would, but some users are running
out of memory, so make it deterministic when it happens.

Noticed by Coverity Scan (CID: 4-6)



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

Make sure WRK_Flush() always resets w->niov so WRK_Write() does not
overrun the w->iov.

Because niov is right after iov in struct worker, it is hard to predict
what the effect of hitting this bug, but "core dump" is almost a given.

I don't think it has been likely to happen a lot however, as it would
require a full complement of HTTP headers or a very fragmented object.

Coverity Scan (CID:7)




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

too much, too little or just plain wrong.


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

still bits missing.


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

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

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