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

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

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

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

new ones.


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

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

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

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

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

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

* 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

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

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

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

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

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

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

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

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

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

gracefully.


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

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

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

storage chunks.



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

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

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

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

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

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

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

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

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

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

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

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

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

given circumstances is fair game.


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

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

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

from which it tries to extract as much useful information as possible before
it croaks.  The corresponding macro is spassert(), which assumes you have
a struct sess *sp in scope.  This should help a lot with bugs like #167
where important information is not available post-mortem (because sp->obj
points into the cache, which is not included in the core dump)


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