Hello,

On 08/10/08 19:15, Iñaki Baz Castillo wrote:

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?

right, you have some good point, at least there should be a way to reset calls of the branch_route. Please add it to the tracker.

Thanks, Daniel