run-time parameters.

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

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

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

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

Clean up the paramter stuff even more.



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

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

Give the managers main a struct cli and use that to call into
the paramter stuff for setting listen address.  More params to follow.

When setting the listen address, check that getaddrinfo() doesn't
hate it.



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

Make the listen address a parameter.



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

that way and we may eventually want a config file for varnishd to
control obscure parameters.



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

VCL tracing is responsible for a very large fraction of the shmlog
records and will generally only be used for debugging of VCL code.



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

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

large in general (think RTT) for this to make sense, it costs a syscall
and if a delay is used, at least two context switches.

We still capture sessions that do pipe-line avoiding the context switch
in that case, without incurring the syscall overhead.


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

knowing this at the end of a request.

Instead put the address + port in the ReqStart shmtag where it does
a lot of good.


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

It is not clear if this is a benefit or not.  There seems to be a significant
(100msec ?) inter-request gap and seeting the grace period that long
means tying up worker threads doing basically nothing.

Setting a short timeout (10msec) results in an extra system call which
practically never does anything good.

Unless benefit is shown, this stuff should be removed again.


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

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

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

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

need to use REG_STARTEND any more.


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

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

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

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

Also skip IP# from SessionReuse records.


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

 - use the correct headers
 - don't duplicate WRK_Flush()
 - pass the offset correctly

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

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

don't waste time putting the session on the herder, but go right
back and take the next request in the current worker thread.



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

Reduce memory footprint by only allocating space for a fd first time
we see it.  Few if any servers will ever see 64k fd's in use.

Move the sbuf into the logline structure for simplicity.

Access the logline structure through a pointer instead of indexing
the array all the time.

Reduce amount of malloc/free traffic for performance.

Use the "cooked" SHMlog api where the length, fd, etc are broken out
as arguments for us.  Pass the FILE* where we want the stuff to
go as private data (stdout for now).

Add FlexeLint files.

Now over to Anders again...



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

Fixed timestamp so thats it's correct. PHK added a new variable to ReqEnd that contains a correct endtime.



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

Vector failures of the the FIRST case via DONE as well to
avoid code duplication.



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

Isolated by:	Xing Li <xing@litespeedtech.com>


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

low-bandwidth devices which for some reason include their entire
lifehistory in the HTTP requests.


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

Cleared some unused variables.




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

on subsequent requests.


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

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

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

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

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

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

Getting somewhere. I now have a "full" logline. Apart from writing usernames caught by the auth header, the logline is complete.
I have now cleared up my obvious memoryleaks also.

The code looks like it has been through a shredder, and needs massive cleaning before alpha.



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

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

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