git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4290 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4289 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4288 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4287 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/branches/2.0@4286 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4285 d4fa192b-c00b-0410-8231-f00ffab90ce4

Kindly submitted by Rogério Schneider.

Fixes: #492



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4284 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/branches/2.0@4283 d4fa192b-c00b-0410-8231-f00ffab90ce4

Merge r4073: Be much more consistent about snapshotting session workspace when 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/branches/2.0@4282 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/branches/2.0@4281 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4068:
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

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

r4081:
I am stupid, missing '/'



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4280 d4fa192b-c00b-0410-8231-f00ffab90ce4

Put an upper limit on how many sessions we will allocate before we
just 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/branches/2.0@4260 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fix an inconsequential oversight in session management, and prevent it
from 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/branches/2.0@4259 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4258 d4fa192b-c00b-0410-8231-f00ffab90ce4

Add a miniature facility for starting a background thread with its
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/branches/2.0@4257 d4fa192b-c00b-0410-8231-f00ffab90ce4

Note that to use this for full effect, varnishd should be installed
unstripped.

r4058:
Also remember compat execinfo.h file.

r4059:
Tell autocrap about compat/execinfo.h

r4060:
Attempt to add a stack backtrace to the panic message.

r4061:
Spit out more information on panic

r4062:
Autocrap the dladdr() functions existence.

r4063:
More autocrappery.

r4064:
Comment out unneeded function.

r4065:
Pass a void* to Symbol_Lookup() to avoid stdint requirement on
common.h



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4256 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4255 d4fa192b-c00b-0410-8231-f00ffab90ce4

written by Maxim Sobolev <sobomax@FreeBSD.org>



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4254 d4fa192b-c00b-0410-8231-f00ffab90ce4

The object will not have a ban yet in the 2.0 branch, so revert the
cache_hash part of r4252.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4253 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4252 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4251 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4052:
Be more paranoid about backend responses, a response of:
        HTTP/1.1 1000\n\r\n\r
would panic us trying to find a suitable message for 1000.

Now we 503 the response instead.

Fixes #506

r4053:
Regression test for #506



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4250 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes #502



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4249 d4fa192b-c00b-0410-8231-f00ffab90ce4

r4046:
Change the way we close client sessions.

Previously we always used SO_LINGER to make sure that all queued data
got transmitted, no matter under which circumstances we closed the
client connection.

Change this so that SO_LINGER is only activated for orderly connection
closure (ie: "Connection: close" from client or error handling), in
all other cases (usually the client connecting on us, abandon any data
queued for transmission.

This _may_ reduce the tendency of worker threads to get hung up on
network failures a little bit.

r4047:
r4046 forgot to reset SO_LINGER for pipe handling which basically
broke pipehandling.

Fixes #505

r4183:
Disable SO_LINGER when we time out a connection due to sess_timeout,
so that we do not RST connections that have still not transmitted
their
data.

Since we were able to get the writev(2) to detach the socket, we
should
not end up sleeping in the close(2) either.

We still RST the socket for all error conditions.

Ideally I would still like to RST connections that have no outstanding
data after their sess_timeout, in order to avoid the 2*RTT+misc
timeouts delays associated with loosing a TCP socket for a client
that have gone to meet some other IP#.

In particular with load-balancers, this allows the load balancer to
declare the session dead right away, and reuse it for something more
productive.

Unfortunately, this lacks OS support in all presently released
OS'es: you cannot ask if a socket is done transmitting what you
asked it to.

FreeBSD-8.0 will have experimental support for this (FIONWRITE)
and I will revisit it in that context.


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4248 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4247 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4246 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes #494



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4245 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4244 d4fa192b-c00b-0410-8231-f00ffab90ce4

Thanks to "whocares" in the bts.

Fixes #455


git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4243 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4170 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4169 d4fa192b-c00b-0410-8231-f00ffab90ce4

backport changes from trunk that doesn't allocate transient objects from the store, this means all error requests from recv no longer go through the STV_allocator.

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4167 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4164 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4162 d4fa192b-c00b-0410-8231-f00ffab90ce4

Move the setting of the correct headers for ESI from ESI parsing time to delivery time. 
This is in anticipation for set req.esi = off; 

Allows you to turn off esi processing for a specific request using set req.esi = off even 
if the object has been esi processed -- this is useful if you have a cache heirarchy of 
varnish machines as well as debugging. 
Only change to processing is to store a copy of the attribute value instead of 
mangling to original. Committed from Oahu.



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4082 d4fa192b-c00b-0410-8231-f00ffab90ce4

fix for #498 -- if a return header overran the obj_workspace (but was small
enough to fit in sess_workspace) the header is dropped and an empty slot is put
in there -- rest of the code now detects this empty slot. It should probably
ask VLC what to do if a header is dropped



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4040 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4019 d4fa192b-c00b-0410-8231-f00ffab90ce4

Fixes ticket #466



git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4018 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4017 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/branches/2.0@4016 d4fa192b-c00b-0410-8231-f00ffab90ce4