Debian packaging: Fix syntax error in varnishlog init script, and set correct variable in defaults file. Add clarifying comment for variable

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

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

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

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

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

Ignore SIGPIPE, otherwise varnishreplay will stop as soon as varnishd starts
overflowing.


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

-s, this allows varnishlog to be used to extract part of a log file, or
partition a log file into smaller sections.


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

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

fd has finished, flush the previous request with an additional line to note
that the request was interrupted.

This is usually a symptom of the child dying midway through the first
request.


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

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

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

structure into the picture.


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

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

can be tuned separately.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Drop the hangman, with grace implemented we might as well just ditch
the object when the timer expires.

Use separate markers for "on LRU" and "on binheap" and document the
specific protocol for avoiding conflicts between LRU and timer processing.

Many more asserts and a couple of minor bugfixes.



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

missed a marker variable.



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

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

return value, and not in errno.


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

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

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

the LRU list and the binary heap.  In both of these cases, operations
on one object will result in certain fields in neighbor objects in
these data structures to be updated.

In difference from cache_hash.c which examine objects related by
hash match where the existence of the hash lookup in the first place
is a predictor for their likely use, in cache_expire the neighbor
objects are totally unrelated and the fact that we update their
list pointers or binheap index in no way indicates that they will
get a cache hit any time soon.

Paging in one page for a number of objects, just to move another
object up or down the binheap or LRU list is thus not only slow,
but also increases varnish' VM footprint for no real benefit.

This commit moves the relevant housekeeping fields into a "objexp"
structure, which gets hung off the objects when they enter the cache.

The objexp structure is small (40 bytes on i386) so statistically it
is more than an order of magnitude more likely to already be in core
when we need it, compared to the object itself.




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

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

when we shuffle the LRU list.


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

expiry mutex without waiting.

This is in addition to the already present "only if it have not
been moved recently" check.

This additional mutex-contestion reduction obviously might leave
the LRU list badly out of order, but this can be worked around
by examining obj.last_use in vcl_discard()



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

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

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