Hi, imagine this simple case:
--------------------------
route {
t_on_branch("1");
t_on_failure("2");
xlog("We are in 'route'");
t_relay("1.1.1.1");
}
branch_route[1] {
xlog("We are in 'branch_route[1]'");
# do something....
}
failure_route[2] {
xlog("We are in 'failure_route[2]'");
append_branch();
t_relay("2.2.2.2");
}
---------------------------
In case an error occurs when forwarding the request to 1.1.1.1 this would be
the screen log output:
We are in 'route'
We are in 'branch_route[1]'
We are in 'failure_route[2]'
We are in 'branch_route[1]'
This is: branch_route[1] will also be runned **again** after the failure route
since it was loaded in the first forward attemp.
I really don't know if this is intuitive or not. The only way to "dissable"
branch_route[1] in the failure route is by adding:
-------------------
failure_route[2] {
t_on_branch("2"); # <--- Dissable t_on_branch("1")
xlog("We are in 'failure_route[2]'");
append_branch();
t_relay("2.2.2.2");
}
branch_route[2] {
xlog("We are in 'branch_route[2]'");
# Nothing to do here.
# This route is neccesary to dissable t_on_branch("1")
}
------------------
This would show:
We are in 'route'
We are in 'branch_route[1]'
We are in 'failure_route[2]'
We are in 'branch_route[2]'
What about if "t_on_branch" wouldn't remain loaded after a failure route or
serial forking? wouldn't be more intuitive to re-enable it explicitely when
required?
--
Iñaki Baz Castillo