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

Fixes	#640



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

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

properly close the connection when doing so.

Fixes 524



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

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

a table produced from the CLI parameter tables.

In the future all updates to these descriptions SHALL happen in the
CLI tables in the C source code.

Fixes	#419



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

which only does something if -DDIAGNOSTIC was configured.

First secret superpower is "-x dumpmdoc" which emits a -mdoc suitable
table of all run-time parameters, which can be absorbed into the
varnishd.1 manual page, so we do not have to maintain the text in
two different places.



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

Fixes #592



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

out.



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

storage space.

Fixes	590



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

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

sockets as fast as we can, so that a new copy of varnishd can get at them.

Fixes	#622



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

If the master pid is active when we start, we issue a message about
this, (with a hint about -n) and exit.

If the master pid is not active, but the child pid is, we issue a
message about it presumably being busy dying, dump the SHMFILE and
create a new one.  (This only saves our bacon, if the dying
process manages to close the listening sockets before we need them).

This should end any confusion that might arise from accidentally
running multiple varnishes at the same time.

Fixes #620



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

the worker thread.



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

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

simply be dying on us.  Instead return the designed error code for
this: CLIS_COMM 

Fixes	#639



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

object on the LRU list, we may not be holding the last reference.

Fixes:	#634

Tip of hat to:	Matt Page for execellent diagnosis & patch.



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

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

actual objhead, to make it painfully obvious, that no dereference is
allowed.

Various strokes with the polishing cloth along the way.



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

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

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

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

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

Fixes #635



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

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

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

transaction



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

is some limit to linux kernels promiscuousness.



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

before mucking with a running server.

If running on a random port, record it for subsequent -starts, so
we use the same (random) port throughout.

Fix the v00014 testcase which made some really bad assumptions relative
to the above, eliminating the delay it used in the process.



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

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

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

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

For now use 255.255.255.254 which is about as illegal as an IP# can
be for TCP purposes.

Use instead of 127.0.0.2, which appearantly Linux allows you to bind to.



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

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

filedescriptors, generalize that concept and use it for all cases
where we cannot accept and/or serve the connection:  (Lack of sessions,
lack of workerthreads).

This is controlled by three paramters:

Everytime we run into trouble, we increase the sleep-time by:
	acceptor_sleep_incr (0.001 s)

But we never let it get above
	acceptor_sleep_max  (0.050 s)

Once we manage to accept and schedule a connection, we multiply
the sleep-time by:
	acceptor_sleep_decay (0.9)

The default numbers are more or less picked out of thin air.

Two new stats counters help us keep track of this:
	accept_fail
		where accept(2) returns error.  This can be out of
		file-descriptors, but also clients which closed while
		they were stuck in the accept-queue.  Under normal
		operation, a minor trickle is probably to be expected.

	client_drop
		New connection dropped, because we could not get a
		session for it, or because the workerthreads were
		too busy.

	client_drop_late
		An previously served connection was dropped for the
		same reasons.

As always, feedback welcome.




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

as indeed queued or if it was dropped.



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

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

Put the fields VCL tweaks in the worker, and figure out the real
numbers when we connect/have connected to a backend, and but the
numbers in the vbe_conn.



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

Always zap struct sess to zero before we start using it, but do so in the
recycling workerthread if we can get away with it, to reduce the amount
of work done in the acceptor.

Let worker threads pick up some of the pool-expansion work by pre-creating
sessmem structures, to offload this from the acceptor thread if possible.



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

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