[SR-Users] Dispatcher Confusion (v3.2.0)

[Asgaroth]

Hi Daniel,

On 27/10/2011 15:57, Daniel-Constantin Mierla wrote:
> Hello,
>
> I just pushed to remote GIT repository in master branch a bit of
> refactoring about the states and ds_mark_dst().

Thanks, I will test the dev branch in a short while and get back to you.

>
> Since with 3.2 seemed that it was lost capability to go inactive after
> a certain number of failures (ds_probing_threshold), there is a new
> state 'trying' that can be used for it. Means that you can set a
> destination in trying state couple of times and then it becomes
> inactive. In 3.1 it was using a confusing mechanism based on probing mode.

Can you explain this trying state and "lost capability to go inactive
after certain number of failures" a little more please and how it
relates to the new trying->inactive states. I would like to understand
how these states relate so that I can test better.

>
>
> So right now there are states: active, inactive, trying and disabled,
> plus modes: probing, not-probing. A destination can be selected only
> if it is active or trying. It will not be selected in inactive and
> disabled. Probing mode specifies whether keepalives should be sent to
> destinations, can be done per address or globally with the module
> parameter ds_probing_mode. If a keepalive is not replied, the address
> is marked as trying first and later will become inactive if keeps
> being non-responsive.

OK, so if I understand this above paragraph correctly, if I have
ds_probing_mode = 0, then I need to set mode manually to probing for a
gateway that has failed "ds_probing_threshold" times? If a server times
out and I set state/mode to "ip", then I assume probing will commence.
In this case the server will not responde to probe requests (as it has
crashed), does this mean then that the state will change to "trying"
because there was no probe response recieved from destination?

>
> The parameter for ds_mark_dst() can be now a combination between
> states and probing mode, like ds_mark_dst("ip").

Excellent, thank you, that will help :)

>
> Maybe you can give it a try and let me know if it works -- I was not
> able to test in my side yet -- remember this id master branch (devel
> version 3.3.0-devX). Once this is ok and the internal states are clear
> and acting properly, I will look into backporting the fixes to 3.2
> branch.

OK, I will try this in a short while and get back to you.

Thanks