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

very first functions ever written in Varnish.   Since I knew
that the file stevedore would always return the size you asked for,
or panic, I didn't bother to actually check how big the storage
segment he allocated was, I just knew it would be the right size.

Guess what, segments are finite size in the -spersistent stevedore
so you may in fact _not_ get what you ask for.

(Cue music: Theme Music from The Keystone Kops)

DuH!


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

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

Don't explode manager if it gets overwritten.



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

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

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

Add test-case for same.



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

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

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

for expiry of non-instantiated objects from -spersistent



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

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

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

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

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

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

first, so combine them into one and avoid the issue entirely.



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

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

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

This is the number of good probes we pretend to have already seen when
we start up, in order to speed up getting healthy backends.

The default value is one less than the .threshold, so the backend
will be set healthy if it manages to respond correctly to the very 
first probe we send to it.

(A bit of this commit leaked in during r4184)



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

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

so that we do not RST connections that have still not transmitted their
data.

Since we were able to get the writev(2) to detach the socket, we should
not end up sleeping in the close(2) either.

We still RST the socket for all error conditions.

Ideally I would still like to RST connections that have no outstanding
data after their sess_timeout, in order to avoid the 2*RTT+misc
timeouts delays associated with loosing a TCP socket for a client
that have gone to meet some other IP#.

In particular with load-balancers, this allows the load balancer to
declare the session dead right away, and reuse it for something more
productive.

Unfortunately, this lacks OS support in all presently released
OS'es: you cannot ask if a socket is done transmitting what you
asked it to.

FreeBSD-8.0 will have experimental support for this (FIONWRITE)
and I will revisit it in that context.




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

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

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

to recycle



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

Add a complementary vsb_unquote() function.



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

Reinstate code to embed the svn version (or git commit id) in the
output given by varnishd -V.

Also, make sure we don't overwrite version.c when the tree is
exported, but generate it if it's completely missing.  (This should
only happen if somebody does svn export rather than make dist, but
some people might do that.)

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

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

varnishtop used to have a hard-coded max record length of 255 bytes.
This broke with the change that allows larger record length.  Use a
dynamic buffer instead.

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

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

http://www.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html

"The pthread_mutex_trylock() function shall return zero if a lock on the mutex object referenced by mutex is acquired. Otherwise, an error number is returned to indicate the error."



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

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

to toggle blocking. This then results in the connects failing.

The way Solaris seems to want it to be done is using fcntl
over two syscalls. So make it so conditionally for Solaris.

Should fix #482 and #535

Compiled on Solaris and Victori tested a prelminary version
of the patch that solved it. Sadly test cases don't 
seem to run at all on my solaris dev zone.



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

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

fix segfault on eviction -- add testcase that actually tests eviction, without patch the test case segfaults

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

AIX has a "struct thread" in pthread.h, which conflicts with our
struct thread.  Rename ours to replay_thread.

Fixes #531

Thanks to demik for patch

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

AIX doesn't have WCOREDUMP, so compilation failed there.  Add #ifdef.

Partially addresses #531.

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

When hitting 304, ETag, Content-Location, Expires, Cache-control and
Vary should all be sent to the client.

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
for some more details

Thanks to Rogério Schneider for the patch.

Fixes #529

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

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

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

Previously, we did not print out the tag in -1 mode, just the value.
This has been changed so we now print both.

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