The silence is broken!
As documentation is never included IN the release (only on the web
site), I am proad to announce the release of mod_backhand 1.0.9 with
almost no documentation of new feature. The ChangeLog holds the only
key :)
I will attempt to decently document the changes before announcing to the
users list and the rest of the world.
This new versions sports:
o HTTP redirection as and alternative method to proxying. (plus to
candidacy functions to do what "you really want" correctly. This allows
visiting www.clientcompany.com and being HTTP redirected to
www-1.datacenter-3.clientcompany.com with the added advantage of having
the user stick to that machine beacuse it is now the URL base.
o Changes to the candidacy function prototype -- you will have to port
your custom cadidacy functions. (should take about 2 minutes per
function -- look at builtins.c and mod_backhand.h for the necessary
structures and examples)
o A fix (was in 1.0.9pre1) for a horrid free() of an uninitialized
pointer that could easy ruin your day if you web site does POSTs.
o More specific self identification through the MulticastStats
directive.
o A log level directive so you can choose EXACTLY what you want to hit
your error_log.
o A directive to allow "forced" self redirection. This means that if
box A decides that box A is best, then box A will proxy to box A. Why is
this useful, if you convince box A it is box A', then you have a HTTP
accelerator.
This will allow you to run mod_backhand as load_balancing HTTP
accelerator for mod_perl or mod_php servers on the same or different
machines.
If you have 10 servers 1.1.1.1 -> 1.1.1.10 (with Apache+mod_backhand
running on that external interface) and 1.1.1.1 -> 1.1.1.10 have
192.168.1.1 -> 192.168.1.10 as internal interfaces with hefty
mod_{perl,php} server running on them, respectivel; then you can now
say:
On server <X>'s exposed mod_backhand server you say:
BackhandSelfRedirect On
MulticastStats 192.168.1.<X>:80 192.168.1.255:4455
The front end servers will "advertise" themselves as the backhand
servers to each other and thus the front end servers will redirect to
backend servers for content. The problem in earlier versions was that
if a machine found itself to be the best, it would attempt to server the
page on the spot (BAD -- it isn't running mod_{perl,php}). With the new
BackhandSelfRedirect On directive it will proxy to "itself" rather than
serve the request.
All other features can be found by, you guessed it, *reading the source*
or visiting the viewcvs set up here to look for differences:
http://www.cnds.jhu.edu/cgi-bin/viewcvs/jesus/mod_backhand/
Have blast... documentation and a formal announcement will come in time.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
As documentation is never included IN the release (only on the web
site), I am proad to announce the release of mod_backhand 1.0.9 with
almost no documentation of new feature. The ChangeLog holds the only
key :)
I will attempt to decently document the changes before announcing to the
users list and the rest of the world.
This new versions sports:
o HTTP redirection as and alternative method to proxying. (plus to
candidacy functions to do what "you really want" correctly. This allows
visiting www.clientcompany.com and being HTTP redirected to
www-1.datacenter-3.clientcompany.com with the added advantage of having
the user stick to that machine beacuse it is now the URL base.
o Changes to the candidacy function prototype -- you will have to port
your custom cadidacy functions. (should take about 2 minutes per
function -- look at builtins.c and mod_backhand.h for the necessary
structures and examples)
o A fix (was in 1.0.9pre1) for a horrid free() of an uninitialized
pointer that could easy ruin your day if you web site does POSTs.
o More specific self identification through the MulticastStats
directive.
o A log level directive so you can choose EXACTLY what you want to hit
your error_log.
o A directive to allow "forced" self redirection. This means that if
box A decides that box A is best, then box A will proxy to box A. Why is
this useful, if you convince box A it is box A', then you have a HTTP
accelerator.
This will allow you to run mod_backhand as load_balancing HTTP
accelerator for mod_perl or mod_php servers on the same or different
machines.
If you have 10 servers 1.1.1.1 -> 1.1.1.10 (with Apache+mod_backhand
running on that external interface) and 1.1.1.1 -> 1.1.1.10 have
192.168.1.1 -> 192.168.1.10 as internal interfaces with hefty
mod_{perl,php} server running on them, respectivel; then you can now
say:
On server <X>'s exposed mod_backhand server you say:
BackhandSelfRedirect On
MulticastStats 192.168.1.<X>:80 192.168.1.255:4455
The front end servers will "advertise" themselves as the backhand
servers to each other and thus the front end servers will redirect to
backend servers for content. The problem in earlier versions was that
if a machine found itself to be the best, it would attempt to server the
page on the spot (BAD -- it isn't running mod_{perl,php}). With the new
BackhandSelfRedirect On directive it will proxy to "itself" rather than
serve the request.
All other features can be found by, you guessed it, *reading the source*
or visiting the viewcvs set up here to look for differences:
http://www.cnds.jhu.edu/cgi-bin/viewcvs/jesus/mod_backhand/
Have blast... documentation and a formal announcement will come in time.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7