Aiming for Varnish 2.0

[Poul-Henning Kamp]

We are putting Varnish 2.0 right in the cross-hairs now, and that means
that I'll be trying to close as many outstanding issues and tickets as
possible.

I will strongly urge you all to run -trunk and help flush out the
remaining bugs.

Please also help go through the tickets and tell me if there are tickets
that should be closed.

I have made a number of changes in the last couple of days that warrant
a comment here:


regsuball() in VCL
------------------

	Just like regsub, but replaces all occurances of the regexp.
	The manual page was wrong about regsub() previously; it
	only replaces the first match.

Backend connect timeout
-----------------------

	We now have a timeout for how long time it may take to open
	the TCP session to the backend.  This should reduce the
	amount of havoc caused by network hiccups.

	Please understand that this is only the timeout to open the
	TCP connection, not the timeout to perform the HTTP
	transaction.

	The default is 400 msec and you can change the default as
	a parameter ("connect_timeout"), or set a specific timeout
	for each backend in VCL:

                backend b1 {
                        .host = "hex";
                        .port = "80";
                        .connect_timeout = 500 ms;
                }

	Let me know if 400 msec is a bad default.

CLI code cleanup
----------------

	The CLI code has been cleaned up and given a "quit" command.

	This should eliminate some crashes seen in relation to heavy
	CLI traffic via the TELNET interface.

	CLI commands and sessions are now logged in syslog(3).

PURGE code cleanup
------------------

	I have renamed the CLI commands:
		from url.purge to purge.url
	and
		from hash.purge to purge.hash
	for consistency.

	I have no idea how I got it wrong in the first place.

	The old commands will work in all 2.x releases.

	In version 1.x purges based on regexps were expected to be
	very infrequent manual operations, so we didn't clean them
	up, but after my work on them tonight, they should be ready
	for heavy-duty traffic.

	Be aware though, that they _are_ based on regular expressions.

	If you have to purge 10000 objects, you should try to express
	that as a (few) regular expression.

	If you do 10000 individual purges, it means that all cached
	objects will be tested against 10000 regexps next time they
	are hit.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.