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

Add a couple of asserts to check that they all do now.



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

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

selected port numbers.

I belive varnishtest is now entirely without magic TCP port numbers
and multiple instances should be runable without collision.



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

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

workdir below there as well.

Do not remove the tmpdir if we have verbosity and failure, otherwise do.



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

At verbose=0, only spit out a single line if a test passes, but dump
the full show if it fails.

Should make "make check" less tedious to read through.

Fix a race situation related to vsb's while shutting down.




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

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

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

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

Fixes #628

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

subsystems are used (storage/hash/waiter) but not the options given to
these.

This info is often missing in bugreports.



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

Fixes	#617


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

add proper metadata/comment field.

Spotted by:	Kristian



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

Fixes #625

Submitted by:	slink




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

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