- 18 Dec, 2007 7 commits
-
-
Dag Erling Smørgrav authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2306 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2303 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2302 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2301 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
References to tickets have been included where I have been able to track down the ticket corresponding to a particular commit. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2300 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
new ones. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2298 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Stig Sandbeck Mathisen authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2295 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 11 Dec, 2007 7 commits
-
-
Poul-Henning Kamp authored
are parked not holding a worker thread, until the fetching session lowers the busy bit on the object. At that point we would release all the parked requests into the thread pool to be serviced, causing instant congestion and calls for road-pricing if the backend were a bit slow on an oft-requested object. Change the restart policy to be paced exponential: When we clear the busy bits, we unpark "rush_exponent" requests into the thread pool to start the show. Whenever the object is dereferenced, in practice whenever a request has been serviced, another "rush_exponent" worth of requests are unparked into the tread pool. Set the parameter to a conservative 3 until we know more about the behaviour in practice. If it is a big object and/or the clients are on slow lines, 3 may be an order of magnitude to small. Attempts to fix: #188 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2294 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
On FreeBSD this means that for instance "top -H" will show the varnish threads as "cache-foo" for various values of foo, hopefully giving us another debugging hint. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2293 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2292 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Stig Sandbeck Mathisen authored
was included by the debhelper tag as well, which resulted in a double startup entry, and an error on package installation. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2291 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Stig Sandbeck Mathisen authored
* Use native version for the debian package * Add headers to indicate location of varnish source * Add "xsltproc" to build dependencies git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2290 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Stig Sandbeck Mathisen authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2289 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Stig Sandbeck Mathisen authored
an erroneous use of -n from the configuration examples. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2288 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 10 Dec, 2007 1 commit
-
-
Poul-Henning Kamp authored
Add a byte to the length field, but retain the 255 bytes restriction for now. Add symbolic names for the header fields and macros for multi-byte fields, and uses these throughout. This will make it easier next time. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2287 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 07 Dec, 2007 1 commit
-
-
Poul-Henning Kamp authored
that for the managers CLI event-engine: React to POLLNVAL as we would to POLLHUP git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2286 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 23 Nov, 2007 2 commits
-
-
Poul-Henning Kamp authored
See also http://www.version2.dk/artikel/5153 if you read danish. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2285 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2284 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 20 Nov, 2007 21 commits
-
-
Poul-Henning Kamp authored
I find out where to put ad-hoc stuff like this in the tree. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2283 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
as opposed to unhandled esi: elments which we complain about in varnishlog. Thus, if you want to get a short comment into the shmlog, the easiest way is to do something like <esi:say a="Hi Mom"> which will result in a shmlog record: 11 ESI_xmlerror c at 25: ESI 1.0 unimplemented element "<esi:say Hi Mom>" But the length of the message is truncated to avoid dumping the entire source document into the shmlog. Snip out any unknown esi: element. While the ESI 1.0 specification doesn't address this directly, my impression from the document is that they should never leak through to the client. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2282 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
storage boundaries. Complain if it isn't closed at the end. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2281 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
gracefully. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2280 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2279 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2278 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
storage chunks. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2277 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
to parse due to lack of bytes. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2276 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
parts, otherwise we will get trouble (#167 ?) later. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2275 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2274 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2273 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
evaluated even if we don't bother to check the result. We should trust the compiler to eliminate code that has no effect. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2272 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2271 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Dag Erling Smørgrav authored
to feed to h_ncsa(), so it is up to h_ncsa() to interrupt it if reopen is non-zero. Also remove a superfluous call to VSL_Arg() as was previously done in varnishlog(1). git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2270 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2269 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
we get around to delete the kevent. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2268 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
do anything about the associated session. May be relevant relative to: #162 (Bitmap functions slightly general, for possible later reuse) git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2267 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Don't take a detour around cache_response.c, go directly to cache_synthetic.c. Don't wast time and energy mucking about with pseudo-objects, just synthesize the error body directly in the workspace and send it from there. Close the session after sending error response, freeing up resources sounds like a good strategy. (XXX: for futher study). This might be related to #167 git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2266 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2265 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
given circumstances is fair game. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2264 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
Poul-Henning Kamp authored
Collect any messages from the C-compiler and pass them on to the user, but do not take them as evidence of a failed compilation, check the returnvalue for that. To avoid confusion, explicitly say when the VCL program was compiled. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2263 d4fa192b-c00b-0410-8231-f00ffab90ce4
-
- 15 Nov, 2007 1 commit
-
-
Dag Erling Smørgrav authored
git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2255 d4fa192b-c00b-0410-8231-f00ffab90ce4
-