Noticed by:	Jyri J. Virkki <jyri@virkki.com>


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

entries, a 'c' for client-related log entries, and a ' ' for everything
else (CLI Ping for instance).  This makes it hard to process logs with
awk or similar tools, since the number of columns varies.  Therefore,
change the character used for non-backend-or-client log entries to '-'.


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

Reduce SHM mutex contention further, by only holding lock over
reservation of space, and do the copying from workthread buffer
to shm buffer efter we let go of the mutex.


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

Debian packaging: Move control file "docs" to "varnish.docs" for consistency, add HTML changelogs from the doc/ directory to the packaging

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

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