knutroy [Tue, 21 Aug 2007 11:48:57 +0000 (11:48 +0000)]
* Connect to management socket after select-loop is started.
* Removed Varnish::Test::Varnish::kill() which we do not use.
(Varnish::Test::Varnish::shutdown() does kill() and more.)
phk [Tue, 21 Aug 2007 09:23:31 +0000 (09:23 +0000)]
Make sure wrk->used is always set when we park on an object, we might be
unlucky multiple times in which case the responsibility falls back to
cnt_lookup().
des [Mon, 20 Aug 2007 19:27:08 +0000 (19:27 +0000)]
Distribute all the files that are needed to recreate the change logs, and
add an explicit dependency so the logs are regenerated if the stylesheet
changes.
des [Mon, 20 Aug 2007 19:17:49 +0000 (19:17 +0000)]
At some point along the line, I forgot that these files aren't actually
DocBook, and that I don't have <filename>, <literal>, <varname> etc. -
just <code>.
phk [Mon, 20 Aug 2007 11:05:07 +0000 (11:05 +0000)]
Fix a long-standing bug in pipe-mode: We must pass the protocol version
across unchanged, otherwise the semantics of the Connection: header cannot
be interpreted correctly by the server.
wget(1) could trigger this problem and would have to wait for the server
to close the (seemingly idle) connection before continuing.
des [Mon, 20 Aug 2007 09:52:51 +0000 (09:52 +0000)]
Use time-limited polling loops to verify parent and child startup and child
shutdown, instead of relying on unordered events. Ignore anything that
appears on varnishd's std{out,err} except for an unexpected "child died",
which we handle by dying instead of emitting an event.
des [Mon, 20 Aug 2007 07:56:25 +0000 (07:56 +0000)]
Change the way the result from a command is reported. Instead of separate
ev_varnish_command_ok and ev_varnish_command_unknown events, we now emit
a single ev_varnish_result event accompanied by the result code and text.
Furthermore, Varnish::Test::Varnish::send_command() will now wait for this
event and return the code and text.
Note that this reintroduces a race between ev_varnish_child_stopped and
ev_varnish_result; this will be dealt with in a later commit.
phk [Sun, 19 Aug 2007 21:20:48 +0000 (21:20 +0000)]
Reset the cli buffer when we have soaked up all it contained.
Otherwise we will for ever be repeating the same command over and over,
no matter what the input to the cli might be.
des [Sun, 19 Aug 2007 18:12:03 +0000 (18:12 +0000)]
Restructure mgt_cli_callback(), and add comments to make it clear what's
going on. Also take care of a bug where strchr() was used on a non-NUL-
terminated buffer. This fixes #134.
knutroy [Wed, 15 Aug 2007 08:28:58 +0000 (08:28 +0000)]
* Added handling of event handlers using die(), by queuing "die"
events.
* Issue warning when IO::Multiplex has been subject to die() which
where not caught and queued. (This is known to happen e.g. when
hitting die() in Varnish::Test::Server::Connection::mux_eof(), so a
more complete, long-term die()-wrapping solution is needed.)
ingvar [Tue, 14 Aug 2007 21:57:58 +0000 (21:57 +0000)]
* Tue Aug 14 2007 Ingvar Hagelund <ingvar@linpro.no> - 1.1.svn
- Update for 1.1 branch
- Added the devel package for the header files and static library files
- Added a varnish user, and fixed the init script accordingly
des [Mon, 13 Aug 2007 13:52:29 +0000 (13:52 +0000)]
Improve timeout handling, and add a server timeout which starts running when
the server gets a partial response. Similarly, on the client side, cancel
the timeout as soon as we get data, but restart it if we have to wait for
more. Also stop logging the full content of requests and responses; it
clutters the output and can easily be obtained using varnishlog(1).
phk [Fri, 10 Aug 2007 09:51:16 +0000 (09:51 +0000)]
Fix an architectural mistake:
What the compiled VCL code contains is not "a backend" but more
like a specification of or a template of a backend.
This matters because it controls the ownership of the backend
structure, and to a lesser degree because it complicates the VRT
api with a lot of pointless functions.
When vcl.use switches to a different VCL program, the backends of
the old VCL program may still be in use, and, provided the backend
declarations of the two VCL programs are identical, should continue
be carried over to the new VCL code.
This requires the memory and state to be owned by the central backend
code, and the VCL programs to just hold references and becomes even
more important when we keep complex state for load balancing on
individual backends.
This commit changes the ownership of the backends to the central code,
and moves the specification used in the compiled VCL program to a
communication structure for just that.
This also paves the way for introducing directors/policies for backend
selection and for good measure, I have named the default (ie: current)
backend policy "simple" for now.
phk [Wed, 8 Aug 2007 19:43:51 +0000 (19:43 +0000)]
Implement purging on either of hash or url.
In VCL:
purge_url(<regexp>)
purge_hash(<regexp>)
(for an interrim period purge(<regexp>) will be the same as purge_url).
In CLI
url.purge <regexp>
hash.purge <regexp>
purge_hash operates on the hash-string which results from vcl_hash(),
by default it is composed of:
req.url "#" req.http.host "#"
To purge everything on the virtual host foo.bar.com:
In CLI:
url.purge "#foo.bar.com#$"
In VCL:
purge_hash("#foo.bar.com#$");
The general format, if you have defined vcl_hash(), is:
Each "req.hash +=" operator appends the right hand side of the
+= and a "#" separator.
You'll have to figure out your own regexps.
Under the hood:
Move the hash string from object to objecthead and save space while
we're at it.
des [Wed, 8 Aug 2007 12:10:17 +0000 (12:10 +0000)]
I'm not sure Varnish should GET from the backend when the client used POST
but the VCL script decided to cache the request anyway. Treat it as an
error for now.
phk [Mon, 6 Aug 2007 09:25:20 +0000 (09:25 +0000)]
Rewrite the req.hash implmentation:
Instead of assembling the entire hash-string in the workspace, use
a scatter gather approach, hinted by the VCL compiler.
This eliminates the workspace reservation which prevented regsub() from
working in vcl_hash, and reduces the size of the necessary workspace a
fair bit as well, at the cost of a little bit of complexity in the
hash implmentations.
phk [Mon, 6 Aug 2007 08:07:18 +0000 (08:07 +0000)]
Have the VCL compiler provide a hint about the worst case number of
operations on the req.hash variable.
It is only a hint, because it merely counts how many times the parser
saw something being added to the req.hash variable. If the operation
was in a subroutine which was called multiple times, the hint will not
reflect the number of actual operations.
For now we will deal with that at runtime, at the expense of a
failed transaction every time we run short. If this becomes an issue,
an extensive topological analysis of the VCL program can give us
a definitive count.
projects / varnish / log