- 20 May, 2009 1 commit
-
-
Poul-Henning Kamp authored
Fixes: #492 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4085 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 19 May, 2009 2 commits
-
-
Poul-Henning Kamp authored
the first time. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4084 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
do unnatural things to them. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4083 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 14 May, 2009 4 commits
-
-
Artur Bergman authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4081 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4080 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
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/varnish-cache@4079 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4078 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 13 May, 2009 1 commit
-
-
Artur Bergman authored
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/varnish-cache@4077 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 12 May, 2009 1 commit
-
-
Poul-Henning Kamp authored
workspace before we start using it in miss/pass/pipe. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4076 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 11 May, 2009 9 commits
-
-
Poul-Henning Kamp authored
we short-cut through STP_AGAIN. Expected to fix #487 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4075 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4074 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
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/varnish-cache@4073 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4072 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
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/varnish-cache@4071 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
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/varnish-cache@4070 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
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/varnish-cache@4069 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Artur Bergman authored
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/varnish-cache@4068 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4067 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 10 May, 2009 1 commit
-
-
Artur Bergman authored
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/trunk/varnish-cache@4066 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 09 May, 2009 14 commits
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4065 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4064 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4063 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4062 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4061 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Platform-breakage to be expected I pressume. Apply gross hacks to POSIX-shortages, trying to get a result barely as usable as what sensible operating systems have provided since at least 1985. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4060 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4059 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4058 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4057 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Maxim Sobolev <sobomax@FreeBSD.org> git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4056 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4055 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4054 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4053 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
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 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4052 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 04 May, 2009 4 commits
-
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4050 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Artur Bergman authored
This is in anticipation for set req.esi = off; git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4049 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Fixes #502 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4048 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
broke pipehandling. Fixes #505 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4047 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 01 May, 2009 3 commits
-
-
Poul-Henning Kamp authored
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. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4046 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4045 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4044 d4fa192b-c00b-0410-8231-f00ffab90ce4
-