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

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

It's general enough to find other uses, but right now it's only for
the manager process.



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

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

spurious first entries.



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

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

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

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

as well allow their manipulation also when the child is not
running.



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

Keep track of all loaded VCL programs in the manager and tell the
child to load them via VCL.

Don't start he acceptor thread until a "start" command cones down
the CLI.

XXX: Right now we leak stuff when a VCL program is dicarded



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

Take default_vcl out of heritage.

Keep track of all compiled VCL files and delete them at
exit.

After starting child, use CLI to load all vcl programs
and then issue "start" via the CLI.

In the cacher, don't start the acceptor until we get
a start command.



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

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

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

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

Add mgt_cli_askchild() function to poke the CLI interface to
the child.

Use it to ping the child every second.


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

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

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

The first line of the response has a fixed format ("%-3d %-8u\n")
and consequently fixed length (CLI_LINE0_LEN == 13).

This makes parsing responses more efficient.  Add a function
in common_cli to do so.




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

cache process again.


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

impossible.



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

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

Placed a new sbuf_clear at a more strategic place. It got cluttered when a host left without SessionClose of SessionReuse.

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

Got a workaround for IP adress fetching. If we connect logger while Varnish is running, we won't catch the IP from SessionOpen since it's already done that. Workaround is to catch the IP from SessionReuse if IP of session is NULL

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

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

fetch it.


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

Not as useful as it will be yet, see ticket 22



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

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

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

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

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

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

Still bits missing.



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

We are only accepting CLI from the pipes in heritage, so simply
run a loop reading those, dispatching lines as we see them.

Export CLI_cmds[] so that the management process can see it,
we might as well take advantage of the shared binary where we can.



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

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

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

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

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

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

them already.


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

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