Conflicts:
	varnish-cache/bin/varnishd/varnishd.1

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

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

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

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

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

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

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

We had big plans for this originally, but none of them have materialized
because there are better ways to do those things.

For instance: why invent a lot of code to do prefetch, when wget(1) can
do the job already ?

Getting rid of vcl_timeout{} (and vcl_discard{}, see yesterdays commit)
simplifies the expiry codes locking and statekeeping significantly.



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

which outweigh the trouble it causes.

The original idea was to allow intelligent purging for space reason
in a size-constrained storage.

In practice, storage is seldomly constrained.

In the cases where it is, I have yet to see any documented benefit
from using vcl_discard{}, likely because of the fragmentation such
use would cause.

The implementation of the vcl_discard callback had severe costs in
code complexity (not fully unrolled by this commit) and locking
activity.

The straw that breaks the camels back, is that faithfull implementation
of vcl_discard{} in -spersistence would force us to relocate objects,
at a cost likely higher than picking them up from the backend.



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

we had to do was add a configure check for Mac OS X.


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

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

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

the version tag from the script that generated them.


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

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

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

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

Hopefully make it slightly more obvious we are just the provider of
the caching software in the default vcl_error.

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

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

Make sure to quiet the build process a bit, if we don't have git (or
this is not a git checkout).

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

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

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

We checked for EPOLLRDHUP before including sys/epoll.h which led to
compilation failures.

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

Fixes: #492



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

the first time.



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

do unnatural things to them.



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

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

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

Change the session handling logic, so that we hand any session back to
the herder, if the session_linger timer fires.

This means that a new session, will get a worker thread, but if nothing
happens within session_linger, it disembarks and lets the herder handle
the assembly of the request.

This actually simplifies the state engine, because the "again" state
(now renamed "wait) can also be used both for the first request.



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

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

It turns out that you could turn off ESI processing for subrequest and compeltely hose the response. Ignore the flag if you are in a subrequest.

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

workspace before we start using it in miss/pass/pipe.  



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

we short-cut through STP_AGAIN.

Expected to fix #487



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

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

doing an esi-include.

This should reduce the pressure on session workspace from nested
ESI includes considerably.



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

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

Instead of the acceptor thread doing it when reusing the session, have the
worker threads clean it out before putting it on the free list.

It could be, and probably was, argued that this is a performance
pessimization, but having thought much about it, I can't spot the
argument any longer, and certainly moving load off the acceptor thread
to the massively parallel worker threads is a good idea.



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

drop new connections summarily.

The parameter is session_max, default is 100k and the stats variable
client_drop counts how many sessions were dropped.

This is mostly an anti-DoS measure and your feedback and experience
with it is most welcome.




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

happening again:

We optimize session allocation, SES_New(), to minimize the amount
of locking the VCA_thread participates in with flip-flop lists of
free sessions: Allocate from one list, free to the other, flip lists
only when necessary.

This scheme only works if nobody but VCA_thread calls SES_New().

Background worker threads need dummy sessions and thus called into
SES_New() as well.

These calls all happen during startup, so they do in fact not mess
up the locking, but made mockery of a number of very stern comments.

Add SES_Alloc() for such "other uses" and enforce VCA_thread monopoly
with an assert.


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

There is probably a bug if an ESI subrequest turns ESI delivery back on -- add reminder so I can circle back and extend the test for it

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

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